This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux major release.  Product Management has requested further
review of this request by Red Hat Engineering, for potential inclusion in a Red
Hat Enterprise Linux Major release.  This request is not yet committed for
inclusion.

When the SELinux is running in permissive mode, and the VM is running, can you show me

# ls -alZ /var/lib/libvirt/qemu/

And

# ps -axuwfZ | grep qemu-kvm

# ls -alZ /var/lib/libvirt/qemu/
drwxrwxrwx. vdsm kvm  system_u:object_r:svirt_var_run_t:s0 .
drwxr-xr-x. root root system_u:object_r:virt_var_lib_t:s0 ..
srwxr-xr-x. vdsm kvm  unconfined_u:object_r:svirt_var_run_t:s0 barak-xp.monitor
drwxr-xr-x. vdsm kvm  system_u:object_r:svirt_var_run_t:s0 save
drwxr-xr-x. vdsm kvm  system_u:object_r:svirt_var_run_t:s0 snapshot

# ps axuwfZ | grep qemu
unconfined_u:system_r:qemu_t:s0-s0:c0.c1023 vdsm 18065 10.4 17.3 2562664 2120728 ? Sl 18:09   8:43 /usr/libexec/qemu-kvm -S -M rhel6.0.0 -cpu qemu64,-svm,-nx -enable-kvm -m 2048 -smp 1,sockets=1,cores=1,threads=1 -name barak-xp -uuid 09abc572-d080-442e-a139-f70a817302b7 -nodefaults -chardev socket,id=monitor,path=/var/lib/libvirt/qemu/barak-xp.monitor,server,nowait -mon chardev=monitor,mode=control -rtc base=2010-5-1T18:9:4 -boot cn -device virtio-serial-pci,id=virtio-serial0,max_ports=16,bus=pci.0,addr=0x5 -drive file=/rhev/data-center/606d043c-ef9c-4c6f-848b-5bd89325c78d/d58d83c5-5008-4906-9c44-bb9915428327/images/056480d6-ea9a-4ee9-a678-d39f7a9713a3/0c936f3f-7d2e-4002-a136-3dd95408950d,if=none,id=drive-ide0-0-0,boot=on,format=qcow2,serial=e9-a678-d39f7a9713a3,cache=none -device ide-drive,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0 -netdev tap,fd=20,id=hostnet0 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=00:1a:4a:23:71:0c,bus=pci.0,addr=0x4 -chardev socket,id=channel0,path=/var/run/vdsm/09abc572-d080-442e-a139-f70a817302b7.guest.socket,server,nowait -device virtserialport,chardev=channel0,name=org.linux-kvm.port.0 -usb -spice port=5900,tls-port=5901,addr=0,x509-dir=/etc/pki/libvirt-spice,tls-channel=main,tls-channel=inputs -k en-us -vga qxl -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x3

It looks like the labelling on your /var/lib/libvirt/qemu directory is incorrect. The policy defines it as system_u:object_r:qemu_var_run_t:s0, rather than svirt_var_run_t. Please update to at least

  selinux-policy-targeted-3.7.19-21.el6.noarch

And then

  touch /.autorelabel 

and reboot the whole machine. Hopefully that should fix your host labelling.

Thanks. upgrade and relabeling solves the monitor socket issue, but not that of

# ls -lZ /var/run/vdsm/9ffe28b6-6134-4b1e-8804-1185f49c436f.guest.socket
srwxr-xr-x. vdsm kvm system_u:object_r:var_run_t:s0   /var/run/vdsm/9ffe28b6-6134-4b1e-8804-1185f49c436f.guest.socket

generated due to the device

<controller index="0" ports="16" type="virtio-serial"/>
<channel type="unix">
    <target name="org.linux-kvm.port.0" type="virtio"/>
    <source mode="bind" path="/var/run/vdsm/9ffe28b6-6134-4b1e-8804-1185f49c436f.guest.socket"/>
</channel>

The VM channel has the same problem - '/var/run/vdsm' is not labeled with 'qemu_var_run_t', so QEMU will be unable to create the channel's UNIX socket in that location. Unfortunately UNIX sockets cannot be pre-created by libvirt, so we can't label them ahead of time, thus the only option is to make sure they're in a directory labelled 'qemu_var_run_t'.

I see 3 options

 1. Have VDSM deploy an addon selinux policy module that labels '/var/run/vdsm' as 'qemu_var_run_t'
 2. Have VSDM set the vmchannel path to /var/lib/libvirt/qemu/...something...
 3. Have VSDM set the vmchannel path to /var/lib/libvirt/qemu/channels/...something...

My recommendation is for option 3, and to use the VM name  + channel target as the filename, eg

  /var/lib/libvirt/qemu/channels/barak-xp.org.linux-kvm.port.0


libvirt uses & recommends VM name for all files, since it is just as unique as a UUID, and much more friendly for admins. The use of the channel target also to make it clear what the socket is for.

Ok, I'll try to take your suggestion 3.

I wish everyone was as elaborate and helpful as you are. Much better than the approach taken in bug 594068 comment 7.

verified, however, there is one exception; as I configured 'virt_use_nfs'=on manually, though it should be configured by vdsm. 
with this change, I am able to run vm with selinux on both iscsi and nfs. 

checked audid.log and there was no AVC.

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHEA-2011-1782.html