Hi Daniel--
Thanks for the followup and the background. What you say makes sense to
me, but i don't know enough about the plumbing to know how i would go
about trying to help make it happen. I ask a few questions below for
hints on how i might move forward.
On Tue 2025-07-01 10:38:02 +0100, Daniel P. Berrangé wrote:
> Spice is rather an odd-ball part of QEMU today that isn't using modern
> best practice config design, so what looks simple from a Spice POV is
> not aligned with what we need for QEMU.
Fair enough, i'd be happy to put the spice work on the back burner and
get the systemd socket activation by named file descriptor normalized
first.
> IMHO for systemd socket activation, we want to introduce the ability
> to reference sockets by name at startup, so it is aligned with what
> we can do at runtime.
Agreed, this makes sense to me.
> 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?
> 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.
> Meanwhile both -vnc and -spice need updating to have their CLI
> modelled in QAPI, and use the SocketAdddress struct config, which
> would unlock FD passing both with & without systemd socket activation.
I'm happy to leave the -vnc and -spice alone for now, if we can get
name-based socket activation normalized and stable.
> 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.
--dkg
PS in the course of thinking through this patch, one alternate approach
did occur to me, but i'm not inclined to follow it as it might be too
radical. I thought i'd note it here anyway, in case anyone thinks
it's interesting, or (alternately) wants to definitively close the
door on it.
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.
