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

[Daniel P . Berrangé]

On Fri, Aug 23, 2019 at 03:31:16PM +0400, Marc-André Lureau wrote:
> Hi
> 
> On Fri, Aug 23, 2019 at 3:21 PM Daniel P. Berrangé <address@hidden> wrote:
> >
> > 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")
> 
> 
> There is no need for extra registration if the services are queued.
> You can then query the queue of org.qemu.VhostUser instances.
> 
> This is the approach I took in v1 of this series with
> org.qemu.VMState1 service name.
> 
> See https://patchew.org/QEMU/address@hidden/address@hidden/

I think that's a pretty gross hack tha is abusing the unique service
concept, as we clearly don't have unique services anymore.

> Other approaches are common prefix (ex:
> org.mpris.MediaPlayer2.FooBar), which also allows to identify a
> particular implementation in a simple way.

This means QEMU still has to iterate over every single client
on the bus to identify them. If you're doing that, there's
no point in owning a well known service at all. Just iterate
over the unique bus names and look for the exported object
path /org/qemu/VMState


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