Reputation: 8173
This only happens on Fedora, on ubuntu it works fine.
I have a VM contain a symlink point to actual image. When I start the vm, it error out due to permission denied:
error: internal error: process exited while connecting to monitor: 2020-10-15T19:24:24.359891Z qemu-system-x86_64: -drive file=/some-local-pool/VM01.current,format=qcow2,if=none,id=drive-virtio-disk0,cache=unsafe,discard=unmap,aio=threads: Could not open '/some-local-pool/VM01.current': Permission denied
But the permission is fine:
lrwxrwxrwx. 1 root root 32 Oct 15 20:37 VM01.current -> VM01.deployed
-rw-rw-r--. 1 root root 20G Oct 15 21:01 VM01.deployed
unconfined_u:object_r:unlabeled_t:s0 VM01.current
system_u:object_r:default_t:s0 VM01.deployed
Directly use the actual image path works. qemu-img info on the symlink works too. Any idea why this won't work?
Upvotes: 0
Views: 684
Reputation: 2816
When libvirt runs QEMU, it is given a unique SELinux label that is specific to that VM instance. In order for this to work, libvirt has to set the SELinux label on every disk image that QEMU is intended to access prior to QEMU being started. The label that libvirt sets will apply to the real disk image (VM01.deployed), but not the symlink (VM01.current) which you need to set to virt_image_t/virt_content_t.
Upvotes: 0
Reputation: 8173
it is the selinux context problem. Somehow, the VM01.deployed get wrong type of default_t if start the VM with it. We need to change it to virt_content_t, if we want the symlink as image path.
Moreover, the label of symlink itself need to match the target.
# chcon --reference=VM01.deployed VM01.current
Then it is going to work.
It is still not clear why use the VM01.deployed as image path can still work if type label is default_t.
So far if we use libvirt and qemu tools to create new qcow2 disk or snapshots. The labels can be many things: default_t, virt_image_t, virt_content_t ... no idea why cannot they all agree on one type. This is really confusing.
Upvotes: 1