Hi On Fri, Aug 23, 2019 at 3:21 PM Daniel P. Berrangé <berra...@redhat.com> 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/20190708072437.3339-1-marcandre.lur...@redhat.com/20190708072437.3339-4-marcandre.lur...@redhat.com/ as well as the libvirt series https://patchew.org/Libvirt/20190708070747.1962-1-marcandre.lur...@redhat.com/ Other approaches are common prefix (ex: org.mpris.MediaPlayer2.FooBar), which also allows to identify a particular implementation in a simple way. > > 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 :|
