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.
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
FYI, fix has been committed upstream http://libvirt.org/git/?p=libvirt.git;a=commit;h=567779e51a7727b021dee095c9d75cf0cde0bd43
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 ?
Putting in POST to schedule for next Fedora update.
I've done the backport to the v0.10.2-maint branch.
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
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).
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.