Created attachment 1454512 [details] Failure message Description of problem: On virt-manager, when I add a host filesystem to mount onto the guest, qemu fails to start. This happens even with 777 permissions on the host directory. Version-Release number of selected component (if applicable): 1.4.3 How reproducible: every time Steps to Reproduce: 1. Cuing root, create a /vmshare directory with 777 permissions. This should exclude any permission issues. 2. Create a Linux VM in virt-manager and ensure that the VM starts normally. Shut down the VM. 3. Double-click the VM in virt-manager to open it. Click the bulb to edit settings. 4. Click Add Hardware, then Filesystem 5. enter /vmshare for both source and target paths Actual results: qemu fails to start, screenshot attached Expected results: qemu starts; if the VM kernel supports p9fs, the directory can be mounted in the guest. Additional info:
Thanks for the report. Please provide: sudo virsh dumpxml $vmname Do you have selinux enabled? Does 'sudo setenforce 0' make it work?
selinux is enabled and with "sudo setenforce 0" the VM boots. After "sudo setenforce 1" the problem returns. attaching virsh dumpxml output
Created attachment 1454795 [details] virsh dumpxml output
Also I have upgraded to Fedora 28 today and nothing has changed. I have changed the Fedora version in this bug to 28 to avoid the bug being closed at EOL of Fedora 27. In reality it applies to both versions as far as I can see.
Yeah so this is selinux. If you create a directory /vmshare, it gets the default selinux label, which qemu is restricted from accessing. libvirt will relabel individual disk images in a case like this, but it's not wired up to do so for <filesystem> directories. The workaround is to create the filesystem dir in /var/lib/libvirt/filesystems/... which is set up to give all subfiles the proper selinux label. Or move your vmshare directory there and manually relabel it to unconfined_u:object_r:virt_var_lib_t:s0
This message is a reminder that Fedora 28 is nearing its end of life. On 2019-May-28 Fedora will stop maintaining and issuing updates for Fedora 28. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '28'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 28 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Since this is an selinux thing there's not much virt-manager can do. When virt-fs lands upstream and gets wider usage I imagine the virt stack will revisit this issue and maybe solve it at the libvirt level. But it's not really a virt-manager issue