Virt Manager Quit Working (ibvirtError: can't connect to virtlogd)

2nd (and hopefully) the last issue of the day. Virt-Manager/Qemu has been working without issue till tonight. Now I can’t run existing VMs or new VMs, I get the following error when attempting to run:

Error starting domain: can’t connect to virtlogd: Unable to open file: /var/log/libvirt/qemu/fedora39.log: Permission denied

I tried sudo usermod -a -G libvirt username but to no avail.

Traceback (most recent call last):
File “/usr/share/virt-manager/virtManager/”, line 72, in cb_wrapper
callback(asyncjob, *args, **kwargs)
File “/usr/share/virt-manager/virtManager/”, line 108, in tmpcb
callback(*args, **kwargs)
File “/usr/share/virt-manager/virtManager/object/”, line 57, in newfn
ret = fn(self, *args, **kwargs)
File “/usr/share/virt-manager/virtManager/object/”, line 1402, in startup
File “/usr/lib64/python3.12/site-packages/”, line 1379, in create
raise libvirtError(‘virDomainCreate() failed’)
libvirt.libvirtError: can’t connect to virtlogd: Unable to open file: /var/log/libvirt/qemu/fedora39.log: Permission denied

1 Like

It is impossible to keep up with what you have for OS, version, and status.
Please, when asking for assistance at least tell us fedora 39? or 40?
fully updated?
when was it last updated?
What has changed since it last worked?
What do the logs say?

That says fedora39.log, but you do not give us any of the content nor the ownership or selinux content.

I have many log files in that directory, one for each VM I have used, and all show something similar to this.

# ls -lZ /var/log/libvirt/qemu/
-rw-------. 1 root root system_u:object_r:virt_log_t:s0 1098346 Apr 10 20:56 fedora39.log
-rw-------. 1 root root system_u:object_r:virt_log_t:s0 2097124 Nov 23 12:25 fedora39.log.0

# ls -lZd /var/log/libvirt/qemu/
drwx------. 2 root root system_u:object_r:virt_log_t:s0 4096 Apr  7 16:25 /var/log/libvirt/qemu/

# ls -lZd /var/log/libvirt/
drwx------. 5 root root system_u:object_r:virt_log_t:s0 4096 Mar 11 19:00 /var/log/libvirt/

# ls -lZd /var/log/
drwxr-xr-x. 26 root root system_u:object_r:var_log_t:s0 4096 Apr 14 00:00 /var/log/

If selinux context is messed up or if ownership or permissions are not correct (on the file or the directory tree) then libvirt would not be able to access the file.

Note that arbitrarily changing group or other configs is not the first step. The first step would be to analyze why? then take appropriate steps.

When changing groups for a user the change does not take effect until after a logout and back in. To see what groups that user may belong to the user simply runs groups, or if running as root the command would be groups USERNAME

sorry, i’m running F40

ls -lZ /var/log/libvirt/qemu/
total 0

ls -lZd /var/log/libvirt/qemu/
drwxr-xr-x. 2 root root system_u:object_r:var_log_t:s0 4096 Apr 18 22:32 /var/log/libvirt/qemu/

ls -lZd /var/log/libvirt/
ls -lZd /var/log/libvirt/

ls -lZd /var/log/
drwxr-xr-x. 7 root root system_u:object_r:var_log_t:s0 4096 Apr 19 00:00 /var/log/

groups output:
spaceboy wheel vboxusers libvirt

Note that on my F39 system /var/log is var_log_t
/var/log/libvirt and everything below is virt_log_t, which certainly would be a difference for selinux.

Yours shows no selinux context for /var/log/libvirt and var_log_t for /var/log/libvirt/qemu/.
To test if this is selinux you might try sudo setenforce 0 to temporarily disable it.
You can also see that permissions are incorrect for /var/log/libvirt/qemu since it should be as shown with my post above.
The reason you got no response for a couple of those directories is that the directories are owned by root and should have 700 permissions for those directories so are accessible only with root environment & permissions. Note that what I posted has the # prompt which indicates I was logged in as root at that time.
Using sudo su would get you to the root environment and allow seeing the proper results for all those directories. Use exit to get back out of that environment.

Assuming the F40 selinux policies are correct, you should be able to fix the context on the /var/log/libvirt tree with sudo restorecon -rv /var/log/libvirt/. The -v option makes it verbose so it tells you what is happening.
You would be able to change permissions on /var/log/libvirt/qemu with
sudo chmod 700 /var/log/libvirt/qemu


This is also reported in bugzilla: