From: "Marc-André Lureau" <marcandre.lureau@redhat.com>
To: "Daniel P. Berrangé" <berrange@redhat.com>
Cc: Laurent Vivier <lvivier@redhat.com>,
Thomas Huth <thuth@redhat.com>,
Juan Quintela <quintela@redhat.com>,
qemu-devel <qemu-devel@nongnu.org>,
"Dr. David Alan Gilbert" <dgilbert@redhat.com>,
Stefan Hajnoczi <stefanha@redhat.com>,
Paolo Bonzini <pbonzini@redhat.com>
Subject: Re: [Qemu-devel] [PATCH v2 0/2] Add dbus-vmstate
Date: Fri, 23 Aug 2019 15:31:16 +0400 [thread overview]
Message-ID: <CAMxuvayoLetZkJ_HNKxC8Y0Yk33hn5pHLLn32R-XCuD7z31i=Q@mail.gmail.com> (raw)
In-Reply-To: <20190823112053.GE9654@redhat.com>
Hi
On Fri, Aug 23, 2019 at 3:21 PM Daniel P. Berrangé <berrange@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.lureau@redhat.com/20190708072437.3339-4-marcandre.lureau@redhat.com/
as well as the libvirt series
https://patchew.org/Libvirt/20190708070747.1962-1-marcandre.lureau@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 :|
next prev parent reply other threads:[~2019-08-23 11:33 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-08-08 15:03 [Qemu-devel] [PATCH v2 0/2] Add dbus-vmstate Marc-André Lureau
2019-08-08 15:03 ` [Qemu-devel] [PATCH v2 1/2] qemu-file: move qemu_{get, put}_counted_string() declarations Marc-André Lureau
2019-08-09 18:32 ` Dr. David Alan Gilbert
2019-08-08 15:03 ` [Qemu-devel] [PATCH v2 2/2] Add dbus-vmstate object Marc-André Lureau
2019-08-08 15:07 ` Marc-André Lureau
2019-08-22 10:55 ` Dr. David Alan Gilbert
2019-08-22 11:35 ` Marc-André Lureau
2019-08-22 11:41 ` Dr. David Alan Gilbert
2019-08-22 11:57 ` Marc-André Lureau
2019-08-22 12:19 ` Dr. David Alan Gilbert
2019-08-22 12:38 ` Marc-André Lureau
2019-08-22 12:51 ` Dr. David Alan Gilbert
2019-08-23 11:20 ` [Qemu-devel] [PATCH v2 0/2] Add dbus-vmstate Daniel P. Berrangé
2019-08-23 11:31 ` Marc-André Lureau [this message]
2019-08-23 11:41 ` Daniel P. Berrangé
2019-08-23 11:47 ` Marc-André Lureau
2019-08-23 13:00 ` Dr. David Alan Gilbert
2019-08-23 13:48 ` Marc-André Lureau
2019-08-23 14:09 ` Daniel P. Berrangé
2019-08-23 14:09 ` Dr. David Alan Gilbert
2019-08-23 14:20 ` Daniel P. Berrangé
2019-08-23 14:26 ` Dr. David Alan Gilbert
2019-08-23 14:40 ` Daniel P. Berrangé
2019-08-23 14:56 ` Dr. David Alan Gilbert
2019-08-23 15:05 ` Daniel P. Berrangé
2019-08-23 15:14 ` Dr. David Alan Gilbert
2019-08-23 15:21 ` Daniel P. Berrangé
2019-08-23 15:24 ` Dr. David Alan Gilbert
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAMxuvayoLetZkJ_HNKxC8Y0Yk33hn5pHLLn32R-XCuD7z31i=Q@mail.gmail.com' \
--to=marcandre.lureau@redhat.com \
--cc=berrange@redhat.com \
--cc=dgilbert@redhat.com \
--cc=lvivier@redhat.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=quintela@redhat.com \
--cc=stefanha@redhat.com \
--cc=thuth@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).