First experiences using new libvirt backend

Hi,
first of all thank you for adding that. I tried it a bit this morning and while it generally worked \o/ I ran into a few things I wanted to start a discussion on before considering to open bugs.

After spawning a new machine and trying to use virsh on it the first you get is:

$ multipass.virsh edit up-pony
error: failed to connect to the hypervisor
error: no valid connection
error: Failed to connect socket to '/var/snap/multipass/common/run/libvirt/libvirt-sock': Permission denied

I realized this is due to:

$ ll /var/snap/multipass/common/run/libvirt/libvirt-sock
srwx------ 1 root root 0 Apr 23 07:51 /var/snap/multipass/common/run/libvirt/libvirt-sock=

So I can work with it via sudo, but that feels odd.
Usually in Ubuntu access to this socket is controlled by membership to libvirtd

srwx------ 1 root libvirtd 0 Apr 23 07:02 /var/run/libvirt/libvirt-admin-sock=
srwxrwx--- 1 root libvirtd 0 Apr 23 07:02 /var/run/libvirt/libvirt-sock=
srwxrwxrwx 1 root libvirtd 0 Apr 23 07:02 /var/run/libvirt/libvirt-sock-ro=

I can see why in a snap you can’t rely on group ownership outside the snap.
I haven’t worked too much with snaps in regard to access control, but it would be nice if there is a way to automatically allow at least the user that installed it.

BTW I appreciate that the read-only socket works and that I can attach external libvirt versions.
Here the one of Ubuntu Cloud Archive pike listing my guest:

virsh -c qemu+unix:///system?socket=/var/snap/multipass/common/run/libvirt/libvirt-sock-ro list
 Id    Name                           State
----------------------------------------------------
 1     up-pony                        running

Maybe for transparency and ease of use multipass could expose multipass.virsh with slight options:

  1. multipass.virsh could auto-run sudo internally to be allowed to connect (just a wrapper)
  2. multipass.virsh-ro could auto-add the -c for the RO connection

What do you think about that?

After finding the above I was able to add a secondary interface with multiple virtio queues and modified checksumming settings as well as passing through all my cpu features, by adding:.

   <cpu mode='host-passthrough'/>
   ...
    <interface type='bridge'>                                                       
      <source bridge='mpbr0'/>                                                      
      <model type='virtio'/>                                                        
      <driver name='vhost' ioeventfd='on' queues='6'>                               
        <host csum='off'/>
        <guest csum='off'/>               
      </driver>                                                                     
    </interface>

Which is something I’d have had no way to do before - so \o/ !

Hi @paelzer, thanks for testing it out!

The socket should be group-writable by the sudo group, and that’s the case here:

$ ls -lh /var/snap/multipass/common/run/libvirt/*sock*
srwxrwx--- 1 root sudo 0 kwi 21 19:12 /var/snap/multipass/common/run/libvirt/libvirt-sock
srwxrwxrwx 1 root sudo 0 kwi 21 19:12 /var/snap/multipass/common/run/libvirt/libvirt-sock-ro

Do you not have the sudo group? What about the multipass socket:

$ ls -lh /run/multipass_socket 
srw-rw---- 1 root sudo 0 kwi 21 19:12 /run/multipass_socket

As you pointed out, in a snap, we can’t rely on the libvirt group to exist. Similarly we can’t add it and the notion of “the user that installed it” doesn’t exist (yet?). We don’t want it world-writable, sudo group felt like a good compromise.

With that, would you still find virsh-ro desirable?

If we can get the sudo group to work that is a nice compromise indeed.
But for now it isn’t set up like that, while the sudo group exists and e.g. the multipass socket is using it.

srw-rw---- 1 root sudo 0 Apr 23 07:51 /run/multipass_socket=
srwx------ 1 root root 0 Apr 23 07:51 /var/snap/multipass/common/run/libvirt/libvirt-sock=

Any idea why it would be spawning with different groups on my system?
In a non snap system that would be by unix_sock_group = “libvirt” in /etc/libvirt/libvirtd.conf.
How do you control that group allocation at the moment?

What is happening here is that libvirtd.conf is not getting installed. There is a snap install hook that copies the original libvirtd.conf and then changes the libvirtd group to sudo. The reason this has to be done is that libvirtd got changed to libvirt since Xenial. The snap needs to work on all supported distros, so choosing sudo was a compromise.

As far as libvirtd.conf not getting installed, I’m not sure why the install hook didn’t run or failed. Is there anything in the logs to give a clue?

I couldn’t find any reasonable logs for it.
Discussion on #snappy didn’t indicate any better place to check.

So for now I just removed and installed it again.
That fixed it.

Later on I learned of snap changes but the upgrade of multipass is not in there (as I had it installed before).
The last related I have is the change of the backend which had no extra info that could help.

You might consider doing some upgrade tests around it, but other than that I’m good now having sudo group set after the re-install.

Thanks!

@paelzer,

Thanks! It appears the fairly new post-refresh hook should be included for when Multipass refreshes. The officially snap docs don’t mention it, but a forum post does. Go figure…