Bug 912488 - libvirt-libxl defaulting to tap disk backend and not working
Summary: libvirt-libxl defaulting to tap disk backend and not working
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: libvirt
Version: 18
Hardware: Unspecified
OS: Linux
unspecified
high
Target Milestone: ---
Assignee: Libvirt Maintainers
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-02-18 19:08 UTC by Dario Faggioli
Modified: 2013-04-11 23:31 UTC (History)
13 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-04-11 23:31:24 UTC
Type: Bug


Attachments (Terms of Use)

Description Dario Faggioli 2013-02-18 19:08:55 UTC
Description of problem: when xend is not running, and virt-install and/or virt-manager is used, libvirt-libxl driver kicks in. However, it always seems to try using the tap disk backend, either for VHD or LVM volumes, and that turns out to be impossible, and makes domain creation fail.

Version-Release number of selected component (if applicable):
libvirt-daemon-driver-libxl-0.10.2.3-1.fc18.x86_64
(and also -1.0.2-2-fc19.x86_64)

How reproducible: 100%

Steps to Reproduce:

 -- WHEN USING VHDs

[root@localhost ~]# virt-install -l http://fedora.mirror.constant.com/linux/releases/18/Fedora/x86_64/os/ --ram 1024 --disk /var/lib/libvirt/images/F18-x64.img --name F18_x64-2 --bridge virbr0

Starting install...
Retrieving file .treeinfo...                             | 2.2 kB     00:00 !!! 
Retrieving file vmlinuz...                               | 9.3 MB     00:06 !!! 
Retrieving file initrd.img...                            |  53 MB     00:34 !!! 
ERROR    internal error libxenlight failed to create new domain 'F18_x64-2'
Domain installation does not appear to have been successful.
If it was, you can restart your domain by running:
  virsh --connect xen:/// start F18_x64-2
otherwise, please restart your installation.

libxl: verbose: libxl_create.c:158:libxl__domain_build_info_setdefault: qemu-xen is unavailable, use qemu-xen-traditional instead: No such file or directory
libxl: debug: libxl_create.c:1174:do_domain_create: ao 0x7f5660008f60: create: how=(nil) callback=(nil) poller=0x7f5660002370
libxl: debug: libxl_device.c:229:libxl__device_disk_set_backend: Disk vdev=xvda spec.backend=tap
libxl: debug: libxl_device.c:184:disk_try_backend: Disk vdev=xvda, backend tap unsuitable because blktap not available
libxl: error: libxl_device.c:269:libxl__device_disk_set_backend: no suitable backend for disk xvda
libxl: debug: libxl_event.c:1499:libxl__ao_complete: ao 0x7f5660008f60: complete, rc=-3
libxl: debug: libxl_create.c:1187:do_domain_create: ao 0x7f5660008f60: inprogress: poller=0x7f5660002370, flags=ic
libxl: debug: libxl_event.c:1471:libxl__ao__destroy: ao 0x7f5660008f60: destroy


 -- WHEN USING LVM VOLUMES

[root@localhost ~]# systemctl status xend.service
xend.service - Xend - interface between hypervisor and some applications
	  Loaded: loaded (/usr/lib/systemd/system/xend.service; disabled)
	  Active: inactive (dead)

[root@localhost ~]# virt-install -l http://fedora.mirror.constant.com/linux/releases/18/Fedora/x86_64/os/ --ram 1024 --disk /dev/vms/F18_x64 --name F18_x64

Starting install...
Retrieving file .treeinfo...                             | 2.2 kB     00:00 !!! 
Retrieving file vmlinuz...                               | 9.3 MB     00:06 !!! 
Retrieving file initrd.img...                            |  53 MB     00:33 !!! 
ERROR    internal error libxenlight failed to create new domain 'F18_x64'
Domain installation does not appear to have been successful.
If it was, you can restart your domain by running:
  virsh --connect xen:/// start F18_x64
otherwise, please restart your installation.

