[bug#27887] [PATCH] services: Add libvirt services

[Christopher Baines]

On Fri, 18 Aug 2017 17:49:01 -0700
Ryan Moe <address@hidden> wrote:

> >> This looks pretty much ready to be merged to me. Later, I'll try
> >> running this on my machine, just to check that it starts
> >> successfully.  
> >
> > So, I've reconfigured my machine to run both services, and also
> > configured libvirt to use libvirt for the socket group, so that I
> > could add libvirt as a supplemental group for my user. I think this
> > has all worked fine.
> >
> > I tried using the virt-manager to connect, but I'm getting the
> > following error at the moment:
> >
> >
> > Unable to connect to libvirt.
> >
> > internal error: Cannot find suitable emulator for x86_64
> >
> > Libvirt URI is: qemu:///system
> >
> > Traceback (most recent call last):
> >   File
> > "/gnu/store/h61dc28cck9lmp25d1r11d3hzzhz5qnj-virt-manager-1.4.2/share/virt-manager/virtManager/connection.py",
> > line 1108, in _open_thread self._populate_initial_state() File
> > "/gnu/store/h61dc28cck9lmp25d1r11d3hzzhz5qnj-virt-manager-1.4.2/share/virt-manager/virtManager/connection.py",
> > line 1062, in _populate_initial_state logging.debug("conn
> > version=%s", self._backend.conn_version()) File
> > "/gnu/store/h61dc28cck9lmp25d1r11d3hzzhz5qnj-virt-manager-1.4.2/share/virt-manager/virtinst/connection.py",
> > line 322, in conn_version self._conn_version =
> > self._libvirtconn.getVersion() File
> > "/gnu/store/a9g2s8404v8v5pm7m7w8yzr56ba1k331-python2-libvirt-3.4.0/lib/python2.7/site-packages/libvirt.py",
> > line 3863, in getVersion if ret == -1: raise libvirtError
> > ('virConnectGetVersion() failed', conn=self) libvirtError: internal
> > error: Cannot find suitable emulator for x86_64  
> 
> 
> Hi Christopher,
> 
> Thank you for taking a look at this. I have been trying to track down
> this issue for about a week now (I use virt-manager and libvirt daily
> so I'm kind of bummed this stopped working). When I originally
> submitted the patch it worked, I swear I wouldn't have submitted it
> otherwise :)
> 
> At some point I ran a guix pull and a guix system reconfigure and it
> stopped working. The only difference I see is that when I submitted
> the patch libvirt 3.5.0 was the current version and now it's 3.6.0.
> I'm not sure why that would have broken it though.
> 
> The error you see is what happens if you install libvirt without qemu.
> As far as I can tell though qemu is installed. It's also weird because
> it works if I execute the exact same command that shepherd does. You
> can try it yourself:
> 
> 1. Start shepherd service
> 2. ps aux | grep libvirtd
> 3. herd stop libvirtd
> 4. As root, run the complete command from 2 and test with
> virt-manager.

I think running outside of the shepherd works, as the environment will
be different. I think you can look at the environment for the running
process with:

  sudo cat /proc/$(pgrep -f libvirtd | head -n1)/environ

What I see when running the service through the shepherd is very
minimal, and doesn't have a value for PATH.

As I understand it, often in Guix, having a minimal runtime environment
might not be a problem, as packages retain references to their
dependencies from when they were built. If you look at the libvirt
package though, qemu is an input, but the output doesn't reference it.

> My initial thought was that it had something to do with how I was
> installing two packages into the system profile. qemu and libvirt both
> end up there so I don't see why it doesn't work though.

My guess is that the system profile isn't relevant here, as the bin
directory of the system profile isn't on the PATH.

I've written a basic system test for the libvirt service (a patch is
attached), and with that I tested what happens if set the PATH for the
service to explicitly include the QEMU package bin directory, and the
test passes for me with this change.

Back to getting this working though. Either wrapping libvirtd during
the package build to have a PATH including qemu, or including qemu in
the service will work, and I guess the deciding factor might be how
many things libvirt may need to access? Are there lots of other bits of
software that libvirt needs at runtime, where the package doesn't
currently reference them?

0001-tests-Add-libvirt-service-type-test.patch
Description: Text Data

pgpa1GxRE_QGt.pgp
Description: OpenPGP digital signature