Unable to connect to libvirt qemu:///system.

English Virtualization
1 

Unable to connect to libvirt qemu:///system.

Failed to connect socket to '/var/run/libvirt/virtqemud-sock': Connection refused

Libvirt URI is: qemu:///system

Traceback (most recent call last):
  File "/usr/share/virt-manager/virtManager/connection.py", line 958, in _do_open
    self._backend.open(connectauth.creds_dialog, self)
  File "/usr/share/virt-manager/virtinst/connection.py", line 174, in open
    open_flags)
  File "/usr/lib64/python3.6/site-packages/libvirt.py", line 104, in openAuth
    if ret is None:raise libvirtError('virConnectOpenAuth() failed')
libvirt.libvirtError: Failed to connect socket to '/var/run/libvirt/virtqemud-sock': Connection refused



nasheayahu@kohanOS:~> systemctl status libvirtd
● libvirtd.service - Virtualization daemon
   Loaded: loaded (/usr/lib/systemd/system/libvirtd.service; enabled; vendor preset: disabled)
   Active: active (running) since Mon 2021-02-08 22:43:27 MST; 2s ago
     Docs: man:libvirtd(8)
           https://libvirt.org
 Main PID: 5031 (libvirtd)
    Tasks: 17 (limit: 32768)
   CGroup: /system.slice/libvirtd.service
           └─5031 /usr/sbin/libvirtd --timeout 120

Feb 08 22:43:26 kohanOS systemd[1]: Starting Virtualization daemon...
Feb 08 22:43:26 kohanOS libvirtd[5031]: libvirt version: 6.0.0
Feb 08 22:43:26 kohanOS libvirtd[5031]: hostname: kohanOS
Feb 08 22:43:26 kohanOS libvirtd[5031]: **Failed to initialize libnetcontrol.  Management of interface devices is disabled**
Feb 08 22:43:27 kohanOS systemd[1]: Started Virtualization daemon.

This is a new full KDE install, I’m added to kvm, libvirt, qemu groups and still not able to connect to either LXC nor QEMU / KVM. What am I missing?

2

Did you read the man page of the “libvirtd management daemon”? – <https://linux.die.net/man/8/libvirtd&gt;
Did you configure the daemon correctly?


/etc/libvirtd.conf
    The default configuration file used by libvirtd, unless overridden on the command line using the -f|--config option.
3

[QUOTE=dcurtisfra;3002068]Did you read the man page of the “libvirtd management daemon”? – <https://linux.die.net/man/8/libvirtd>
Did you configure the daemon correctly?



Didn't read that info, I don't know what build version I'm currently using but, with four fresh installs of Leap 15.2 and two SUSE Enterprise ARM (Pi 4), I made no changes.  So something changed or I did something without knowing it, because I didn't have this problem before the fresh installs of Leap.  All four Leap OS have the same problem and did test the SUSE Enterprise yet.

One of the Leap OS, I'm trying to create a Dev Env (Pondman, Buildah, LXC, QEMU / KVM, Vagrant using KVM) to prepare for a Production Environment and I can't get started until I get this fixed.  Any suggestion on what may have happen?
4

Just check my SUSE Enterprise ARM:


administrator@susepi1:~> systemctl status libvirtd
● libvirtd.service - Virtualization daemon
   Loaded: loaded (/usr/lib/systemd/system/libvirtd.service; enabled; vendor preset: enabled)
   Active: inactive (dead)
     Docs: man:libvirtd(8)
           https://libvirt.org
administrator@susepi1:~> systemctl start libvirtd
==== AUTHENTICATING FOR org.freedesktop.systemd1.manage-units ====
Authentication is required to start 'libvirtd.service'.
Authenticating as: root
Password: 
==== AUTHENTICATION COMPLETE ====
administrator@susepi1:~> systemctl status libvirtd
● libvirtd.service - Virtualization daemon
   Loaded: loaded (/usr/lib/systemd/system/libvirtd.service; enabled; vendor preset: enabled)
   Active: active (running) since Tue 2021-02-09 12:03:35 MST; 3s ago
     Docs: man:libvirtd(8)
           https://libvirt.org
 Main PID: 30999 (libvirtd)
    Tasks: 17 (limit: 32768)
   CGroup: /system.slice/libvirtd.service
           └─30999 /usr/sbin/libvirtd --timeout 120
