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.

Yeah we probably need a Help Center article on this.

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.

@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.

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

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

2. 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!

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

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 ✅

3. 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 ✅

5. 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)