On Mon, Jul 08, 2019 at 04:44:06PM +0100, Dr. David Alan Gilbert wrote: > * Marc-André Lureau (marcandre.lur...@redhat.com) 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 :|
