Page MenuHomeSolus

virt-manager doesn't automatically start libvirtd
Closed, ResolvedPublic

Description

I installed virt-manager via the Software Center. When I start it, it states that he 'libvirtd' daemon is running.
If I close the application, run the command sudo systemctl start libvirtd and start it up again, it works fine.

Remarkably after the virt-manager start up correctly, it asks for 'the sudo password', so it could have started libvirtd himself.

I don't know whether this is an error in Solus or in virt-manager.

Following are the details of the error message (partially in Dutch):

Kan geen verbinding maken met libvirt.
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 904, in _do_open
  self._backend.open(self._do_creds_password)
File "/usr/share/virt-manager/virtinst/connection.py", line 148, in open
  open_flags)
File "/usr/lib/python2.7/site-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': Bestand of map bestaat niet

Related Objects

Event Timeline

Dag @caspermeijn !

When you install virt-manager, libvirt is also installed (if it wasn't previously installed).
The libvritd service is not started automatically.

@DataDrake made a very good explanation here. I think you'll find it useful ?

Hi @kyrios123

Sorry for not finding the other issue, I am new to the Solus project and had not figured out the search yet...

I understand that intended use case of virt-manager is not necessarily managing virtual machines running on the desktop. But as a end-user I found it strange that I got the error.

As background; I started using virt-manager because I am new to Solus and wanted to run a virtual machine on my laptop. When I searched for 'virtual machine' in the Software Center then virt-manager was the only program to appear (next to some libraries). If I would have found Gnome Boxes, then I would probably used that. Maybe this could be fixed?

Personally I fixed the problem with sudo systemctl enable libvirtd to start libvirtd during boot. I hope that a middle ground could be found, so that other users don't have to experience this problem.

DataDrake edited projects, added Software; removed Lacks Project.Nov 2 2017, 3:42 PM

Yeah we probably need a Help Center article on this.

DataDrake triaged this task as Normal priority.

I experienced the same issue and confusion when I installed virt-manager on my system and later figured out I needed to manually run

sudo systemctl enable libvirtd

A Help Center article would be useful, but that's not very discoverable at the time of install. It's also frustrating, as a user, to install something and have a "problem" immediately out of the gate. Might there be a way to note it in the install text in Software Center or have some sort of pop up when you first launch virt-manager? From the user's point of view it's more forgivable to have to run something to manually enable if they are told up front rather than discover it via error message.

Ideally this would be an option box pop up with a check mark to enable libvirtd to start at boot time, optionally. I understand that's up to the maintainers of virt-manager, however. I'm just wondering about what Solus *can* do in line for the user.

ermo added a subscriber: ermo.EditedSep 16 2020, 8:27 AM

@TClark77:

The most straightforward path is to ensure that libvirtd uses .socket activation on install I think?

I'm taking a quick stab at updating the package while I'm at it. Will ping you once it's ready for testing.

EDIT: Fair warning, this may not land this week as I haven't fully sussed out (nor tested) the necessary rebuilds.

ermo claimed this task.Sep 16 2020, 8:28 AM

Just FYI, there's an open usysconf issue for reporting what systemd services has been installed: https://github.com/getsolus/usysconf/issues/3

ermo added a comment.EditedSep 16 2020, 1:46 PM

Looks like the rebuild stack (including libvirt and qemu updates) is manageable and I've been given the green light to land this ASAP.

qemu required rebuilds::

  • gnome-boxes
  • virt-manager

libvirt required rebuilds:

  • gnome-boxes
  • libvirt-glib
  • libvirt-python
  • virt-manager
  • virt-viewer

@livingsilver94 :

.socket activation has been tested to work with virt-manager running against the new libvirt-6.7.0 release on my end even with the libvirt.service disabled.

I installed vm-manager on my dev VM where it had never been installed before for testing

Testing platform

VM on -unstable

Virtual Machine Manager was not yet installed and had never been installed.
libvirtd had never been installed

Preconditions

Updated system with Software Center

Virt-manager available: 2.2.1-26

Test steps

  1. Installed virt-manager from Software Center 2.2.1-26 9/16
    • Is libvirtd installed by default? Yes
  1. Ran virt-manager Expect No warnings / errors about libvirtd - fail x Actual result
The libvirtd service does not appear to be installed. Install and run the libvirtd service to manage virtualization on this host.
A virtualization connection can be manually added via File->Add Connection

Checked to see if libvirtd was installed / running
It is installed

 ❯ which libvirtd                                                 [11:51:40]
/usr/sbin/libvirtd

Status

 tracey@solus-dev-tlc  ~ 
 ❯ sudo systemctl status libvirtd                                 [12:28:34]
Password: 
● libvirtd.service - Virtualization daemon
     Loaded: loaded (/usr/lib/systemd/system/libvirtd.service; disabled; ven>
     Active: inactive (dead)
TriggeredBy: ● libvirtd-ro.socket
             ● libvirtd-admin.socket
             ● libvirtd.socket
       Docs: man:libvirtd(8)
             https://libvirt.org
In T4432#176496, @ermo wrote:

@livingsilver94 :
.socket activation has been tested to work with virt-manager running against the new libvirt-6.7.0 release on my end even with the libvirt.service disabled.

Ah, cool!

ermo added a comment.EditedSep 17 2020, 2:10 PM

I've written a systemd-sockets trigger for the legacy usysconf C-version, which will restart sockets.target on changes to the /usr/lib/systemd/system/sockets.target.wants/ directory where vendor-enabled .socket units live.

In my tests, this reliably activates the newly added .socket units immediately after installation of the package containing them as seen in P8.

The PR lives at https://github.com/getsolus/usysconf/pull/7

ermo changed the task status from Open to In Progress.EditedSep 24 2020, 12:21 AM
ermo reassigned this task from ermo to TClark77.
ermo moved this task from Backlog to System and Configuration Fixes on the Software board.

@TClark77

Josh just tagged usysconf legacy 0.5.4 containing the above trigger PR and committed it in R3873:334346bfedda4d20b1dc26a31e291db4c276740e on -unstable.

Re-assigning this to you for proper verification (it works on Josh's and my systems, but we'd love a proper 2nd opinion!).

List of test targets which it might be nice to verify (at your discretion obviously):

  • cups
  • docker
  • radeon-profile-daemon
  • snapd
  • virt-manager (and libvirtd)
ermo renamed this task from virt-manager doesn't automatcally start libvirtd to virt-manager doesn't automatically start libvirtd.Sep 24 2020, 9:26 AM

Virtual Machine Manager testing result

Pass - ✅

Testing platform

VM on -unstable

Preconditions

Uninstalled Virt-manager and updated system through Software Center

Test steps

  1. Installed virt-manager from Software Center 2.2.1-26
    • Is libvirtd installed by default? Yes ✅
  2. Ran virt-manager Expect No warnings / errors about libvirtd - pass - ✅

User is prompted to authenticate when the system starts libvirtd, and again to manage virtualization pass - ✅

Status before auth

 ❯ sudo systemctl status libvirtd           
● libvirtd.service - Virtualization daemon
     Loaded: loaded (/usr/lib/systemd/system/libvirtd.service; disabled; vendor preset: enabled)
  Active: inactive (dead)
TriggeredBy: ● libvirtd.socket (green)
          ● libvirtd-admin.socket (white)
             ● libvirtd-ro.socket (green)
       Docs: man:libvirtd(8)
             https://libvirt.org

Status after auth

All circles / dots green

 ❯ sudo systemctl status libvirtd
● libvirtd.service - Virtualization daemon
     Loaded: loaded (/usr/lib/systemd/system/libvirtd.service; disabled; vendor preset: enabled)
     Active: active (running) since Thu 2020-09-24 19:33:52 CDT; 1min 5s ago
TriggeredBy: ● libvirtd.socket
             ● libvirtd-admin.socket
             ● libvirtd-ro.socket
       Docs: man:libvirtd(8)
             https://libvirt.org
   Main PID: 32053 (libvirtd)
   Tasks: 17 (limit: 32768)
     Memory: 16.4M
  CGroup: /system.slice/libvirtd.service
             └─32053 /usr/sbin/libvirtd --timeout 120

Status is the same (all green) after restarting the test VM - ok ✅

  1. created a new VM in Virtual Manager & rebooted testing VM

Started up virt-manager
Expect No warnings / errors about libvirtd No password prompt to start libvirtd Password prompt to be able to manage virtualization - ok ✅

  1. Resumed VM

Expect VM resumes normally - ok ✅

Additional software testing

Testing steps

  1. Uninstall package before system update if necessary
  2. Install package in Solus Software Center
  3. Restart VM
  4. Start up program & test
  1. Expect
  2. No warnings
  3. Login prompt to set up the systemd service if necessary
  4. Launch software, verify it works as expected

software tested

cups (unable to uninstall prior to testing due to dependencies, it would have wiped out a decent chunk of Plasma) pass - ✅

Socket: green - ok ✅

 ❯ sudo systemctl status cups-browsed       
● cups-browsed.service - Make remote CUPS printers available locally
     Loaded: loaded (/usr/lib/systemd/system/cups-browsed.service; disabled; vendor preset: enabled)
     Active: active (running) since Thu 2020-09-24 19:52:43 CDT; 5min ago
   Main PID: 650 (cups-browsed)
      Tasks: 3 (limit: 4683)
     Memory: 3.5M
     CGroup: /system.slice/cups-browsed.service
             └─650 /usr/sbin/cups-browsed

Sep 24 19:52:43 solus-dev-tlc systemd[1]: Started Make remote CUPS printers available locally.

Loaded the Printer Settings dialog. Verified it behaves OK (Can’t actually add my printer since it’s not seen by the VM) - ok ✅
Loaded http://localhost:631/ and http://localhost:631/admin and verified things look good - ok ✅

radeon-profile-daemon** (also installed Radeon-profile) - pass ✅
I don’t have a radeon graphics card, so I wasn’t able to select a GPU in the GUI I verified the software launches and the UI behaves correctly

snapd
Unexpected results 2.39.3-56 Socket: Green Not sure if the problem I saw was due to Solus or the way the snapd package is otherwise installed OK
(You knew there had to be one)
I suspect this is due to an upstream issue and not due to anything Solus is doing, read on

 ❯ sudo systemctl status snapd                                                                                                              [20:00:55]
● snapd.service - Snappy daemon
     Loaded: loaded (/usr/lib/systemd/system/snapd.service; disabled; vendor preset: enabled)
     Active: inactive (dead)
TriggeredBy: ● snapd.socket

Tested installing a snap and got an error

 ✘ tracey@solus-dev-tlc ~ 
 ❯ sudo snap install purple-task    
Password: 
error: too early for operation, device not yet seeded or device model not acknowledged

 ✘ tracey@solus-dev-tlc ~
 ❯ systemctl status snapd.seeded.service   
● snapd.seeded.service - Wait until snapd is fully seeded
     Loaded: loaded (/usr/lib/systemd/system/snapd.seeded.service; disabled; vendor preset: enabled)
     Active: inactive (dead)

Restarted the snapd service as recommended in This Ubuntu bug and was able to install the snap successfully - ok ✅

systemctl restart snapd.seeded.service

After installation the program launched normally

Skipped

Docker - no testing (Josh had tested docker and verified it works so not retesting)

ermo closed this task as Resolved.Sep 25 2020, 8:35 AM

Looks like the libvirt/virt-manager part is indeed solved now, so closing as resolved.

Thanks for the thorough testing @TClark77 !

(The snap stuff probably needs its own issue).