Richard, what do you think?

This discussion should probably go to upstream qemu-devel instead. I believe systemd activation would be a benefit though, as it would make it possible to directly spawn qsd from a system .service unit file with sockets, which is not possible with QEMU's home grown FD passing.

With SystemD activation you can give names to passed in FDs, which are visible in the "LISTEN_FDNAMES" env variable. I'd like to see QEMU support an FD name of 'qmp' to indicate that the passed in FD is to be used to run a QMP monitor.

This would allow for a normal systemd config to spawn QSD with no args and get a QMP socket available to do all runtime config:

 $ cat myapp-qsd.service
 [Unit]
 Description=something QSD something

 [Service]
 ExecStart=/usr/bin/qemu-storage-daemon

 $ cat myapp-qsd-qmp.socket
 [Unit]
 Description=something QSD something socket

 [Socket]
 ListenStream=/var/run/myapp/qsd.qmp
 FileDescriptorName=qmp
 Service=myapp-qsd.service

If we do this it shouldn't be tied to QSD - it should be universal across any QEMU binary that has QMP support

Using 'LISTEN_FDNAMES' we can extend this to other sockets in QEMU too if needed by defining more well known names.

Yup, systemd socket activation is great and generally easy to implement, so why not.
It's a requirement (as well as full and simple command line configuration) if
qsd is ever to replace uses like:

$ nbdcopy -- [ qemu-nbd -r -f qcow2 https://example.com/disk.qcow2 ] -
$ nbdinfo -- [ qemu-nbd -r -f qcow2 file.qcow2 ]
etc

Adding a few more folks for awareness, but indeed should be an upstream discussion - feel free to refer back to this BZ though.

Once we establish a (better?) severity/prioritization/target, we can use this BZ to track.

I thought about this again after my previous comment, and I think we ought to explore how to integrate socket activation with our 'fd' passing support in the SocketAddress struct.

Currently SocketAddressType has:

# @fd: decimal is for file descriptor number, otherwise a file descriptor name.
#      Named file descriptors are permitted in monitor commands, in combination
#      with the 'getfd' command. Decimal file descriptors are permitted at
#      startup or other contexts where no monitor context is active.

The distinction between FDs being named when using QMP and raw FD numbers during startup has always irritated me. With systemd activation, the LISTEN_FDNAMES env variable gives names to each passed in FD at startup. We could make use of this, to allow SocketAddressType to support named FDs during startup, on a par with what's possible with QMP already.

If we did this, then any QEMU program with command line args that have a mapping to the SocketAddress  struct will get transparent support for socket activation usage. This will be way more general purpose than the limited socket activation support we have today.

However you do it, please make it compatible with
https://libguestfs.org/nbd_connect_systemd_socket_activation.3.html

I'm not sure if I would shoehorn socket activation into the existing 'fd' SocketAddress type or add a separate new type, but I agree that any SocketAddress(Legacy) user should automatically support this and am pretty sure I argued for it already in past upstream discussions about this. But the final design needs to be discussed upstream again anyway.

Revisiting this bug; I've tried to start an upstream discussion:
https://lists.nongnu.org/archive/html/qemu-block/2023-01/msg00710.html

However, as it does need to play out in upstream first, it's hard to state what timeline we can expect for downstream usage of whatever solution the list settles on.

What is the development plan? 
Does it need to close this or extend the stale date?

(In reply to qing.wang from comment #11)
> What is the development plan? 
> Does it need to close this or extend the stale date?

At present, this has not received any upstream traction. I intend to revive the topic upstream once 64-bit NBD extensions have landed, but that does mean that it is likely that it may take more than 30 days before this bug is addressed.

Issue migration from Bugzilla to Jira is in process at this time. This will be the last message in Jira copied from the Bugzilla bug.