similar to: Error: Device 0 (vif) could not be connected.Hotplug scripts not working.

# HG changeset patch # User Ian Campbell <ian.campbell at citrix.com> # Date 1341941699 -3600 # Node ID efb7fee3573b68e895de0341dd67df83cb68acc6 # Parent ca5c306052791edf6d96da3f80aecd750b86a5e4 hotplug: vif: fail if a duplicate vifname is used. This is based on a patch from Hans van Kranenburg in http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=658305. Quoting that bug report: When

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

Hello, I installed Xen 3.2.1 on Debian Lenny from packages. Then created image files with 'xen-create-image --size=2Gb --swap=128Mb --dhcp --dir=/xen --hostname=test'. Now I'm trying to run Debian in PV mode using the following configuration file: kernel = "/boot/vmlinuz-2.6.26-1-xen-686" ramdisk = "/boot/initrd.img-2.6.26-1-xen-686" memory = 128 name =

Package: xen-utils-3.4 Version: 3.4.3~rc6-1 Severity: important blktapctrl doesn't start. This means that none of the tap: disks work (eg tap:aio). It produces this in the log BLKTAPCTRL[6569]: blktapctrl.c:788: blktapctrl: v1.0.0 BLKTAPCTRL[6569]: blktapctrl.c:790: Found driver: [raw image (aio)] BLKTAPCTRL[6569]: blktapctrl.c:790: Found driver: [raw image (sync)]

Package: xen-utils-4.3 Version: 4.3.0-3+b1 Using the xl toolstack there's no information about the networks of the domUs in xentop. I have a PV and a HVM domU and both are shown as having 0 network interfaces, while in fact they have functioning interfaces. Here's one of the interfaces that should be shown, from xenstore: 29 = "" 0 = "" frontend =

I''m getting this message (subject line) in daemon.log every time I start or restart xend. I''m not sure if this is related to the fact that I cannot boot up my Windows domU from a VHD file. The Windows domU was working fine with Xen 4.0.0 (with 2.6.32.14 dom0 kernel). When I upgraded to Xen 4.0.1-rc4 (with 2.6.32.16 dom0 kernel), I can no long boot the Windows domU from VHD. The

Hi! When I try to compile xen-unstable on Sarge, I get this error and I don''t know how to solve it: make[3]: Entering directory `/root/xen-unstable/tools/blktap/drivers'' gcc -O2 -fomit-frame-pointer -DNDEBUG -m32 -march=i686 -Wall -Wstrict-prototypes -D__XEN_TOOLS__ -fPIC -Wall -Werror -Wno-unused -g3 -fno-strict-aliasing -I ../../../tools/libxc -I ../../libaio/src -I..

Package: xen-utils-3.4 Version: 3.4.3~rc6-1 Severity: important blktapctrl isn't started by default. If blktapctrl isn't started then none of the tap: disks (eg tap:aio) work. This functionality has been removed in tools-misc-xend-startup.diff @@ -120,24 +86,14 @@ if not sys.argv[1:]: print 'usage: %s {start|stop|reload|restart}' % sys.argv[0] elif

a clean new FC6 system downloading xen src tar ball I get make[3]: Entering directory `/opt/xen-3.0.4_1-src/tools/blktap/drivers'' gcc -O2 -fomit-frame-pointer -m64 -DNDEBUG -std=gnu99 -Wall -Wstrict- prototypes -Wno-unused-value -Wdeclaration-after-statement - D__XEN_TOOLS__ -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -Werror - Wno-unused -fno-strict-aliasing -I

Processing commands for control at bugs.debian.org: > close 421825 4.4.0-1 Bug #421825 [src:xen] xen-utils-3.0.3-1: blktap is missing Bug #442380 [src:xen] xen-utils-3.1-1: reenabled blktap support unusable Bug #517007 [src:xen] xen-utils-3.2-1: tap:aio on disk image files is not usable Bug #582363 [src:xen] xen-utils-3.4: blktapctrl not started by default Bug #582364 [src:xen] xen-utils-3.4:

Hi, I am running XEN 4.1 on Debian 6 and I cannot find blktapctrl process running. xend is started. I installed XEN from 4.1 source following instructions here: http://wiki.xensource.com/xenwiki/XenParavirtOps http://wiki.xensource.com/xenwiki/Xen4.0 Should there be a blktapctrl process running in this version? The problem I have encountered is that I can create a domain on a raw disk image but

Andrew, I think bug 709 is caused by blktapctrl not daemonizing itself correctly and holding open a file descriptor that the xm-test python code is reading from. I''m not really very familiar with blktapctrl. If you''d like to pick up the bug or outline how you''d like it fixed---for example by copying the daemonize implementation from xenconsoled---that would be

[PATCH 3/4] (Refactored) Add error checking in blktapctrl blktap-fixes.patch Add some additional error checking to blktapctrl during mkfifo Signed-off-by: Boris Ostrovsky <bostrovsky@virtualiron.com> Signed-off-by: Ben Guthro <bguthro@virtualiron.com> _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com

Package: xen-utils-common Version: 4.1.2-3 Severity: normal When configurating a duplicate custom vifname for interfaces in the Xen dom0 that are added to a bridge (which is obviously a configuration error), the hotplug scripts fail silently to rename the new vifX.0 to the custom vifname, if it's already existing. The result of this, is that the domU will start normally, but no network

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

Hi, Centos 7 Xen4CentOS - 4.6.1 Open vSwitch When i specify custom name of the domU NIC than it refues to start vif = [ 'vifname=vNIC1' ] libxl: error: libxl_exec.c:118:libxl_report_child_exitstatus: /etc/xen/scripts/vif-openvswitch online [10168] exited with error status 1 libxl: error: libxl_device.c:1084:device_hotplug_child_death_cb: script: ip link set vif38.0 name vNIC1 failed

Hi, On restarting one of my domains, it went into zombie state and failed to restart. Now I see it like this: Name ID Mem(MiB) VCPUs State Time(s) Domain-0 0 256 1 r----- 1088916.2 Zombie-test1 111 128 1 ---s-d 195171.2 Issuing "xm shutdown 111" or "xm destroy 111" immediately

Processing commands for control at bugs.debian.org: > forcemerge 582363 582364 421825 442380 517007 Bug #582363 [src:xen] xen-utils-3.4: blktapctrl not started by default Bug #582363 [src:xen] xen-utils-3.4: blktapctrl not started by default The source xen and version 3.0.3-0-2 do not appear to match any binary packages The source xen and version 3.1.0-2 do not appear to match any binary

What follows below is an outline of what we''re changing in Xen startup for Fedora 8. I know historically when getting into initscripts you tend to hit distro specific issues. So I''m posting this to see if there''s any interest from others in having these changes integrated upstream. I''d like to thing that with a few minor tweaks this is general enough to be