Virt Machine Manager Connection Failure!

[Jeff_Fredericks]

I’m having massive issues with Virtual Machine Manager. For some reason, after starting it up, I now see a ‘Unable to connect to libvirt qemu:///system. Verify that the libvirtd daemon is running.’

Going into details this is what I see:

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

Verify that the 'libvirtd' daemon is running.

Libvirt URI is: qemu:///system

Traceback (most recent call last):
  File "/usr/share/virt-manager/virtManager/connection.py", line 1036, in _do_open
self._backend.open(self._do_creds_password)
  File "/usr/share/virt-manager/virtinst/connection.py", line 144, in open
open_flags)
  File "/usr/lib/python2.7/dist-packages/libvirt.py", line 105, in openAuth
if ret is None:raise libvirtError('virConnectOpenAuth() failed')
libvirtError: Failed to connect socket to '/var/run/libvirt/libvirt-sock': No such file or directory

I can con confirm I do not have any libvirt-sock

And running virt-install isn’t any better

Taking a look, these should be all relevant and necessary users:

As well as the ralevent groups I have configured.

I have a reviewed a number of similar posts about this (though linking would be a not-so-great idea). And am a bit lost as to what to do to fix this. Any help is greatly appreciated.

edit: List of files in /var/run/libvirt

Edit: I marked it as solved. But this wasn’t just 1 issue. There were a number of issues that cropped up. So to anyone out there who comes across this I encourage you to read this post all the way through, until the end.

[tkoham]

run virsh uri, if it returns session, use sudo.

[Jeff_Fredericks]

unknown command ‘url’

[tkoham]

i not l

[Jeff_Fredericks]

aw, haha. apologize I didn’t notice the dot in the i.

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

[imhigh.today]

Do you actually have the libvirt daemon installed? Certain apt::conf settings might have prevented it from being installed with virt-manager.

sudo apt install libvirt-daemon-system

Once installed, the libvirtd should be autostarted on Debian-based systems.

If not autostarted by default:

sudo systemctl start libvirtd

[tkoham]

sudo systemctl enable libvirtd virtlogd && sudo systemctl start libvirtd virtlogd

if it returns an error then install the damn things

[Jeff_Fredericks]

@imhigh.today

All of those are installed and enabled. When i run

systemctl status libvirtd

I see it’s inactive/dead.

@tkoham so this is new

Synchronizing state of libvirtd.service with SysV service script with /lib/systemd/systemd-sysv-install.
Executing: /lib/systemd/systemd-sysv-install enable libvirtd
Synchronizing state of virtlogd.service with SysV service script with /lib/systemd/systemd-sysv-install.
Executing: /lib/systemd/systemd-sysv-install enable virtlogd
The unit files have no installation config (WantedBy, RequiredBy, Also, Alias settings in the [Install] section, and DefaultInstance for template units).
This means they are not meant to be enabled using systemctl.
Possible reasons for having this kind of units are:
1) A unit may be statically enabled by being symlinked from another unit's  .wants/ or .requires/ directory.
2) A unit's purpose may be to act as a helper for some other unit which has a requirement dependency on it.
3) A unit may be started when needed via activation (socket, path, timer, D-Bus, udev, scripted systemctl call, ...).
4) In case of template units, the unit is meant to be enabled with some instance name specified.

[tkoham]

sorry what distro is this

[imhigh.today]

Almost certainly Ubuntu, but the SysV init stuff looks like it was upgraded from an older release improperly. Looks like it’s trying to process SysV compatibility, but probably shouldn’t be.

[Jeff_Fredericks]

… This is a fresh install (almost). If there were any upgrades they were done after the initial installation.

Also yes, it’s ubuntu 18.04

[imhigh.today]

Humor me, please.

sudo apt install -f

Does apt want to take any action from that command?

[tkoham]

yeah i figured because of the bruise colored terminals but this looks busted even for ubuntu

[Jeff_Fredericks]

So right now it says:

apt install -f
Reading package lists... Done
Building dependency tree       
Reading state information... Done
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.

However I ran apt update && apt upgrade a few minutes before thinking it would be a good idea.

Not sure how much of that you want to see.

edit: I’m just comfortable with Ubuntu

[imhigh.today]

Yeah, something’s definitely not right here.

Not sure how much of that you want to see.

That’s sufficient. I was checking to make sure you didn’t have a partially installed set of packages. You don’t appear to.

The good news: Almost certainly not an error on your end. You got the right packages and it should be working.

The bad news: I have no idea what broke.

[Jeff_Fredericks]

Looking at this guide right now. And I noticed this line in libvirt.conf:

uri_default = "qemu:///system"

Is that right?

[imhigh.today]

That SysV processing stuff looks suspicious to me.

18.04 should be completely moved over to Systemd, so that shouldn’t be happening.

If there’s a missing systemd service unit, or there’s leftover SysV scripts, I could see that happening. But there shouldn’t be a missing service unit (it would be a major bug), and you shouldn’t have SysV init scripts if it wasn’t upgraded from an older release.

[tkoham]

that’s fine, you’d just add your user to the qemu group if you dont want to run it as sudo.

problem here is your services aren’t wanting to run for some reason.

[imhigh.today]

That whole guide seems like a lot of unneeded system pokery.

[Jeff_Fredericks]

Do I need to look into reinstalling Ubuntu?