Re: [Qemu-devel] [PATCH v2 0/2] Add dbus-vmstate

[Daniel P . Berrangé]

On Thu, Aug 08, 2019 at 07:03:23PM +0400, Marc-André Lureau wrote:
> Hi,
> 
> With external processes or helpers participating to the VM support, it
> becomes necessary to handle their migration. Various options exist to
> transfer their state:
> 1) as the VM memory, RAM or devices (we could say that's how
>    vhost-user devices can be handled today, they are expected to
>    restore from ring state)
> 2) other "vmstate" (as with TPM emulator state blobs)
> 3) left to be handled by management layer
> 
> 1) is not practical, since an external processes may legitimatelly
> need arbitrary state date to back a device or a service, or may not
> even have an associated device.
> 
> 2) needs ad-hoc code for each helper, but is simple and working
> 
> 3) is complicated for management layer, QEMU has the migration timing
> 
> The proposed "dbus-vmstate" object will connect to a given D-Bus
> peer address, and save/load from org.qemu.VMState1 interface.
> 
> This way, helpers can have their state migrated with QEMU, without
> implementing another ad-hoc support (such as done for TPM emulation)
> 
> I chose D-Bus as it is ubiquitous on Linux (it is systemd IPC), and
> can be made to work on various other OSes. There are several
> implementations and good bindings for various languages.
> (the tests/dbus-vmstate-test.c is a good example of how simple
> the implementation of services can be, even in C)
> 
> v2:
> - D-Bus is most common and practical through a bus, but it requires a
>   daemon to be running. I argue that the benefits outweight the cost
>   of running an extra daemon in v1 in the context of multi-process
>   qemu, but it is also possible to connect in p2p mode as done in this
>   new version.

So yesterday Stefanha brought up need for "mgmt apis" on the
virtiofsd helper process & the conclusion is that dbus makes
most sense for this purpose:

  https://www.redhat.com/archives/virtio-fs/2019-August/msg00339.html

This use case is a slightly different from vmstate though.

For vmstate we have two parties - virtiofsd and QEMU talking

For the "mgmt apis" in virtiofsd, we have arbitrary parties
involved - virtiofsd *and* an admin client tool, and/or
maybe libvirt.

I think this different scenario means that we do in fact need
to have a bus present, as the p2p model doesn't scale well
to many clients.

Even if we have 1 dbus-daemon per QEMU instance, we need to cope
with multiple instances of the same helper needing to connect.
So we need to come up with some for identifying services. Normally
DBus only allows 1 peer to own a given well known service name at
any time.  So we can't simply talk to a well-known 'org.qemu.virtiofsd'
service name.

Each service would need to to just rely on exporting objects under
its unique service id  (they look like :1.NNNN for some uniq NNN)

QEMU still needs to known which connections on the bus are actually
providing vhost-user services, and which are other things (like
libvirt or random mgmt tools)

So perhaps QEMU should expose a service  'org.qemu.VhostUserManager'
with an object /org/qemu/VhostUSerManager

Each helper supporting vmstate could register its existance
by invoking a method

   org.qemu.VhostUserManager.Register(":1.NNNN")

For things we want every vhost user daemon to implement, we can
define well known objects paths & intefaces to expose at the path.

eg If the helper supports vmstate dump, it should export an object
at the well known path "/org/qemu/VMState" with methods x, y & z

If the helper supports debug logging it should export an object at
the well known path "/org/qemu/Logger" with method a, b & c

etc

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 :|