This looks like libvirt did not label the device correctly.

Please attach the following to the bug report:

1) the output of "virsh dumpxml $guestname --inactive"
2) The last several lines of /var/log/libvirt/qemu/$guestname.log
3) Any messages from /var/log/libvirt/libvirtd.log from around the time of this failure.

Thanks for the reply. Since posting this I've made quite a few changes to the guest and built a few selinux modules around it also.

I'll look to recreate it and provide the detail you're asking for but it should be easily doable with:

* create vm using the virt-manager create wizard
* before beginning installation, alter the configuration
* change the NIC from NAT to macvtap (eth0 in my case), VEPA
* attempt to boot the new guest.

Regards

This probably isn't relevant to the bug, but I do you actually have a VEPA capable switch, and if so, do you have lldpad installed? These are still very rare in the wild, and 90% of the time I see somebody using VEPA mode, it is in error - if you are connected to any switch that doesn't specifically support VEPA, you should instead use 'bridge' or 'private' mode (depending on whether you want the guests to be able to directly communicate with each other without bouncing all traffic off the switch)

I'm receiving this error on RHEL 6 as well.. The key is the Selinux deny log entry.   creating a new semodule with the following resolves the issue (run audit2allow -M libvirt-tap on the log in the OP )

module libvirt-tap 1.0;

require {
        type device_t;
        type svirt_t;
        class chr_file { read write };
}

#============= svirt_t ==============
allow svirt_t device_t:chr_file { read write };

Edward, are you seeing this issue when trying to start the VM? Can you provide the VM XML of the offending VM? sudo virsh dumpxml $vmname

Created attachment 590296 [details]
"offending vm xml config"

I've attached the XML setup for the offending VM..

Thanks Edward.

Here's the network bit:

    <interface type='direct'>
      <mac address='52:54:00:ae:5e:08'/>
      <source dev='eth0' mode='bridge'/>
      <target dev='macvtap0'/>
      <alias name='net0'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/>
    </interface>

I actually can't reproduce this on F17, so closing as WORKSFORME.

Edward, if you are still seeing this on RHEL6, please file a bug there or follow up with RH support.

If anyone can reproduce on F17+, please reopen.

As a matter of fact, we just recently figured out (on RHEL6, but it is a verified problem in F17, F18, and Rawhide as well) that there was a race condition when macvtap devices are created that can cause an selinux AVC failure if the new device's fd is passed to qemu too quickly. The problem is that the kernel creates macvtap devices with the label device_t, and relies on udev to asynchronously notice this and relabel them to tun_tap_device_t (which is the label that qemu has permissions for). If udev was excessively slow to notice and take action, or libvirt was excessively quick to pass the device's fd off to qemu, qemu would fail in exactly the manner described here.

The solution is to add code to libvirt to relabel each newly created macvtap device with the selinux label *it should have had to begin with* (the effect is just to guarantee the default label is in place before using the fd).

This was reported against RHEL6 in Bug 851981 and fixed upstream in several patches (there were a couple prerequisites, and a few missteps in figuring out the correct fix). Unfortunately it seems non-trivial to backport these patches to the 0.9.11-maint branch for F17 (much less to v0.9.6-maint for F16), since the security driver code went through a major refactoring just before 0.10.0.

These patches *can* easily be applied on top of 0.10.2, though, and that will probably be the maintenance branch for F18, so I'm changing the Fedora version of this bug to F18 and setting it to POST (but not pushing the patches to v0.10.2-maint until verifying that's what will be F18)

commit 9674f2c637114fa6ac0680fe5658a41a62bb34a8
Author: Martin Kletzander <mkletzan@redhat.com>
Date:   Fri Oct 5 16:41:22 2012 +0200

    selinux: Use raw contexts

commit ae368ebfcc4923d0b32e83d4ca96a6f599625785
Author: Guannan Ren <gren@redhat.com>
Date:   Mon Oct 15 17:03:49 2012 +0800

    selinux: add security selinux function to label tapfd
    
    When using macvtap, a character device gets first created by
    kernel with name /dev/tapN, its selinux context is:
    system_u:object_r:device_t:s0
    
    Shortly, when udev gets notification when new file is created
    in /dev, it will then jump in and relabel this file back to the
    expected default context:
    system_u:object_r:tun_tap_device_t:s0
    
    There is a time gap happened.
    Sometimes, it will have migration failed, AVC error message:
    type=AVC msg=audit(1349858424.233:42507): avc:  denied  { read write } for
    pid=19926 comm="qemu-kvm" path="/dev/tap33" dev=devtmpfs ino=131524
    scontext=unconfined_u:system_r:svirt_t:s0:c598,c908
    tcontext=system_u:object_r:device_t:s0 tclass=chr_file
    
    This patch will label the tapfd device before qemu process starts:
    system_u:object_r:tun_tap_device_t:MCS(MCS from seclabel->label)

commit 89b63f0ad448a0442f4afc5489748e2cc829e527
Author: Guannan Ren <gren@redhat.com>
Date:   Wed Oct 17 11:23:19 2012 +0800

    selinux: fix wrong tapfd relablling
    
    It should relabel tapfd of virtual network of type VIR_DOMAIN_NET_TYPE_DIRECT
    rather than VIR_DOMAIN_NET_TYPE_NETWORK and VIR_DOMAIN_NET_TYPE_BRIDGE
    (commit ae368ebfcc4923d0b32e83d4ca96a6f599625785 introduced this bug)
    
    Caution: The context of the two hunks is identical other than indentation.
    Please be extremely cautious of where the patch gets applied.

commit 6676c1fc8fb297de998f96862cbe2396355b2777
Author: Martin Kletzander <mkletzan@redhat.com>
Date:   Mon Oct 15 14:04:36 2012 +0200

    selinux: Use raw contexts 2
    
    In commit 9674f2c637114fa6ac0680fe5658a41a62bb34a8, I forgot to change
    selabel_lookup with the other functions, so this one-liner does exactly
    that.

commit d37a3a1d6c6508f235965185453602ba310cc66e
Author: Guannan Ren <gren@redhat.com>
Date:   Wed Oct 17 11:28:28 2012 +0800

    selinux: remove unused variables in socket labelling

commit 4492ef7f485a7d42d84a714d2150e648b11e2740
Author: Guannan Ren <gren@redhat.com>
Date:   Fri Oct 19 16:44:30 2012 +0800

    selinux: relabel tapfd in qemuPhysIfaceConnect
    
    Relabeling tapfd right after the tap device is created.
    qemuPhysIfaceConnect is common function called both for static
    netdevs and for hotplug netdevs.

Cool Laine, thanks for the diligence!

libvirt-0.10.2.1-1.fc18 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/libvirt-0.10.2.1-1.fc18

Package libvirt-0.10.2.1-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.1-1.fc18'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2012-17097/libvirt-0.10.2.1-1.fc18
then log in and leave karma (feedback).

libvirt-0.10.2.1-2.fc18 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/libvirt-0.10.2.1-2.fc18

libvirt-0.10.2.1-2.fc18 now in stable