Bug 1558836

I reproduced the issue on my env.
It is a SELinux issue.
If I disable SELinux on the host running the VM, the VM starts successfully.

ausearch -m AVC,USER_AVC -ts recent

type=PROCTITLE msg=audit(1527583258.543:92781): proctitle=2F7573722F6C6962657865632F71656D752D6B766D002D6E616D650067756573743D434550484653564D2C64656275672D746872656164733D6F6E002D53002D6F626A656374007365637265742C69643D6D61737465724B6579302C666F726D61743D7261772C66696C653D2F7661722F6C69622F6C6962766972742F71656D
type=SYSCALL msg=audit(1527583258.543:92781): arch=c000003e syscall=2 success=no exit=-13 a0=55a5c41931e0 a1=80800 a2=0 a3=fffffffffffff498 items=0 ppid=1 pid=11716 auid=4294967295 uid=107 gid=107 euid=107 suid=107 fsuid=107 egid=107 sgid=107 fsgid=107 tty=(none) ses=4294967295 comm="qemu-kvm" exe="/usr/libexec/qemu-kvm" subj=system_u:system_r:svirt_t:s0:c440,c805 key=(null)
type=AVC msg=audit(1527583258.543:92781): avc:  denied  { read } for  pid=11716 comm="qemu-kvm" name="36b34034-5b5b-454d-a117-0f71129c9493" dev="ceph" ino=1099511627789 scontext=system_u:system_r:svirt_t:s0:c440,c805 tcontext=system_u:object_r:cephfs_t:s0 tclass=file
----
time->Tue May 29 11:40:58 2018
type=PROCTITLE msg=audit(1527583258.543:92782): proctitle=2F7573722F6C6962657865632F71656D752D6B766D002D6E616D650067756573743D434550484653564D2C64656275672D746872656164733D6F6E002D53002D6F626A656374007365637265742C69643D6D61737465724B6579302C666F726D61743D7261772C66696C653D2F7661722F6C69622F6C6962766972742F71656D
type=SYSCALL msg=audit(1527583258.543:92782): arch=c000003e syscall=4 success=no exit=-13 a0=55a5c41931e0 a1=7ffd1106f400 a2=7ffd1106f400 a3=fffffffffffff498 items=0 ppid=1 pid=11716 auid=4294967295 uid=107 gid=107 euid=107 suid=107 fsuid=107 egid=107 sgid=107 fsgid=107 tty=(none) ses=4294967295 comm="qemu-kvm" exe="/usr/libexec/qemu-kvm" subj=system_u:system_r:svirt_t:s0:c440,c805 key=(null)
type=AVC msg=audit(1527583258.543:92782): avc:  denied  { getattr } for  pid=11716 comm="qemu-kvm" path="/rhev/data-center/mnt/10.35.1.36:6789:_ovirt/56c92d21-d086-4692-9835-29edb47ee522/images/3b95e159-d4a3-4491-91dc-3bfdc1e5f1f4/36b34034-5b5b-454d-a117-0f71129c9493" dev="ceph" ino=1099511627789 scontext=system_u:system_r:svirt_t:s0:c440,c805 tcontext=system_u:object_r:cephfs_t:s0 tclass=file
----
time->Tue May 29 11:40:58 2018
type=PROCTITLE msg=audit(1527583258.543:92783): proctitle=2F7573722F6C6962657865632F71656D752D6B766D002D6E616D650067756573743D434550484653564D2C64656275672D746872656164733D6F6E002D53002D6F626A656374007365637265742C69643D6D61737465724B6579302C666F726D61743D7261772C66696C653D2F7661722F6C69622F6C6962766972742F71656D
type=SYSCALL msg=audit(1527583258.543:92783): arch=c000003e syscall=2 success=no exit=-13 a0=55a5c41931e0 a1=84002 a2=0 a3=0 items=0 ppid=1 pid=11716 auid=4294967295 uid=107 gid=107 euid=107 suid=107 fsuid=107 egid=107 sgid=107 fsgid=107 tty=(none) ses=4294967295 comm="qemu-kvm" exe="/usr/libexec/qemu-kvm" subj=system_u:system_r:svirt_t:s0:c440,c805 key=(null)
type=AVC msg=audit(1527583258.543:92783): avc:  denied  { read write } for  pid=11716 comm="qemu-kvm" name="36b34034-5b5b-454d-a117-0f71129c9493" dev="ceph" ino=1099511627789 scontext=system_u:system_r:svirt_t:s0:c440,c805 tcontext=system_u:object_r:cephfs_t:s0 tclass=file

