similar to: [RFC] Proposed XenStore Interactions for Multi-Queue VIFs

All the resources allocated based on xen_blkif_reqs are global in blkback. While (without having measured anything) I think that this is bad from a QoS perspective (not the least implied from a warning issued by Citrix''es multi-page-ring patches: if (blkif_reqs < BLK_RING_SIZE(order)) printk(KERN_WARNING "WARNING: " "I/O request space (%d reqs) < ring

Hi, all I want to get some information of How xVM is integrated with Crossbow project. Do some buddies have those documents or blogs? Thanks --luke

Hi all I''m hacking on a netback trying to identify whether TLB flushes causes heavy performance penalty on Tx path. The hack is quite nasty (you would not want to know, trust me). Basically what is doesn''t is, 1) alter network protocol to pass along mfns instead of grant references, 2) when the backend sees a new mfn, map it RO and cache it in its own address space. With this

Hello, We''re running Xen Unstable changeset 15468 with SLES10 on a Unisys ES7000/one 56x cpu and 160GB memory. Xen is built with NR_DYNIRQS=1024 and max_phys_cpus=64, and booted with dom0_mem=1024 and xenheap_megabytes=64. We have 320 para-virtualized SLES10 VMs on external storage. Our script starts a VM, waits for the start to complete, then starts the next: "for i in *.cfg;

Hello, When start a domU through xl create. The domU associated ip in the configuration file is not recorded in the xenstore. For this reason vif-common.sh antispoof scripts fails. *xl create * /usr/bin/xenstore-ls /local/domain/0/backend/vif/5/0 frontend = "/local/domain/5/device/vif/0" frontend-id = "5" online = "1" state = "4" script =

Package: xen-utils-4.0 Version: 4.0.1-2 Severity: normal This issue is similar to http://lists.alioth.debian.org/pipermail/pkg-xen-devel/2011-March/003217.html but since I was not able to find a bug report I'm reporting this now. Steps to reproduce: 1) cat << EOF > config name = 'squeeze64' vcpus = '4' memory = '512' disk = [

I guess I have stumbled upon a bug in gplpv drivers. If you try to re-enable an nic adapter after disabling it, it just hides out of blue. And you have to reboot. Latest version of gplpv drivers and Windows 2008 R2 here. Anyone else noticed the same issue? I wonder if this is related to hot-plugging something like

Hey folks, I created a DomU, installed Linux, and then realized I''d only given it 1 NIC so brought it down to edit the cfg file to give it another NIC. Originally I just had : vif = [''''] And so I guess the defaults worked for the 1 NIC. So I changed it to : vif =

From: Santosh Jodh <santosh.jodh at citrix.com> Add support for multi page ring for block devices. The number of pages is configurable for blkback via module parameter. blkback reports max-ring-page-order to blkfront via xenstore. blkfront reports its supported ring-page-order to blkback via xenstore. blkfront reports multi page ring references via ring-refNN in xenstore. The change allows

From: Santosh Jodh <santosh.jodh at citrix.com> Add support for multi page ring for block devices. The number of pages is configurable for blkback via module parameter. blkback reports max-ring-page-order to blkfront via xenstore. blkfront reports its supported ring-page-order to blkback via xenstore. blkfront reports multi page ring references via ring-refNN in xenstore. The change allows

From: Santosh Jodh <santosh.jodh at citrix.com> Add support for multi page ring for block devices. The number of pages is configurable for blkback via module parameter. blkback reports max-ring-page-order to blkfront via xenstore. blkfront reports its supported ring-page-order to blkback via xenstore. blkfront reports multi page ring references via ring-refNN in xenstore. The change allows

Package: xen-utils-4.17 Version: 4.17.1+2-gb773c48e36-1 Severity: important Dear Maintainers, On one of our domUs we discovered that the network interface names were wrongly assigned since recreating the domU after an upgrade to bookworm. If over 10 network interfaces are configured the mapping (dom0) vifX.10 <-> eth10 (domU) does not apply anymore. Instead the interfaces on dom0 are

Is there a way to dinamically know on which network interface domU sees the Vif Dom0 "gives" to them. Ex: on Dom0: Vifname: vif111.0 on DomU: vif111.0 on network interface : eth0 Best Regards, Diego Dias _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users

What are the outstanding things to do before we think we can start on the 4.2 -rc''s? Does anyone have a timetable in mind? hypervisor: * ??? - Keir, Tim, Jan? tools: * libxl stable API -- we would like 4.2 to define a stable API which downstream''s can start to rely on not changing. Aspects of this are: * event handling (IanJ working

I saw the pci dev''s config is different from vbd/vnif with following comments: # Parsing the device SXP''s. In most cases, the SXP looks # like this: # # [device, [vif, [mac, xx:xx:xx:xx:xx:xx], [ip 1.3.4.5]]] # # However, for PCI devices it looks like this: # # [device, [pci, [dev, [domain, 0], [bus, 0], [slot, 1]]]] # # It seems the reasoning for this difference is

I''m running Xen3 7775 with udev 073 (which was a PITA to get working, as the initrd I''ve been running for quite some time uses an older one -- but that''s an entirely different story). My dom0 is Gentoo-based. When I try to start a DomU, it times out waiting for hotplug-based notification, as per the following: DEBUG (DevController:69) Waiting for devices vif. DEBUG

I''m running Xen3 7775 with udev 073 (which was a PITA to get working, as the initrd I''ve been running for quite some time uses an older one -- but that''s an entirely different story). My dom0 is Gentoo-based. When I try to start a DomU, it times out waiting for hotplug-based notification, as per the following: DEBUG (DevController:69) Waiting for devices vif. DEBUG

Hello, Introduction ------------ I''m introducing myself since it''s my first post here. My name is Roel Broersma and my company is using Xenserver 5.0, we''re using Xenserver since it was from Xensource. Nowadays it''s Citrix and we have several expensive licenses, paid support and are Citrix certified (Silver Solution Advisor). However, we''re

Hello, While using xen 4.1-testing.hg (r23202) I noticed that the ''vifname'' config value is not handled by xl, but is handled by xm. Is there a workaround or patch for this? My firewall and scripts depend on static vifnames. XM works good - it adds multiple interfaces to multiple bridges and configures them appropriately. But with xl it differs -- here only tap devices are

Hello, While using xen 4.1-testing.hg (r23202) I noticed that the ''vifname'' config value is not handled by xl, but is handled by xm. Is there a workaround or patch for this? My firewall and scripts depend on static vifnames. XM works good - it adds multiple interfaces to multiple bridges and configures them appropriately. But with xl it differs -- here only tap devices are