qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: "Dr. David Alan Gilbert" <dgilbert@redhat.com>
To: "Marc-André Lureau" <marcandre.lureau@redhat.com>
Cc: Laurent Vivier <lvivier@redhat.com>,
	Thomas Huth <thuth@redhat.com>,
	berrange@redhat.com, Juan Quintela <quintela@redhat.com>,
	qemu-devel@nongnu.org, Paolo Bonzini <pbonzini@redhat.com>
Subject: Re: [Qemu-devel] [PATCH 0/3] Add dbus-vmstate
Date: Mon, 8 Jul 2019 16:44:06 +0100	[thread overview]
Message-ID: <20190708154406.GL2746@work-vm> (raw)
In-Reply-To: <20190708072437.3339-1-marcandre.lureau@redhat.com>

* Marc-André Lureau (marcandre.lureau@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?
  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
  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.

Dave

> Thus helpers can easily have their state migrated with QEMU, without
> implementing 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)
> 
> The D-Bus protocol can be made to work peer-to-peer, but the most
> common and practical way is through a bus daemon. This also has the
> advantage of increased debuggability (you can eavesdrop on the bus and
> introspect it).
> 
> dbus-vmstate is put into use by the libvirt series "[PATCH 00/23] Use
> a slirp helper process".
> 
> Marc-André Lureau (3):
>   qemu-file: move qemu_{get,put}_counted_string() declarations
>   tests: add qtest_set_exit_status()
>   Add dbus-vmstate object
> 
>  MAINTAINERS                         |   6 +
>  backends/Makefile.objs              |   4 +
>  backends/dbus-vmstate.c             | 497 ++++++++++++++++++++++++++++
>  configure                           |   7 +
>  docs/interop/dbus-vmstate.rst       |  64 ++++
>  docs/interop/index.rst              |   1 +
>  include/migration/qemu-file-types.h |   4 +
>  migration/qemu-file.h               |   4 -
>  tests/Makefile.include              |  18 +-
>  tests/dbus-vmstate-test.c           | 387 ++++++++++++++++++++++
>  tests/dbus-vmstate1.xml             |  12 +
>  tests/libqtest.c                    |  41 +--
>  tests/libqtest.h                    |   9 +
>  13 files changed, 1030 insertions(+), 24 deletions(-)
>  create mode 100644 backends/dbus-vmstate.c
>  create mode 100644 docs/interop/dbus-vmstate.rst
>  create mode 100644 tests/dbus-vmstate-test.c
>  create mode 100644 tests/dbus-vmstate1.xml
> 
> -- 
> 2.22.0.214.g8dca754b1e
> 
--
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK


  parent reply	other threads:[~2019-07-08 15:46 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-07-08  7:24 [Qemu-devel] [PATCH 0/3] Add dbus-vmstate Marc-André Lureau
2019-07-08  7:24 ` [Qemu-devel] [PATCH 1/3] qemu-file: move qemu_{get, put}_counted_string() declarations Marc-André Lureau
2019-07-08  8:03   ` Juan Quintela
2019-07-08  7:24 ` [Qemu-devel] [PATCH 2/3] tests: add qtest_set_exit_status() Marc-André Lureau
2019-07-08  8:04   ` Juan Quintela
2019-07-17 11:50   ` Thomas Huth
2019-07-08  7:24 ` [Qemu-devel] [PATCH 3/3] Add dbus-vmstate object Marc-André Lureau
2019-07-08  8:41   ` Juan Quintela
2019-07-08 16:11     ` Eric Blake
2019-07-10  6:14   ` Paolo Bonzini
2019-07-10  8:05     ` Daniel P. Berrangé
2019-07-08  8:01 ` [Qemu-devel] [PATCH 0/3] Add dbus-vmstate no-reply
2019-07-08  9:35 ` no-reply
2019-07-08 15:44 ` Dr. David Alan Gilbert [this message]
2019-07-08 16:08   ` Daniel P. Berrangé
2019-07-08 16:04 ` Daniel P. Berrangé
2019-07-09  8:26   ` Marc-André Lureau
2019-07-09  9:01     ` Daniel P. Berrangé
2019-07-09 10:47       ` Marc-André Lureau
2019-07-10  9:10         ` Daniel P. Berrangé
2019-07-10  8:53   ` Paolo Bonzini
2019-07-10  9:03     ` Daniel P. Berrangé
2019-07-10  9:54       ` Paolo Bonzini

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=20190708154406.GL2746@work-vm \
    --to=dgilbert@redhat.com \
    --cc=berrange@redhat.com \
    --cc=lvivier@redhat.com \
    --cc=marcandre.lureau@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=quintela@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).