Hello,
libvirt/virt-manager qemu virtualization has problems on my f38 system since a few days.
Failed to connect socket to '/var/run/libvirt/libvirt-sock'
What am I missing here? (It has still worked a few days ago.) How to fix that?
Kind regards,
aanno
References:
Is libvirtd running?
Check systemd statis libvirtd
I think that is where the socket is set up.
Flacky:
# systemctl status libvirtd
○ libvirtd.service - Virtualization daemon
Loaded: loaded (/usr/lib/systemd/system/libvirtd.service; enabled; preset: disabled)
Drop-In: /usr/lib/systemd/system/service.d
└─10-timeout-abort.conf
Active: inactive (dead) since Wed 2023-05-17 20:09:22 CEST; 4s ago
Duration: 458ms
TriggeredBy: ● libvirtd.socket
● libvirtd-ro.socket
● libvirtd-admin.socket
○ libvirtd-tcp.socket
○ libvirtd-tls.socket
Docs: man:libvirtd(8)
https://libvirt.org
Process: 14810 ExecStart=/usr/sbin/libvirtd $LIBVIRTD_ARGS (code=exited, status=0/SUCCESS)
Main PID: 14810 (code=exited, status=0/SUCCESS)
CPU: 342ms
Mai 17 20:09:21 redsnapper systemd[1]: Starting libvirtd.service - Virtualization daemon...
Mai 17 20:09:21 redsnapper systemd[1]: Started libvirtd.service - Virtualization daemon.
Mai 17 20:09:22 redsnapper libvirtd[14810]: libvirt version: 9.0.0, package: 2.fc38 (Fedora Project, 2023-01-19->
Mai 17 20:09:22 redsnapper libvirtd[14810]: hostname: redsnapper
Mai 17 20:09:22 redsnapper libvirtd[14810]: Erlangen der PID Datei '/run/libvirt/nodedev/driver.pid' fehlgeschla>
Mai 17 20:09:22 redsnapper libvirtd[14810]: Initialisierung des udev Status-Treibers fehlgeschlagen: Erlangen de>
Mai 17 20:09:22 redsnapper libvirtd[14810]: Treiber Status Initialisierung fehlgeschlagen
Mai 17 20:09:22 redsnapper systemd[1]: libvirtd.service: Deactivated successfully.
But I could restart it with:
# systemctl restart libvirtd
# systemctl status libvirtd
● libvirtd.service - Virtualization daemon
Loaded: loaded (/usr/lib/systemd/system/libvirtd.service; enabled; preset: disabled)
Drop-In: /usr/lib/systemd/system/service.d
└─10-timeout-abort.conf
Active: active (running) since Wed 2023-05-17 20:10:41 CEST; 2s ago
TriggeredBy: ● libvirtd.socket
● libvirtd-ro.socket
● libvirtd-admin.socket
○ libvirtd-tcp.socket
○ libvirtd-tls.socket
Docs: man:libvirtd(8)
https://libvirt.org
Main PID: 15001 (libvirtd)
Tasks: 21 (limit: 32768)
Memory: 14.3M
CPU: 439ms
CGroup: /system.slice/libvirtd.service
└─15001 /usr/sbin/libvirtd --timeout 120
Mai 17 20:10:41 redsnapper systemd[1]: Starting libvirtd.service - Virtualization daemon...
Mai 17 20:10:41 redsnapper systemd[1]: Started libvirtd.service - Virtualization daemon.
But still after this, virt-install ... leads to:
Couldn't create default storage pool '/var/lib/libvirt/images': Could not define storage pool: Socket-Erstellung zu '/var/run/libvirt/virtstoraged-sock' fehlgeschlagen: Datei oder Verzeichnis nicht gefunden
I have been using virt-manager on my F38 WS with no issues. Libvrtd.service does not run and is disabled on my system. It is still inactive while a VM is running so I am uncertain whether checking it’s status is beneficial. When I installed it, on this system, I did nothing to any configuration files nor did I need to start libvirtd as a service. It just worked. My suggestion is to install the virtualization group using dnf, like so sudo dnf group install virtualization.
Well, I think it is normally not started/enabled because fedora has switched to the ‘modular daemons’. See the links in my question!
I used Getting started with virtualization :: Fedora Docs to install the stuff. This includes sudo dnf group install virtualization.
The libvirtd services has been split up into separate daemon services a couple of releases ago. Currently the enabled units are
virtinterfaced.socket
virtnetworkd.socket
virtnodedevd.socket
virtnwfilterd.socket
virtproxyd.socket
virtqemud.service
virtsecretd.socket
virtstoraged.socket
Running libvirtd instead might still work.
makes sense, but I still didn’t need to do anything special to get it running was my point. It worked for me ootb, I did need to make sure my hardware virtualization was enabled in the bios.
Because doing that would enable these units instead of the libvirtd units. If, however, you have upgraded through several releases you will have a different set of units enabled depending on what units were enabled per default those releases ago.
System mode requires the group membership:
sudo usermod -a -G libvirt ${USER}
Strange,
this morning (after update and reboot) things work as expected again.
However, I was able to submit an automatic bug report related to libvirt yesterday: 2208026 – [abrt] libvirt-daemon: __futex_abstimed_wait_common64(): libvirtd killed by SIGABRT