From: "Daniel P. Berrangé" <berrange@redhat.com>
To: Eric Blake <eblake@redhat.com>,
qemu-devel@nongnu.org, qemu-block@nongnu.org, rjones@redhat.com,
kwolf@redhat.com
Subject: Re: RFC: towards systemd socket activation in q-s-d
Date: Mon, 30 Jan 2023 16:45:08 +0000 [thread overview]
Message-ID: <Y9f0FNvmYwaDzyn1@redhat.com> (raw)
In-Reply-To: <Y9fa+Zm5VLNoDDo0@redhat.com>
On Mon, Jan 30, 2023 at 02:58:01PM +0000, Daniel P. Berrangé wrote:
> > 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.
Some worked examples of what I would like to see being possible.
First the bare minimum, allowing a zero-conf setup (ok not possible
today, but lets assume QEMU can configure machine hardware entirely
via QMP):
$ cat /etc/system/system/myvm.service
[Unit]
Description=My VM
[Service]
Exec=/usr/bin/qemu-system-x86_64
$ cat /etc/system/system/myvm-qmp.socket
[Unit]
Description=My VM QMP
[Socket]
ListenStream=/var/run/myvm-qmp.socket
FileDescriptorName=qmp
So in this example, /usr/bin/qemu-system-x86_64 would be started
with no args, and LISTEN_FDS=1 and LISTEN_FDNAMES=qmp. QEMU will
have declared that 'qmp' is a reserved activation name that results
in creation of a QMP chardev.
This would be functionally equivalent to the following more explicit
syntax, which avoids the reserved name:
$ cat /etc/system/system/myvm.service
[Unit]
Description=My VM
[Service]
Exec=/usr/bin/qemu-system-x86_64 -chardev socket,fd=control,id=qmp0 -qmp chardev=qmp0
$ cat /etc/system/system/myvm-qmp.socket
[Unit]
Description=My VM QMP
[Socket]
ListenStream=/var/run/myvm-qmp.socket
FileDescriptorName=control
which is LISTEN_FDS=1, LISTEN_FDNAMES=control
A more advanced usage would be to pass many FDs for different
tasks:
$ cat /etc/system/system/myvm.service
[Unit]
Description=My VM
[Service]
Exec=/usr/bin/qemu-system-x86_64 \
-chardev socket,fd=control,id=qmp0 -qmp chardev=qmp0 \
-vnc fd=vnc-listen
$ cat /etc/system/system/myvm-qmp.socket
[Unit]
Description=My VM QMP
[Socket]
ListenStream=/var/run/myvm-qmp.socket
FileDescriptorName=control
$ cat /etc/system/system/myvm-vnc.socket
[Unit]
Description=My VM VNC
[Socket]
ListenStream=0.0.0.0:5901
FileDescriptorName=vnc
which is LISTEN_FDS=2, LISTEN_FDNAMES=control,vnc
This can apply to q-s-d too with the -export flag taking a FD name.
eg here we use the implicit QMP socket, and the explicit NBD exports:
$ cat /etc/system/system/mydisks.service
[Unit]
Description=My DISKS
[Service]
Exec=/usr/bin/qemu-storage-daemon \
-blockdev id=pubdisk,.... \
-blockdev id=privdisk,.... \
-export type=nbd,id=nbdpub,node-name=pubdisk,addr.type=fd,addr.fd=nbd-public
-export type=nbd,id=nbdpub,node-name=privdisk,addr.type=fd,addr.fd=nbd-private
$ cat /etc/system/system/mydisks-qmp.socket
[Unit]
Description=My disks QMP
[Socket]
ListenStream=/var/run/mydisks-qmp.socket
FileDescriptorName=qmp
$ cat /etc/system/system/mydisks-nbd-public.socket
[Unit]
Description=My disks Public
[Socket]
ListenStream=0.0.0.0:9000
FileDescriptorName=nbd-public
$ cat /etc/system/system/mydisks-nbd-private.socket
[Unit]
Description=My disks private
[Socket]
ListenStream=/var/run/mydisks-nbd-private.sock
FileDescriptorName=nbd-private
which is LISTEN_FDS=3, LISTEN_FDNAMES=qmp,nbd-public,nbd-private, giving
you a QMP server on a UNIX socket, a private disk on a NBD UNIX socket
and a public disk on a NBD TCP socket.
The above system units are overly simplified for illustration, real
world ones would have more such as SocketMode for unit sockets and
dependencies, etc
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 :|
next prev parent reply other threads:[~2023-01-30 16:45 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-01-27 21:26 RFC: towards systemd socket activation in q-s-d Eric Blake
2023-01-28 7:49 ` Richard W.M. Jones
2023-01-30 14:58 ` Daniel P. Berrangé
2023-01-30 15:44 ` Richard W.M. Jones
2023-01-30 15:51 ` Daniel P. Berrangé
2023-01-30 16:45 ` Daniel P. Berrangé [this message]
2023-01-30 16:55 ` Richard W.M. Jones
2023-01-31 11:17 ` Kevin Wolf
2023-01-31 11:29 ` Daniel P. Berrangé
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Y9f0FNvmYwaDzyn1@redhat.com \
--to=berrange@redhat.com \
--cc=eblake@redhat.com \
--cc=kwolf@redhat.com \
--cc=qemu-block@nongnu.org \
--cc=qemu-devel@nongnu.org \
--cc=rjones@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.