Bug 912488

Summary:	libvirt-libxl defaulting to tap disk backend and not working
Product:	[Fedora] Fedora	Reporter:	Dario Faggioli <raistlin>
Component:	libvirt	Assignee:	Libvirt Maintainers <libvirt-maint>
Status:	CLOSED ERRATA	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	high	Docs Contact:
Priority:	unspecified
Version:	18	CC:	berrange, clalancette, dallan, itamar, jfehlig, jforbes, jyang, laine, libvirt-maint, raistlin, veillard, virt-maint, xen-maint
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2013-04-11 23:31:24 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

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.