SELinux is preventing /usr/bin/virsh from using the 'setpcap' capabilities. ***** Plugin catchall (100. confidence) suggests *************************** If you believe that virsh should have the setpcap capability by default. Then you should report this as a bug. You can generate a local policy module to allow this access. Do allow this access for now by executing: # grep virsh /var/log/audit/audit.log | audit2allow -M mypol # semodule -i mypol.pp Additional Information: Source Context unconfined_u:system_r:virsh_t:s0 Target Context unconfined_u:system_r:virsh_t:s0 Target Objects Unknown [ capability ] Source virsh Source Path /usr/bin/virsh Port <Unknown> Host (removed) Source RPM Packages libvirt-client-0.8.3-2.fc14 Target RPM Packages Policy RPM selinux-policy-3.9.7-29.fc14 Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Host Name (removed) Platform Linux (removed) 2.6.35.10-74.fc14.x86_64 #1 SMP Thu Dec 23 16:04:50 UTC 2010 x86_64 x86_64 Alert Count 1 First Seen Sat 05 Feb 2011 12:15:31 PM EST Last Seen Sat 05 Feb 2011 12:15:31 PM EST Local ID 06517710-55f1-4d9e-9456-dc5afd3228be Raw Audit Messages type=AVC msg=audit(1296926131.119:64039): avc: denied { setpcap } for pid=548 comm="virsh" capability=8 scontext=unconfined_u:system_r:virsh_t:s0 tcontext=unconfined_u:system_r:virsh_t:s0 tclass=capability type=SYSCALL msg=audit(1296926131.119:64039): arch=x86_64 syscall=prctl success=no exit=EPERM a0=18 a1=0 a2=0 a3=0 items=0 ppid=546 pid=548 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=42 comm=virsh exe=/usr/bin/virsh subj=unconfined_u:system_r:virsh_t:s0 key=(null) Hash: virsh,virsh_t,virsh_t,capability,setpcap audit2allow #============= virsh_t ============== allow virsh_t self:capability setpcap; audit2allow -R #============= virsh_t ============== allow virsh_t self:capability setpcap;
Issuing a "clusvcadm -M vm:<name> -m <target>" results in the setpcap denial reported at the beginning of the migration process (starting the source target qemu instance). The denial does not occur if the live migration is performed using the "# virsh migrate --live" command. The denial does not appear to prevent the migration from completing.
This indicates that virsh is dropping capabilities? Daniel does it drop capabilities now?
virsh itself doesn't drop capabilities, but if it forks a helper program, there may be cases where it drops capabilities inbetween the fork+exec path. I can't remember if there are any such cases in virsh offhand though. What libvirt driver URI is being used by clusvcadm ? It would help to get a debug trace by setting the env variables LIBVIRT_LOG_FILTERS="1:libvirt 1:util" LIBVIRT_LOG_OUTPUTS="1:file:/var/log/libvirt/virsh.log" in clusvcadm when issuing the virsh commands.
I attempted to set the env variables in the shell where I executed the clusvcadm command, but got no output to a log file in /var/log/libvirt: [root ~]# export LIBVIRT_LOG_FILTERS="1:libvirt 1:util" [root ~]# export LIBVIRT_LOG_OUTPUTS="1:file:/var/log/libvirt/virsh.log" [root ~]# env | grep LIBVIRT LIBVIRT_LOG_FILTERS=1:libvirt 1:util LIBVIRT_LOG_OUTPUTS=1:file:/var/log/libvirt/virsh.log [root ~]# clusvcadm -M vm:vm1 -m host2 Trying to migrate vm:vm1 to host2...Success [root ~]# clusvcadm -M vm:vm1 -m host1 Trying to migrate vm:vm1 to host1...Success [root ~]# ls -lart /var/log/libvirt/ total 20 drwx------. 2 root root 4096 Aug 23 17:32 uml drwx------. 2 root root 4096 Aug 23 17:32 lxc drwx------. 5 root root 4096 Jan 31 01:02 . drwx------. 2 root root 4096 Jan 31 15:28 qemu drwxr-xr-x. 19 root root 4096 Feb 6 03:12 .. [root ~]#
The alert says /usr/bin/virsh executed the prctl syscall resulting in a setpcap access check. Since it has setcap already I thine we should add setpcap.
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
F14 is EOL, please reopen if this is still relevant in a more recent fedora.