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

[Ryan Moe]

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

This is because qemu isn't listed in propagated-inputs?

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

Setting the PATH does indeed work, thank you for figuring that out.

> 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?

Libvirt can work with other hypervisors like lxc, openvz, and xen and
it supports lots of storage backends like NFS, LVM, and RBD.