services: vmware-vmtoolsd: Add vmware-vmtoolsd service.

Reasoning on running these executables outside a VMWare hypervisor is
difficult, which mean we can't implement service tests in current state
of the art in upstream QEMU.

Essentially the first thing any `open-vm-tools' executable checks is
whether it is executing in a VMWare hypervisor via
`CPUID_VMWARE_HYPERVISOR_VENDOR_STRING' [1]. This would fail for any
machine not running inside VMWare.

Marionette evaluations in Guix use QEMU to run the virtual machines that
some tests run on. QEMU emulates and allow configuration of some CPUID
flags and vendor strings. It does not emulate the hypervisor flag, or
allow configuration of the hypervisor vendor flag, which would be
required for this program to run and output anything observable, other
than a non-zero exit code.

In the case someone added upstream QEMU support for custom CPUID
hypervisor flags and vendor strings, these executables would initialize
a log file, but could not test anything meaningful without a hypercall
interface. QEMU sort-of emulates such an interface when it is told to
act like the Xen hypervisor, but doesn't seem to support the required
`vmcall', `vmmcall', or `inl' x86 assembly instruction communication
mechanism between the host and guest.

The Linux KVM supports a limited set of hypercalls [2], but certainly
not the ones required for these executables, the same applies for
Hurd. Since the KVM project already has a functional serial interface
between the guest and host [3], it is a low possibility upstream would
want to greatly expand the `vmcall' hypercall support in any case.

An alternative path would be to add the `USE_VALGRIND' define when
compiling the `vmware-open-vm-tools' package, which skips the hypervisor
CPUID flag checking, but still would require proper hypercall support to
test anything useful.  Additionally, this would require another package,
or perhaps a "testing" output of the `vmware-open-vm-tools' pacakge,
which would be a nearly entire duplicate of the executables and would be
used exclusively for whichever test is written.

1. <https://github.com/vmware/open-vm-tools/blob/stable-13.1.x/open-vm-tools/lib/vmCheck/vmcheck.c#L335>
2. <https://docs.kernel.org/virt/kvm/x86/hypercalls.html>
3. <https://linux-kvm.org/page/VMchannel_Requirements>

* gnu/services/virtualization.scm
(vmware-vmtoolsd-shepherd-service): new procedures.
(vmware-vmtoolsd-service-type): new service type
(vmware-vmtoolsd-configuration): new struct.
update copyright commentary.
* doc/guix.texi (Virtualization Services): document it.

Merges: guix/guix!5098
Modified-by: Sharlatan Hellseher <sharlatanus@gmail.com>
Signed-off-by: Sharlatan Hellseher <sharlatanus@gmail.com>

1 files changed, 27 insertions, 0 deletions

diff --git a/doc/guix.texi b/doc/guix.texi
index 99cef6fce3c..c5fed97da08 100644
--- a/doc/guix.texi
+++ b/doc/guix.texi
@@ -43751,6 +43751,33 @@ How often to run the node cleaning job.  The default is once per day, at
 @end table
 @end deftp
 
+@defvar vmware-vmtoolsd-service-type
+@command{vmtoolsd} is a daemon from
+@url{https://github.com/vmware/open-vm-tools/, the VMWare open-vm-tools
+project} which provides for communication between the host and guest
+operating system. This service manages and runs that daemon.
+
+It takes a @code{vmware-vmtoolsd-configuration} object.
+@end defvar
+
+@deftp {Data Type} vmware-vmtoolsd-configuration
+
+@table @asis
+@item @code{pid-file} (default: @code{"/var/run/vmware-vmtoolsd.pid"})
+The @command{vmtoolsd} pid file.
+
+@item @code{requires-xorg?} (default: @code{#f})
+When @code{#t}, the @command{vmtoolsd} requires the xorg-server to be running
+before the command is started. This is the case for the @command{vmtoolsd}
+command from the @code{vmware-open-vm-tools-gtk} package.
+
+@item @code{vmware-open-vm-tools} (default: @code{vmware-open-vm-tools})
+The @code{vmware-open-vm-tools} package to use for the @command{vmtoolsd}
+command.
+
+@end table
+@end deftp
+
 @node Version Control Services
 @subsection Version Control Services