libvirtd failed to initialize libnetcontrol

Since doing a rollback to get my system working from a kernel-firmware problem, it seems KVM has stopped working. When I try to start virt-manager I get the following error from the system logs:

libvirtd[2731]: 2019-01-16 04:47:32.641+0000: 2731: warning : netcfIfaceRegister:1193 : Failed to intialize libnetcontrol.  Management of interface devices is disabled

Everything for the KVM host virtualization pattern still shows installed in yast. What is causing this error?

Thanks.

Also, if I try to launch virt-manager from the command line, I get the following:

/usr/bin/virt-manager: line 3: /usr/share/virt-manager/virt-manager: Permission denied
/usr/bin/virt-manager: line 3: /usr/share/virt-manager/virt-manager: Success

Previously, it would just open with no messages displayed in the terminal. Any idea why it would give permission denied, then success on the same line?

When KVM is installed does it automatically add the user to a kvm group? The only group my user is listed under is “users.” I don’t know if the rollback may have removed my user from a group or not, as I never checked it before I did the rollback.

I just thought I’d post that I resolved this issue by reinstalling the OS. No idea what happened, but it appeared to be caused by the rollback and probably some problem with the kernel-firmware issue everyone is having with the atheros wifi cards. Maybe rolling back to the previous firmware left some setting behind that messed up KVM. Reinstalling KVM did not fix the problem. I probably should have tried forcing a reinstall of the firmware, but I did not think about that until after I started the OS reinstall. In any case, reinstalling was faster than trying to narrow down the cause.

Thanks for reporting back.

I had this when NetworkManager was enabled (openSuSE 15.1).
Currently, libvirtd starts correctly only if network is managed over “wicked” service. (Yast / Network settings / Global options / Network setup method )

I can confirm this is still the case after rolling dist upgrade (# zypper dup) to latest version:

> cat /etc/os-release
NAME=“openSUSE Tumbleweed”

VERSION=“20191009”

and tested both with wicked service and NetworkManager controlled setups.

Further debug info:

> uname -r
5.3.5-2.gdb1b90f-default

grep -vE “^(#| *$)” /etc/libvirt/libvirtd.conf

unix_sock_group = “libvirt”
unix_sock_rw_perms = “0770”
log_level = 4
log_outputs=“3:syslog:libvirtd”

systemctl status libvirtd.service

Active: failed (Result: exit-code)
… localhost systemd[1]: libvirtd.service: Start request repeated too quickly.
… localhost systemd[1]: libvirtd.service: Failed with result ‘exit-code’.
… localhost systemd[1]: Failed to start Virtualization daemon.

journalctl -b -u libvirtd.service

no errors listed

virsh net-start default

error: failed to connect to the hypervisor
error: Failed to connect socket to ‘/var/run/libvirt/libvirt-sock’: Connection refused

It was working before the upgrade (my last version was from around middle of August).
Where else I could look for the cause?

Thanks
/pyramid

I wish I could offer some insight, but I never found a solution other than reinstalling the OS. However, I’m currently running Leap with the Tumbleweed kernel and using Network Manager and I’m not presently having any problems. The issue for me was caused by a snapper rollback that apparently did not work correctly.

Especially for the following, you should post the entire stdout, there might be more relevant info than what you posted… In fact, it’s a good rule of thumb if there is any question what to post the entire output should be made available. If it’s too large, then post to a pastebin and then include in your post a link to your pastebin

# systemctl status libvirtd.service
Active: failed (Result: exit-code)
... localhost systemd[1]: libvirtd.service: Start request repeated too quickly.
... localhost systemd[1]: libvirtd.service: Failed with result 'exit-code'.
... localhost systemd[1]: Failed to start Virtualization daemon.

Wish I could comment further, I can only say that this type of error happened to me often when the libvirt daemon was implemented as a “server” but I suspect that nowadays like most other services that have been deployed that way, it likely has been re-deployed as a kernel mode process so technically shouldn’t be subject to the same causes. In fact, it’s pretty hard(at least at the moment for me) how one kernel mode process might not have sufficient permissions to access another KMS.

TSU

Well, at least it seems to be resolved since a couple of releases ago.


$ uname -r
5.4.2-2.g3440d57-default

$ cat /etc/os-release 
NAME="openSUSE Tumbleweed"
# VERSION="20191207"

That is NOT the TW kernel. Just saying.