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

[Daniel P . Berrangé]

On Mon, Jul 08, 2019 at 04:44:06PM +0100, Dr. David Alan Gilbert wrote:
> * Marc-André Lureau (address@hidden) 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.
> 
> Some very high level questions:
>   a) If I've got two QEMU's running, how do the right devices
>    end up migrating to the right qemu?

This isn't using the normal DBus instance. It needs a new isntance of
dbus-daemon to be spawned for each VM IIUC.

>   b) Why use dbus for the comms? Don't all of the daemons have some
>    protocol'd socket between QEMU and the daemon? If so they could
>    send up a separate FD for migration data

There's two distinct aspects here

 - Whether to use a bus vs peer-to-peer
 - What protocol to run over the wire

DBus defines a low level wire protocol. It just happens that it is
commonly used in bus topology, but it is fine being used peer-to-peer
instead.

IOW, we could use Dbus as the wire encoding, and still have a direct
FD betwwen QEMU & the helper program, without needign dbus-daemon
present.

>   c) Your 1MB limit is pretty aribtary - it's nice to have a limit
>     but it's hard to justify why it's that one.

IIRC, that's the default DBus message size limit. You can choose to
raise that in the client & server impl if desired, or alternatively
just pass back a memfd() handle with the DBus relpy, over which to
access the bulk data out of band.

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