Bug 1171550

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