administrator@susepi1:~>

Made no changes and it just works. This should also be the result for the current Leap just like before I did the fresh installs.

5

Show output of “ls -l /var/run/libvirt”.

6 

nasheayahu@kohanOS:~> ls -l /var/run/libvirt
total 0
drwxr-xr-x 2 root root  40 Feb  8 22:40 hostdevmgr
srw------- 1 root root   0 Feb  8 23:13 libvirt-admin-sock
srw-rw-rw- 1 root root   0 Feb  8 23:13 libvirt-sock
srw-rw-rw- 1 root root   0 Feb  8 23:13 libvirt-sock-ro
drwxr-xr-x 2 root root  60 Feb  8 23:09 lxc
drwxr-xr-x 2 root root 100 Feb  8 23:00 network
drwx------ 2 root root  40 Feb  8 23:12 nodedev
drwx------ 2 root root  40 Feb  8 22:45 nwfilter
drwx------ 2 root root  40 Feb  8 22:43 nwfilter-binding
drwxr-xr-x 3 root root 100 Feb  8 23:00 qemu
drwx------ 2 root root  40 Feb  8 23:14 secrets
drwxr-xr-x 2 root root  80 Feb  8 23:00 storage
srw------- 1 root root   0 Feb  8 23:00 virtinterfaced-admin-sock
srw-rw-rw- 1 root root   0 Feb  8 23:00 virtinterfaced-sock
srw-rw-rw- 1 root root   0 Feb  8 23:00 virtinterfaced-sock-ro
srw------- 1 root root   0 Feb  8 23:13 virtlockd-sock
srw------- 1 root root   0 Feb  8 23:13 virtlogd-sock
srw------- 1 root root   0 Feb  8 23:00 virtlxcd-admin-sock
srw-rw-rw- 1 root root   0 Feb  8 23:00 virtlxcd-sock
srw-rw-rw- 1 root root   0 Feb  8 23:00 virtlxcd-sock-ro
srw------- 1 root root   0 Feb  8 23:00 virtnetworkd-admin-sock
srw-rw-rw- 1 root root   0 Feb  8 23:00 virtnetworkd-sock
srw-rw-rw- 1 root root   0 Feb  8 23:00 virtnetworkd-sock-ro
srw------- 1 root root   0 Feb  8 23:10 virtnodedevd-admin-sock
srw-rw-rw- 1 root root   0 Feb  8 23:10 virtnodedevd-sock
srw-rw-rw- 1 root root   0 Feb  8 23:10 virtnodedevd-sock-ro
srw------- 1 root root   0 Feb  8 23:00 virtqemud-admin-sock
srw-rw-rw- 1 root root   0 Feb  8 23:00 virtqemud-sock
srw-rw-rw- 1 root root   0 Feb  8 23:00 virtqemud-sock-ro
srw------- 1 root root   0 Feb  8 23:12 virtsecretd-admin-sock
srw-rw-rw- 1 root root   0 Feb  8 23:12 virtsecretd-sock
srw-rw-rw- 1 root root   0 Feb  8 23:12 virtsecretd-sock-ro
srw------- 1 root root   0 Feb  8 23:00 virtstoraged-admin-sock
srw-rw-rw- 1 root root   0 Feb  8 23:00 virtstoraged-sock
srw-rw-rw- 1 root root   0 Feb  8 23:00 virtstoraged-sock-ro

And by the way, my error including the other three Leap OS, they’re working properly. Made the miss judgement by only viewing the same libvirtd status to my Dev Leap OS. After the fresh instrall I never restarted the other three. I did something with the Dev Leap OS and it may have to do with the extra installs or other.

7

After comparing the one of the other three Leap OS to my Dev Leap OS, I found I got carried away with these services:


virtinterfaced                                             │Manually │Inactive (Dead) │Virtualization interface daemon                                                                                                                        
virtlockd                                                  │On Demand│Active          │Virtual machine lock manager                                                                                                                            virtlogd                                                   │On Demand│Active          │Virtual machine log manager                                                                                                                           virtlxcd                                                   │Manually │Inactive (Dead) │Virtualization lxc daemon                                                                                                                             
virtnetworkd                                               │Manually │Inactive (Dead) │Virtualization network daemon                                                                                                                         
virtnodedevd                                               │Manually │Inactive (Dead) │Virtualization nodedev daemon                                                                                                                         virtnwfilterd                                              │Manually │Inactive (Dead) │Virtualization nwfilter daemon                                                                                                                        virtproxyd                                                 │Manually │Inactive (Dead) │Virtualization daemon                                                                                                                                 virtqemud                                                  │Manually │Inactive (Dead) │Virtualization qemu daemon                                                                                                                            
virtsecretd                                                │Manually │Inactive (Dead) │Virtualization secret daemon                                                                                                                          virtstoraged                                               │Manually │Inactive (Dead) │Virtualization storage daemon

