On Tue, Jul 01, 2025 at 02:02:05PM -0400, Daniel Kahn Gillmor wrote:
> On Tue 2025-07-01 10:38:02 +0100, Daniel P. Berrangé wrote:
> > Primarily this comes down to having logic present in the socket_get_fd
> > method, such that when there is no current monitor, we use the systemd
> > named sockets.
>
> I'm not sure how the monitor plays a role here. Are you talking about
> having a socket-activated monitor specifically, or do you see the
> monitor playing some special role in socket activation beyond just being
> yet another file descriptor that might be passed in via systemd-style
> supervision? why wouldn't it be OK to have a monitor *and* use systemd
> named sockets? Looking at socket_get_fd, i see that it's resolving the
> fdstr differently if there is a current monitor; is that codepath only
> active after all command-line arguments have been processed?
The monitor is involved in so much as the socket_get_fd() method
is what internal QEMU code uses to resolve FD names into FD numbers.
The first thing it does is check whether the caller is runing in
the context of a monitor command. If so, it resolves FD names using
the monitor, otherwise it'll assume an FD has been passed in by the
parent process. The latter codepath is the one we need to enhance
to use systemd named FDs. Essentially this latter codepath will only
run during initial QEMU startup, as at runtimne, all callers will
be in the context of the monitor.
> > We should also have logic to validate that we have consumed all
> > systemd sockets, before we move out of startup phase, in order to
> > detect config errors. This indicates should we proactively parse
> > the socket activation env at starutp and record all FDs, and keep
> > track of which are consumed by the config.
>
> Could you be a bit more specific about how the "startup phase" is
> delimited within the codebase? I'd be happy to try to build out
> something similar to what you describe here, if you think that would be
> useful. I'd want to make sure i place the check for all passed file
> descriptors being accounted for in the right place.
In system/vl.c the 'qemu_init' method takes care of system
startup - so at the very end of that method we should check
for unclaimed FDs.
> > And then there are some hard questions about how we integrate this with
> > the various helper programs like qemu-nbd, and friends, which all
> > already support systemd socket activation but fail to validate the
> > names, making it hard to add propert support while retaining back compat.
>
> Understood -- from looking at the sources i think that means this
> specific list of four helper programs:
>
> - qemu-nbd (network block device server)
> - qemu-ga (the qemu guest agent)
> - qemu-pr-helper (qemu SCSI persistent reservation helper)
> - qemu-vmsr-helper (i386 only?)
>
> all of these processes currently just accept a single listening socket,
> and ignore the names. They all abort if they are passed more than one
> socket via systemd-style supervision. With the exception of qga, they
> all abort with an error if they are passed listener configuration
> information while also being launched under systemd-style supervision
> with a socket.
>
> I don't see this narrow scope of functionality as being a difficult to
> maintain for backward-compatibility.
>
> We can simply offer a mechanism that these tools can use with the
> semantics of "if only one socket-activated listener, claim it".
>
> As far as i can tell, none of these four helper daemons is designed to
> listen on more than one socket anyway.
Well that's their current impl, but conceptually it is interesting
to be able to listen on multiple sockets, so that machines with
multiple public facing IP addresses can be made to listen on a
selection of IPs, instead of the wildcard address, or a single
address. So it is an interesting facility to gain if it is easy.
> The idea is that rather than just being able to pass a file
> descriptor by name anywhere that you can pass a file descriptor by
> number, qemu could use the name of the file descriptor to decide what
> to do with it.
>
> So, for example, rather than running:
>
> qemu -chardev socket,id=foo,opt=123,server=on ...
>
> the administrator could set up a systemd .socket file with:
>
> FileDescriptorName=id=foo,opt=123
>
> and have the corresponding systemd .service file would launch:
>
> ExecStart=/usr/bin/qemu ...
>
> One of the logistical challenges for that is that the colon (":")
> isn't permitted in FileDescriptorName, and some qemu options might
> want a colon in them. And, this approach with -chardev doesn't
> necessarily translate well to all the various places that might also
> want a file descriptor (e.g. -incoming, -object, -spice, etc).
>
> So like i said, probably too radical, but i thought i'd mention it.
It gets even more troublesome when we consider our long term direction
is to support JSON documents for command line args. The plain FD names
are a good decoupling of CLI syntax from the service manager.
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 :|
