In Fedora 39, libvirtd work correctly, exactly as expected. But after rebasing to Fedora 40, I start seeting SELinux errors. When SELinux is enabled, trying to create or use a libvirtd VM fails with “Permission Denied” errors. As soon as I disable SELinux, everything works fine. This is not the case with Silverblue. In Silverblue, libvirtd works correctly with SELinux out of the box without needing to disable it.
The Bluefin just file for enabling Incus does specify that SELinux has to be disabled in order for Incus to work, however that’s also different from Silverblue. In Silverblue, Incus works out of the box without needing to disable SELinux.
Maybe you should try installing Bluefin-DX. There are few kinks in Bluefin - in my experience - but definitely everything works in Bluefin-DX. I am still testing every environment. Virtual Manager works very reliably. Just don’t forget to activate the admin group for virtualization with ujust dx-group
I didn’t specify but I am using Bluefin-DX. I’m added to the proper groups but it doesn’t make a difference, even root has the same problem.
This is a root shell, you can see that when SELinux is enabled, I’m unable to create a VM due to a virtlogd error. As soon as I disable SELinux, everything works correctly:
bash-5.2# sudo getenforce
Enforcing
bash-5.2# rpm-ostree status
State: idle
AutomaticUpdates: stage; rpm-ostreed-automatic.timer: no runs since boot
Deployments:
ostree-image-signed:docker://ghcr.io/ublue-os/bluefin-dx-nvidia:40
Digest: sha256:6c5fbf6d2c8da6094ebee8ff0104672275ef411c07f822f75609534c4721a14b
Version: 40.20240417.0 (2024-04-17T16:53:19Z)
Diff: 2 upgraded
● ostree-image-signed:docker://ghcr.io/ublue-os/bluefin-dx-nvidia:40
Digest: sha256:c88b1f5d70f4ab6d1a9e85ae656fc3642ad93c8a1f935d80363752e5a224c8f8
Version: 40.20240416.0 (2024-04-16T21:36:48Z)
ostree-image-signed:docker://ghcr.io/ublue-os/bluefin-dx-nvidia:40
Digest: sha256:84138aacff6e2626b1348fbcc9de23a590371cbd50348029f9925496b7125df8
Version: 40.20240416.0 (2024-04-16T16:58:03Z)
bash-5.2# sudo virt-install --name debian12-vm --memory 2048 --vcpus=2 --cdrom=/tmp/debian-12.5.0-amd64-netinst.iso --os-variant=debian12 --disk size=20
Starting install...
Allocating 'debian12-vm.qcow2' | 3.2 MB 00:00:02 ...
Removing disk 'debian12-vm.qcow2' | 0 B 00:00:00
ERROR can't connect to virtlogd: Unable to open system token /run/libvirt/common/system.token: Permission denied
Domain installation does not appear to have been successful.
If it was, you can restart your domain by running:
virsh --connect qemu:///system start debian12-vm
otherwise, please restart your installation.
bash-5.2# setenforce 0
bash-5.2# systemctl restart libvirtd virtlogd
bash-5.2# virt-install --name debian12-vm --memory 2048 --vcpus=2 --cdrom=/tmp/debian-12.5.0-amd64-netinst.iso --os-variant=debian12 --disk size=20
Starting install...
Allocating 'debian12-vm.qcow2' | 2.0 MB 00:00:00 ...
Creating domain... | 0 B 00:00:00
Running graphical console command: virt-viewer --connect qemu:///system --wait debian12-vm
(virt-viewer:18240): GSpice-WARNING **: 14:08:18.814: Warning no automount-inhibiting implementation available
Domain is still running. Installation may be in progress.
You can reconnect to the console to complete the installation process.
bash-5.2#
I updated to Fedora 40 just to check if it made a difference and it didn’t, I see the same or similar errors with Fedora 39.
You’re right! I got confused about when I tested. I just confirmed it works correctly in Fedora 39, but upon updating to Fedora 40 I start getting errors. Thanks for forcing me to retest!
Seems like there is now a thread in Silverblue for this:
The suggested workaround is:
Doing a full system relabel may mitigate the problem (especially the inability to launch a VM at all). To do this, run the following from a console:
sudo touch /.autorelabel
and then restart the system. The entire filesystem will have its SELinux labels corrected. This takes some time - anywhere from five minutes to an hour or so…
I have not tried the workaround but after the official 40 release I will try it when my system updates. Hopefully it works, otherwise I will have to roll back to 39 and wait for this to be fixed.
AFAIK, relabeling is not possible on an Atomic system because root is not writable. I will do some further testing and see if I can replicate the issue on Bluefin-DX 39 to 40 upgrade.
For now, a potential workaround for this is setting SELinux to permissive mode and see if that resolves the issue!
After running fixfiles -R libvirt-daemon-driver-qemu,libvirt-daemon-log restore && systemctl restart virtqemud virtlogd the problem was fixed
Obviously the fix only works until you reboot:
After a reboot the problem reappeared (since the fixes were all in /run which is not persistent) - I will check the other packages to find a fix on the real file system
I can see myself adding a systemd startup command that runs late to fix these permission on every start to make sure things work (until a proper fix).
I will report here after I upgrade and manage to test this workaround.
Update - above workaround also doesn’t work, however:
I have found this issue is random. I’ve rebooted 5 times just now in a row, and first thing I did was immediately run virt-manager and start a VM. It worked 3 out of 5 times.
So basically, when you reboot, immediately try to start a VM and if it doesn’t work then reboot again and repeat until your system ends up in a working state. This is not ideal, but at least may allow you to work…
I had this problem and tried a whole raft of different solutions. Apart from setting the system SELINUX to permissive mode (setenforce 0), what worked for me in the end ‘restorecon /var/lib/libvirt’ this worked and was persistent after reboot. I have had no issues since.