and return the status back to their defaults. I panicked when I saw:


nasheayahu@kohanOS:~> systemctl status libvirtd
● libvirtd.service - Virtualization daemon
   Loaded: loaded (/usr/lib/systemd/system/libvirtd.service; enabled; vendor preset: disabled)
   Active: active (running) since Mon 2021-02-08 22:43:27 MST; 2s ago
     Docs: man:libvirtd(8)
           https://libvirt.org
 Main PID: 5031 (libvirtd)
    Tasks: 17 (limit: 32768)
   CGroup: /system.slice/libvirtd.service
           └─5031 /usr/sbin/libvirtd --timeout 120

Feb 08 22:43:26 kohanOS systemd[1]: Starting Virtualization daemon...
Feb 08 22:43:26 kohanOS libvirtd[5031]: libvirt version: 6.0.0
Feb 08 22:43:26 kohanOS libvirtd[5031]: hostname: kohanOS
Feb 08 22:43:26 kohanOS libvirtd[5031]: **Failed to initialize libnetcontrol.  Management of interface devices is disabled**
Feb 08 22:43:27 kohanOS systemd[1]: Started Virtualization daemon.

But, I would still like to fix:


Feb 08 22:43:26 kohanOS libvirtd[5031]: Failed to initialize libnetcontrol.  Management of interface devices is disabled

I’m guesting this will cause me problems with the VM’s devices? And it has to do with this service:


virtinterfaced                                             │Manually │Inactive (Dead) │Virtualization interface daemon
8

Before looking more deeply at your troubles,
It looks like you’re attempting to enable your normal User account to have access to managing your virtual machines… Why are you doing that?
The virtualization technologies set up and managed by libvirt are by default intended to comply with normal requirements running a Production environment…
And, it’s an extremely bad decision to compromise the security your your Virtualization.
You should always require elevated permissions to manage (and typically to run) virtual machines.

If you want to manage your virtualization with a normal User account without elevated permissions, you should run something else like Virtualbox or VMware player.
Or, although I strongly do not recommend it… Many distros use the wheel group to grant elevated permissions to Users.

TSU

9

You have both monolithic and modular libvirt sockets. By default unless you explicitly say which socket to use libvirt will try to guess and will use modular socket in preference. But you do not have modular daemons running, you have only monolithic libvirtd

You cannot mix both monolithic and modular implementation. Read libvirt: Libvirt Daemons, check what is active and disable what you do not need. Either you need to disable monolithic libvirtd or you need to disable modular sockets.

10

Okay, I just stay with the defaults, at this point in time its just a single user (Me) Dev Env to learn and master the Leap / SUSE OS before hiring a team.

I’m completely returning back to the Unix/Linux environment after being way too long out of it since the DOS days of development. openSUSE / Redhat were my first distro’s back then, I use to work for Discount Tire Center has a IT on a SCO Unix and one other company.

Was trying to accomplish my company goals with Windows, but now I’m finally fed up, the only thing left hanging in the closet is Visual Studio Community IDE (Excellent IDE, not comfortable as of yet with VS Code, but getting there), TFS on a eval Windows Server; hoping to learn and configure a GIT server on Leap before the eval expires because I don’t want to purchase the server just for TFS.

openSUSE was always my main distro, so after evaluating others, SUSE Enterprise, and Leap is my complete solution for running the company infrastructure and Ubuntu Studio KDE for my media department. So for the next six months or so before hiring a team is to master SUSE / Leap OS.

11

Well after reading this:

Currently both monolithic and modular daemons are built by default, but the RPC client still prefers connecting to the monolithic daemon. It is intended to switch the RPC client to prefer the modular daemons in the near future. At least 1 year after this switch (but not more than 2 years), the monolithic daemon will be deleted entirely.

I will use “modular libvirt sockets”.