Description of problem: Can not create a xen guest with blktap as the backend driver. When try to create such guest, virsh give the following error message: error: Failed to start domain rhel7 error: internal error: libxenlight failed to create new domain 'rhel7' Version-Release number of selected component (if applicable): libvirt-1.1.3.8-1.fc20 xen-4.3.3-3.fc20 kernel-3.17.2-200.fc20 How reproducible: always Steps to reproduce: 1. Prepare a useable rhel guest image: /var/lib/xen/images/hvm-7.1-64-1.img 2. Create a guest on xen hypervisor with the following disk element: <disk type='file' device='disk'> <driver name='tap' type='raw'/> <source file='/var/lib/xen/images/hvm-7.1-64-1.img'/> <target dev='xvda' bus='xen'/> </disk> 3. Create the domain with the above xml file Actual results: At step 2, virsh give the following error message: error: Failed to start domain rhel7 error: internal error: libxenlight failed to create new domain 'rhel7' Expected results: Can create the guest successfully and guest works well after boot up Additional info: # export VIRSH_DEBUG=0 # export LIBVIRT_DEBUG=1 # virsh -d 0 -l logfile start rhel7 &>more_details # cat logfile [2014.11.28 01:18:08 virsh 7310] INFO start: domain(optdata): rhel7 [2014.11.28 01:18:08 virsh 7310] INFO start: found option <domain>: rhel7 [2014.11.28 01:18:08 virsh 7310] DEBUG start: <domain> trying as domain NAME [2014.11.28 01:18:08 virsh 7310] ERROR Failed to start domain rhel7 [2014.11.28 01:18:08 virsh 7310] ERROR internal error: libxenlight failed to create new domain 'rhel7' [2014.11.28 01:18:29 virsh 7316] INFO start: domain(optdata): rhel7 [2014.11.28 01:18:29 virsh 7316] INFO start: found option <domain>: rhel7 [2014.11.28 01:18:29 virsh 7316] DEBUG start: <domain> trying as domain NAME [2014.11.28 01:18:30 virsh 7316] ERROR Failed to start domain rhel7 [2014.11.28 01:18:30 virsh 7316] ERROR internal error: libxenlight failed to create new domain 'rhel7' The attachment is file: more_details.
Created attachment 965685 [details] more_details
This message is a reminder that Fedora 20 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 20. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '20'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 20 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Closing as EOL for F20. Please reopen if this reproduces on F22
This bug still can be reproduced on Fedora22, so I reopen it. Version: libvirt-1.2.13.1-1.fc22.x86_64 xen-4.5.1-2.fc22.x86_64 kernel-4.0.4-301.fc22.x86_64 Steps are the same as the description of the bug, actual resutl is as below: [root@dhcp-66-73-92 ~]# virsh create rhel7.xml error: Failed to create domain from rhel7.xml error: internal error: libxenlight failed to create new domain 'rhel7'
Moving to the upstream tracker jfehlig, any thoughts on this bug?
<driver name='tap'> requires the blktap driver. Does the dom0 kernel contain a blktap driver? /var/log/libvirt/libxl/libxl-driver.log and/or /var/log/libvirt/libxl/<domain-name>.log should contain more information about the error. Also, is there a reason to use the tap driver? Is it possible to use <driver name='qemu' type='raw'/> instead?
(In reply to Jim Fehlig from comment #7) > <driver name='tap'> requires the blktap driver. Does the dom0 kernel contain > a blktap driver? /var/log/libvirt/libxl/libxl-driver.log and/or > /var/log/libvirt/libxl/<domain-name>.log should contain more information > about the error. Setting NEEDINFO, lliu please see provide this info > Also, is there a reason to use the tap driver? Is it possible to use <driver > name='qemu' type='raw'/> instead? This default may be coming from virt-manager which has had it for a looooong time; if guest is PV, disk type=file, and the host has blktap loaded, we use it. But it's likely from the rhel5 xen timeframe... Jim do you think that default still makes sense? or is there a better general purpose default and instead we just let users manually specify blktap if they want it. (dropping the default would be nice since it's one of the last checks we do that's specific to the local machine, since libvirt doesn't advertise anything about blktap support for remote connections)
(In reply to Cole Robinson from comment #8) > Jim do you think that default still makes sense? or is there a better > general purpose default and instead we just let users manually specify > blktap if they want it. I think the best default for image files would be the same between qemu/kvm and xen. I.e. <driver name='qemu' type='qcow2|raw|vhd|...'/> For block devices on xen, the best default would still be <driver name='phy'/>
(In reply to Jim Fehlig from comment #9) > (In reply to Cole Robinson from comment #8) > > Jim do you think that default still makes sense? or is there a better > > general purpose default and instead we just let users manually specify > > blktap if they want it. > > I think the best default for image files would be the same between qemu/kvm > and xen. I.e. > > <driver name='qemu' type='qcow2|raw|vhd|...'/> > Thanks Jim! Just to clarify, this works for both hvm and pv? > For block devices on xen, the best default would still be > > <driver name='phy'/> Cool. hvm and pv as well? and is this only for raw formatted block devices?
(In reply to Cole Robinson from comment #10) > (In reply to Jim Fehlig from comment #9) > > I think the best default for image files would be the same between qemu/kvm > > and xen. I.e. > > > > <driver name='qemu' type='qcow2|raw|vhd|...'/> > > > > Thanks Jim! > > Just to clarify, this works for both hvm and pv? Yes. > > > For block devices on xen, the best default would still be > > > > <driver name='phy'/> > > Cool. hvm and pv as well? and is this only for raw formatted block devices? Yes and yes :-). 'phy' maps to Xen's good 'ol blkbk driver, which only supports the raw format.
(In reply to Jim Fehlig from comment #7) > <driver name='tap'> requires the blktap driver. Does the dom0 kernel contain > a blktap driver? /var/log/libvirt/libxl/libxl-driver.log and/or > /var/log/libvirt/libxl/<domain-name>.log should contain more information > about the error. > Hi Jim, No, it doesn't contain the blktap driver in dom0 kernel. I am trying to install the blktap-3.0.0-3.fc22.git0.9.2.x86_64.rpm, there is a bug https://bugzilla.redhat.com/show_bug.cgi?id=1150546 block the installation. I will try to install and insert blktap driver and try this case again after this bug is fixed. > Also, is there a reason to use the tap driver? Is it possible to use <driver > name='qemu' type='raw'/> instead? It's a case to test all kinds of drivers the host and guest supported, the tap driver is one of them. I have tried <driver name='qemu' type='raw'/>, it's OK but qemu and tap are using different driver, so it could not instead the tap driver testing. Thanks Lin Liu
(In reply to Lin Liu from comment #12) > It's a case to test all kinds of drivers the host and guest supported, the > tap driver is one of them. Does the pvops kernel even have an actively maintained blktap driver? AFAIK, blktap1 and blktap2 are dead/dieing. The blktap1 userspace code has been removed from xen.git master. blktap2 will probably be removed in the Xen 4.7 dev cycle http://lists.xen.org/archives/html/xen-devel/2015-07/msg00805.html http://lists.xen.org/archives/html/xen-devel/2015-07/msg00808.html IMO, use of blktap drivers should be discouraged in favor of the qdisk backend (<driver name='qemu'/>) or the blkbk backend (<driver name='phy'/>).
FWIW I pushed this commit to virt-manager based on our discussion: commit 7c10d8a27f0f635c185d1b85d6d26120d51c8aa2 Author: Cole Robinson <crobinso> Date: Wed Sep 23 17:26:48 2015 -0400 devicedisk: Tweak driver defaults for xen Following some discussion here: https://bugzilla.redhat.com/show_bug.cgi?id=1171550 jfehlig suggested better defaults for modern xen. End result is: - Drop the blktap check, since it's deprecated (yaay) - If xen + block device, use driver_name=phy - Otherwise if on modern enough libvirt + libxl, do the same thing we do for qemu.
Given that use of blktap is discouraged, and the virt-manager default changed, I don't think this is important to track anymore