Description of problem: If selinux is in enforcing more, KVM guest start process fails either through virt-manager or virsh with the following libvirt error. File "/usr/lib64/python2.6/site-packages/libvirt.py", line 973, in createLinux if ret is None:raise libvirtError('virDomainCreateLinux() failed', conn=self) libvirtError: internal error Domain guest01 didn't show up Version-Release number of selected component (if applicable): # rpm -qa|grep kvm kvm-83-84.el5 kvm-tools-83-84.el5 etherboot-zroms-kvm-5.4.4-10.el5 kvm-qemu-img-83-84.el5 kmod-kvm-83-84.el5 #rpm -q libvirt libvirt-0.6.3-13.el5 These versions are newer than whats in production beta channels. How reproducible: always Steps to Reproduce: 1. Shutdown a guest 2. Try to start the guest either through virt-manager or virsh cat /var/log/libvirt/qemu/guest01.log LC_ALL=C PATH=/sbin:/usr/sbin:/bin:/usr/bin /usr/libexec/qemu-kvm -S -M pc -m 512 -smp 1 -name guest01 -uuid 3a51fe73-221b-ed07-7da9-73b23c22aeeb -monitor pty -pidfile /var/run/libvirt/qemu//guest01.pid -boot c -drive file=/var/lib/libvirt/images/guest01,if=ide,index=0,boot=on -net nic,macaddr=00:16:3e:69:fa:97,vlan=0 -net tap,fd=20,script=,vlan=0,ifname=vnet2 -serial pty -parallel none -usb -vnc 127.0.0.1:3 -k en-us Could not acquire pid file 3. Set selinux to permissive and guest start works as expected. audit.log has these denials while writing the pid file if it helps: type=SYSCALL msg=audit(1247149852.415:32724): arch=c000003e syscall=2 success=yes exit=4 a0=7fff895b4eb9 a1=42 a2=180 a3=0 items=0 ppid=1 pid=12107 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4097 comm="qemu-kvm" exe="/usr/libexec/qemu-kvm" subj=root:system_r:qemu_t:s0-s0:c0.c1023 key=(null) type=AVC msg=audit(1247149852.415:32725): avc: denied { lock } for pid=12107 comm="qemu-kvm" path="/var/run/libvirt/qemu/guest02.pid" dev=dm-0 ino=15564838 scontext=root:system_ r:qemu_t:s0-s0:c0.c1023 tcontext=root:object_r:virt_var_run_t:s0 tclass=file type=SYSCALL msg=audit(1247149852.415:32725): arch=c000003e syscall=72 success=yes exit=0 a0=4 a1=6 a2=7fff895b2480 a3=0 items=0 ppid=1 pid=12107 auid=0 uid=0 gid=0 euid=0 suid=0 f suid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4097 comm="qemu-kvm" exe="/usr/libexec/qemu-kvm" subj=root:system_r:qemu_t:s0-s0:c0.c1023 key=(null) type=AVC msg=audit(1247149852.415:32726): avc: denied { write } for pid=12107 comm="qemu-kvm" path="/var/run/libvirt/qemu/guest02.pid" dev=dm-0 ino=15564838 scontext=root:system _r:qemu_t:s0-s0:c0.c1023 tcontext=root:object_r:virt_var_run_t:s0 tclass=file type=SYSCALL msg=audit(1247149852.415:32726): arch=c000003e syscall=1 success=yes exit=6 a0=4 a1=7fff895b24b0 a2=6 a3=0 items=0 ppid=1 pid=12107 auid=0 uid=0 gid=0 euid=0 suid=0 fs uid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4097 comm="qemu-kvm" exe="/usr/libexec/qemu-kvm" subj=root:system_r:qemu_t:s0-s0:c0.c1023 key=(null) type=USER_ACCT msg=audit(1247149921.433:32727): user pid=12139 uid=0 auid=0 subj=root:system_r:crond_t:s0-s0:c0.c1023 msg='PAM: accounting acct="root" : exe="/usr/sbin/crond" (host name=?, addr=?, terminal=cron res=success)'
We also need the version of selinux pilicies installed, what's the output of rpm -qa | grep selinux ? Daniel
From those AVC messages this just looks like RHEL-5 selinux policy needs more of the QEMU / libvirt rules backported from Fedora policy
What version of selinux-policy are you using /var/run/libvirt/qemu is supposed to be labeled qemu_var_run_t If you run restorecon -R -v /var/lib/libvirt/qemu Does it fix the labels? selinux-policy-2.4.6-249.el5 is the latest policy.
These are the selinux versions installed on my kvm host. # rpm -qa|grep selinux-policy selinux-policy-2.4.6-249.el5 selinux-policy-devel-2.4.6-249.el5 selinux-policy-targeted-2.4.6-249.el5
Also forgot to mention, this is an upgraded client from RHEL-5u3 -> 5.4 + kvm with Enforcing all the way. Not sure if that makes a difference.
Did restorecon -R -v /var/lib/libvirt/qemu change the labeling?
ls -lZ /var/lib/libvirt/qemu matchpathcon /var/lib/libvirt/qemu
I believe this is fixed and the policy is not up to date or there is a labeling problem. Could you test this with the latest rhel5 policy selinux-policy-2.4.6-252.el5