journalctl

May 29 11:40:58 vdsm42 systemd[1]: Started Virtual Machine qemu-5-CEPHFSVM.
May 29 11:40:58 vdsm42 systemd-machined[13090]: New machine qemu-5-CEPHFSVM.
May 29 11:40:58 vdsm42 systemd[1]: Starting Virtual Machine qemu-5-CEPHFSVM.
May 29 11:40:58 vdsm42 kvm[11721]: 1 guest now active
May 29 11:40:58 vdsm42 libvirtd[18910]: 2018-05-29 08:40:58.556+0000: 18910: error : qemuMonitorIORead:588 : Unable to read from monitor: Connection reset by peer
May 29 11:40:58 vdsm42 libvirtd[18910]: 2018-05-29 08:40:58.556+0000: 18910: error : qemuProcessReportLogError:1862 : internal error: qemu unexpectedly closed the monitor: 2018-05-29T08:40:58.544994Z qemu-kvm: -
May 29 11:40:58 vdsm42 kvm[11723]: 0 guests now active
May 29 11:40:58 vdsm42 systemd-machined[13090]: Machine qemu-5-CEPHFSVM terminated.
May 29 11:40:58 vdsm42 libvirtd[18910]: 2018-05-29 08:40:58.757+0000: 18913: error : qemuProcessReportLogError:1862 : internal error: process exited while connecting to monitor: 2018-05-29T08:40:58.544994Z qemu-
May 29 11:40:58 vdsm42 vdsm[19103]: WARN File: /var/lib/libvirt/qemu/channels/3738a61b-8a75-42e2-be00-7d0c9fea50c0.ovirt-guest-agent.0 already removed
May 29 11:40:58 vdsm42 vdsm[19103]: WARN File: /var/lib/libvirt/qemu/channels/3738a61b-8a75-42e2-be00-7d0c9fea50c0.org.qemu.guest_agent.0 already removed

# cat /etc/redhat-release 
CentOS Linux release 7.5.1804 (Core) 
# rpm -qa | grep selin
libselinux-2.5-12.el7.i686
libselinux-2.5-12.el7.x86_64
selinux-policy-targeted-3.13.1-192.el7_5.3.noarch
libselinux-python-2.5-12.el7.x86_64
libselinux-utils-2.5-12.el7.x86_64
selinux-policy-3.13.1-192.el7_5.3.noarch

Lukas,
Can you take a look at this issue?

You handled something similar here:
https://bugzilla.redhat.com/show_bug.cgi?id=1315332

Thanks

Lukas, any updates?

Hi, 

It's bug int SELinux policy, will fix it.

*** Bug 1685799 has been marked as a duplicate of this bug. ***

# rpm -qa selinux\* | sort
selinux-policy-3.13.1-244.el7.noarch
selinux-policy-devel-3.13.1-244.el7.noarch
selinux-policy-targeted-3.13.1-244.el7.noarch
# sesearch -s svirt_t -t cephfs_t -A
Found 6 semantic av rules:
   allow virt_domain file_type : dir { getattr search open } ; 
   allow virt_domain cephfs_t : dir { getattr search open } ; 
   allow virt_domain cephfs_t : file { ioctl read write getattr lock append open } ; 
   allow domain file_type : file map ; 
   allow domain file_type : chr_file map ; 
   allow domain file_type : blk_file map ; 

#

There is no allow rule for lnk_file. SELinux denial which affects the lnk_file class is not recorded in this bug, but I believe that such allow rule should be also added to policy.

If following rule is not present, then svirt_t processes cannot read symbolic links stored on CephFS and that could be a problem for users.

When selinux-policy-3.13.1-235.el7 will be released? oVirt still have issue even with ISO domains.

A fix for this bugzilla should be a part of RHEL 7.7 which is expected to go general availability later this quarter.

*** Bug 1724018 has been marked as a duplicate of this bug. ***

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.

https://access.redhat.com/errata/RHBA-2019:2127

Works for me at el 7.7, thanks Zdenek.