Ok, from 2.1 we can see that it is not just the socket that is up. It did indeed start your service at "2020-05-08 17:24:47".
You have a qqemu process listed under libvirt, which is uncommon: 1745 [qemu-system-x86] That isn't a guest as those are not listed there. I'm wondering if this is the capability-probing step which happens when libvirt initializes and there is no cache for the capabilities. When you have the error case and you see a qemu under libvirt again in `systemctl status libvirtd` could you then check if that qemu is running fine. e..g does it consume cpu or is it hanging in a disabled state. Furthermore report its commandline via /proc/<pid>/cmdline. I just want to find if that really is the capability probing. Further in your logs I found: Could not access KVM kernel module: No such file or directory qemu-system-x86_64: failed to initialize KVM: No such file or directory qemu-system-x86_64: Back to tcg accelerator This somewhat matches my assumption in comment #1 that for you libvirt might initialize out of order before kvm is ready. They would be auto-loaded, but just to be sure since it seems reproducible let us try to load kvm earlier to see if that resolves your situation. Put in /etc/modules the line "kvm_amd" Then: $ sudo update-initramfs -u $ sudo update-grub And reboot, let me know if this earlier loading of kvm_amd helped in your case. P.S. I rechecked some MAD systems, but they don't have the same issue to debug it over here ... -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1876266 Title: virt-manager can't connect to libvirtd until the service is restarted To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1876266/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