[root@localhost ~]# cat /var/log/libvirt/libxl/libxl.log
...
libxl: verbose: libxl_create.c:158:libxl__domain_build_info_setdefault: qemu-xen is unavailable, use qemu-xen-traditional instead: No such file or directory
libxl: debug: libxl_create.c:1174:do_domain_create: ao 0x7f566c008d90: create: how=(nil) callback=(nil) poller=0x7f566c009030
libxl: debug: libxl_device.c:229:libxl__device_disk_set_backend: Disk vdev=xvda spec.backend=tap
libxl: debug: libxl_device.c:184:disk_try_backend: Disk vdev=xvda, backend tap unsuitable because blktap not available
libxl: error: libxl_device.c:269:libxl__device_disk_set_backend: no suitable backend for disk xvda
libxl: debug: libxl_event.c:1499:libxl__ao_complete: ao 0x7f566c008d90: complete, rc=-3
libxl: debug: libxl_create.c:1187:do_domain_create: ao 0x7f566c008d90: inprogress: poller=0x7f566c009030, flags=ic
libxl: debug: libxl_event.c:1471:libxl__ao__destroy: ao 0x7f566c008d90: destroy

Additional info: If manually specifying the backend, things work, at least for LVM volumes. I.e., the following seems to work fine:

[root@localhost ~]# virt-install -l http://fedora.mirror.constant.com/linux/releases/18/Fedora/x86_64/os/ --ram 1024 --disk /dev/vms/F18_x64,driver_name=phy --name F18_x64 --bridge virbr0

I tried this on both F18 and rawhide, and the behaviour is the same.

Comment 1 Jim Fehlig 2013-02-20 16:33:25 UTC
Currently, the libvirt libxl code sets the driver name to 'tap' and driver type
to 'raw' if not specified.  From libxlMakeDisk() in $libvirt-src/src/libxl/libxl_conf.c

    if (l_disk->driverName) {
        ...
    } else {
        /* No driverName - default to raw/tap?? */
        x_disk->format = LIBXL_DISK_FORMAT_RAW;
        x_disk->backend = LIBXL_DISK_BACKEND_TAP;
    }

Perhaps LIBXL_DISK_BACKEND_QDISK is a better default for driver name?  Best to discuss this on the public mail list

https://www.redhat.com/archives/libvir-list/2013-February/msg01124.html

Comment 2 Jim Fehlig 2013-02-20 21:56:26 UTC
FYI, fix has been committed upstream

http://libvirt.org/git/?p=libvirt.git;a=commit;h=567779e51a7727b021dee095c9d75cf0cde0bd43

Comment 3 Dario Faggioli 2013-02-22 15:56:09 UTC
Thanks a lot Jim! So --forgive if I'm not yet 100% aware about the libvirt and libvir Fedora package maintenance practises-- would it be possible to backport an apply Jim's patch to F18 libvirt-daemon-driver-libxl and, hence, close this bug ?

Comment 4 Daniel Berrangé 2013-02-22 15:59:20 UTC
Putting in POST to schedule for next Fedora update.

Comment 5 Eric Blake 2013-02-22 16:24:48 UTC
I've done the backport to the v0.10.2-maint branch.

Comment 6 Fedora Update System 2013-04-01 22:05:49 UTC
libvirt-0.10.2.4-1.fc18 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/libvirt-0.10.2.4-1.fc18

Comment 7 Fedora Update System 2013-04-03 04:28:48 UTC
Package libvirt-0.10.2.4-1.fc18:
* should fix your issue,
* was pushed to the Fedora 18 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing libvirt-0.10.2.4-1.fc18'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2013-4691/libvirt-0.10.2.4-1.fc18
then log in and leave karma (feedback).

Comment 8 Fedora Update System 2013-04-11 23:31:28 UTC
libvirt-0.10.2.4-1.fc18 has been pushed to the Fedora 18 stable repository.  If problems still persist, please make note of it in this bug report.


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