Bug 978443 - virt-install without -w bridge=<name> using xen is unable to start
virt-install without -w bridge=<name> using xen is unable to start
Status: CLOSED INSUFFICIENT_DATA
Product: Fedora
Classification: Fedora
Component: virt-manager (Show other bugs)
19
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Cole Robinson
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-06-26 11:59 EDT by Konrad Rzeszutek Wilk
Modified: 2013-08-31 10:38 EDT (History)
9 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-08-31 10:38:34 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Konrad Rzeszutek Wilk 2013-06-26 11:59:33 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:
Comment 1 Konrad Rzeszutek Wilk 2013-06-26 12:02:05 EDT
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"
Comment 2 Konrad Rzeszutek Wilk 2013-06-26 12:27:34 EDT
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!
Comment 3 Jim Fehlig 2013-06-26 12:34:27 EDT
(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;
    }
Comment 4 Konrad Rzeszutek Wilk 2013-06-26 12:44:28 EDT
Is there a default that libvirt uses? Meaning use the default one from libvirt instead of letting libxl set the default?
Comment 5 Jim Fehlig 2013-06-26 13:02:03 EDT
(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?
Comment 6 Cole Robinson 2013-08-31 10:38:34 EDT
No response for 2 months, closing.

Note You need to log in before you can comment on or make changes to this bug.