Red Hat Bugzilla – Bug 978443
virt-install without -w bridge=<name> using xen is unable to start
Last modified: 2013-08-31 10:38:34 EDT
Description of problem: If I try to install a Fedora guest using: virt-install -l http://192.168.2.251/tftpboot/lab/tst031/f19-x86_64 --ram 1024 --disk /dev/vg_guests/guest2 --name F19-64 Starting install... Retrieving file .treeinfo... | 2.2 kB 00:00:00 !!! Retrieving file vmlinuz... | 9.6 MB 00:00:00 !!! Retrieving file initrd.img... | 63 MB 00:00:00 !!! ERROR internal error libxenlight failed to create new domain 'F19-64' Domain installation does not appear to have been successful. If it was, you can restart your domain by running: virsh --connect xen:/// start F19-64 otherwise, please restart your installation. (This is a Xen version with patches 978036 977987). These RPMs are installed: [root@tst031 ~]# rpm -qa | grep xen xen-4.2.2-9.fc19.x86_64 xen-doc-4.2.2-9.fc19.x86_64 libvirt-daemon-xen-1.0.5.1-1.fc19.x86_64 xen-ocaml-4.2.2-9.fc19.x86_64 xen-libs-4.2.2-9.fc19.x86_64 xen-runtime-4.2.2-9.fc19.x86_64 xen-hypervisor-4.2.2-9.fc19.x86_64 xen-ocaml-devel-4.2.2-9.fc19.x86_64 xen-licenses-4.2.2-9.fc19.x86_64 xen-devel-4.2.2-9.fc19.x86_64 libvirt-daemon-driver-xen-1.0.5.1-1.fc19.x86_64 [root@tst031 ~]# rpm -qa | grep libvirt libvirt-daemon-xen-1.0.5.1-1.fc19.x86_64 libvirt-daemon-driver-nwfilter-1.0.5.1-1.fc19.x86_64 libvirt-daemon-config-network-1.0.5.1-1.fc19.x86_64 libvirt-daemon-driver-secret-1.0.5.1-1.fc19.x86_64 libvirt-client-1.0.5.1-1.fc19.x86_64 libvirt-gobject-0.1.6-1.fc19.x86_64 libvirt-daemon-1.0.5.1-1.fc19.x86_64 libvirt-daemon-driver-nodedev-1.0.5.1-1.fc19.x86_64 libvirt-daemon-kvm-1.0.5.1-1.fc19.x86_64 libvirt-daemon-driver-qemu-1.0.5.1-1.fc19.x86_64 libvirt-daemon-driver-libxl-1.0.5.1-1.fc19.x86_64 libvirt-glib-0.1.6-1.fc19.x86_64 libvirt-daemon-driver-storage-1.0.5.1-1.fc19.x86_64 libvirt-daemon-driver-interface-1.0.5.1-1.fc19.x86_64 libvirt-daemon-driver-network-1.0.5.1-1.fc19.x86_64 libvirt-gconfig-0.1.6-1.fc19.x86_64 libvirt-python-1.0.5.1-1.fc19.x86_64 libvirt-daemon-driver-xen-1.0.5.1-1.fc19.x86_64 Version-Release number of selected component (if applicable): How reproducible: 100% Steps to Reproduce: 1. virt-install -l http://192.168.2.251/tftpboot/lab/tst031/f19-x86_64 --ram 1024 --disk /dev/vg_guests/guest2 --name F19-64 2. 3. Actual results: virt-install -l http://192.168.2.251/tftpboot/lab/tst031/f19-x86_64 --ram 1024 --disk /dev/vg_guests/guest2 --name F19-64 --force Starting install... Retrieving file .treeinfo... | 2.2 kB 00:00:00 !!! Retrieving file vmlinuz... | 9.6 MB 00:00:00 !!! Retrieving file initrd.img... | 63 MB 00:00:00 !!! ERROR internal error libxenlight failed to create new domain 'F19-64' Domain installation does not appear to have been successful. If it was, you can restart your domain by running: virsh --connect xen:/// start F19-64 otherwise, please restart your installation. Expected results: virt-install -l http://192.168.2.251/tftpboot/lab/tst031/f19-x86_64 --ram 1024 --disk /dev/vg_guests/guest2 --name F19-64 --force -w bridge=switch Starting install... Retrieving file .treeinfo... | 2.2 kB 00:00:00 !!! Retrieving file vmlinuz... | 9.6 MB 00:00:00 !!! Retrieving file initrd.img... | 63 MB 00:00:00 !!! Creating domain... | 0 B 00:00:00 Additional info:
Sorry about the extra parameters on the virt-install. The "Actual results" and "Expected Results" should have: "virt-install -l http://192.168.2.251/tftpboot/lab/tst031/f19-x86_64 --ram 1024 --disk /dev/vg_guests/guest2 --name F19-64"
Aha! <dariof> darnok: 'cause I think I've seen something like that, having to do with the fact that it by defaults look for 'xenbr0' <dariof> darnok: "it" being the libxl driver (or so I think) .. <darnok> dariof, Right on the money: rror: libxl_exec.c:118:libxl_report_child_exitstatus: /etc/xen/scripts/vif-bridge online [1326] exited with error status 1 <darnok> libxl: error: libxl_device.c:979:device_hotplug_child_death_cb: script: Could not find bridge device xenbr0 And sure enough, if I setup 'xenbr0' bridge (instead of 'switch') it magically works!
(In reply to Konrad Rzeszutek Wilk from comment #2) > <dariof> darnok: 'cause I think I've seen something like that, having to do > with the fact that it by defaults look for 'xenbr0' > <dariof> darnok: "it" being the libxl driver (or so I think) If the bridge name is not specified, libxl itself sets the default to xenbr0. From tools/libxl/libxl.c libxl__device_nic_setdefault(): if (!nic->bridge) { nic->bridge = strdup("xenbr0"); if (!nic->bridge) return ERROR_NOMEM; }
Is there a default that libvirt uses? Meaning use the default one from libvirt instead of letting libxl set the default?
(In reply to Konrad Rzeszutek Wilk from comment #4) > Is there a default that libvirt uses? No. And in fact I'm confused about how lack of a bridge name made it past libvirt. E.g. if I try to create or define a domain with a bridge type interface that does not contain a bridge name (<source bridge='br0'/> subelement), I get the following error error: internal error No <source> 'bridge' attribute specified with <interface type='bridge'/> What is the libvirt domXML created for F19-64?
No response for 2 months, closing.