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

["Daniel P. Berrangé" <berrange@redhat.com>]

On Mon, Jul 08, 2019 at 11:24:34AM +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
> address, and save/load from org.qemu.VMState1 owners on migration.
> 
> Thus helpers can easily have their state migrated with QEMU, without
> implementing 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)
> 
> The D-Bus protocol can be made to work peer-to-peer, but the most
> common and practical way is through a bus daemon. This also has the
> advantage of increased debuggability (you can eavesdrop on the bus and
> introspect it).

The downside of using the bus daemon is that we have to spawn a new
instance of dbus-daemon for every QEMU VM that's running on the host,
which is yet more memory overhead for each VM & another process to
manage, and yet another thing to go wrong.

QEMU already has a direct UNIX socket connection to the helper
processes in question. I'd much rather we just had another direct
UNIX socket  connection to that helper, using D-Bus peer-to-peer.
The benefit of debugging doesn't feel compelling enough to justify
running an extra daemon for each VM.


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