Re: RFC: towards systemd socket activation in q-s-d

[Daniel P . Berrangé]

On Fri, Jan 27, 2023 at 03:26:15PM -0600, Eric Blake wrote:
> In https://bugzilla.redhat.com/show_bug.cgi?id=2055229, the question
> was raised on how to make qemu-storage-daemon sufficiently powerful to
> be a full-blown replacement to qemu-nbd.  One of the features still
> lacking is the ability to do systemd socket activation (qemu-nbd does
> this, qemu-storage-daemon needs a way to do it).
> 
> But that bug further noted that systemd supports LISTEN_FDNAMES to
> supply names to a passed-in fd (right now, qemu-nbd does not use
> names, but merely expects one fd in LISTEN_FDS).  Dan had the idea
> that it would be nice to write a systemd file that passes in a socket
> name for a QMP socket, as in:
> 
>  [Socket]
>  ListenStream=/var/run/myapp/qsd.qmp
>  FileDescriptorName=qmp
>  Service=myapp-qsd.service
> 
> and further notes that QAPI SocketAddressType supports @fd which is a
> name in QMP (a previously-added fd passed through the older 'getfd'
> command, rather than the newer 'add-fd' command), but an integer on
> the command line.  With LISTEN_FDNAMES, we could mix systemd socket
> activation with named fds for any command line usage that already
> supports SocketAddressType (not limited to just q-s-d usage).

Yes, I think should really frame the problem more generally than
merely q-s-d and/or single sockets, so we don't tie ourselves into
something overly limited in scope.

I'm particularly thinking about our long term desire to be able to
fully manage QEMU system emulators via QMP with zero command line
guest config aspects. q-s-d is simply special in that it is fairly
close in operation to what we want to eventially achieve with the
QEMU system emulators with near 100% QMP configurability.


Currently with runtime configuration we can use getfd to pass a
FD over a UNIX socket, associating it with a name, that you can
reference in SocketAddress structs (and potentially elsewhere).

If we assume that QEMU could be started with  -config /some/guest.json
which contains a sequence of QMP commands, then the 'getfd' command is
not usable because QEMU would just be loading the commands from the
JSON file and have no UNIX socket over which to receive the FDs. 

Obviously at startup QEMU can trivially inherit the FDs from whatever
spawned it. The only task is to identify the FDs that are passed into,
and systemd defined a mechanism for this using LISTEN_FDNAMES. IOW the
socket activation can fully replace 'getfd' for purpose of initial
startup. This will get rid of the annoying difference that SocketAddress
only allows numeric FDs at startup and named FDs at runtime, by making
named FDs the consistent standard. We could thus deprecate the use of
non-named numeric FDs in SocketAddress to improve our sanity.

The question is how to define semantics for the LISTEN_FDNAMES while
also still remaining back compat with the existing QEMU utilities
that allow socket activation. Some kind of naming scheme would need
to be decided upon, as well as handling the use of activation without
LISTEN_FDNAMES BEING SET. 

> I'm at a point where I can take a shot at implementing this, but want
> some feedback on whether it is better to try to shoehorn a generic
> solution into the existing @fd member of the SocketAddressType union,
> or whether it would be better to add yet another union member
> @systemd-fd or some similar name to make it explicit when a command
> line parameter wants to refer to an fd being passed through systemd
> socket activation LISTEN_FDS and friends.

I don't think we should change SocketAddress at all, just use the
@fd member that already exists, by fixing its semantics to always
take an alphanumeric FD name and deprecate the use of pure numeric
FD numbers.

Currently the socket code has an annoying structural connection
to the monitor code, because the monitor is tracking the passed
in FDs.

It would be nice to separate this by introducing some dedicated
APIs for handling named FDs. The monitor can feed named FDs into
this from getfd, and the CLI can feed named FDS into this from
activation.   The socket code can then use these named FD handling
APIs and thus isolate/detach itself from the monitor.

With regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|