[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH 0/3] Add dbus-vmstate
From: |
Daniel P . Berrangé |
Subject: |
Re: [Qemu-devel] [PATCH 0/3] Add dbus-vmstate |
Date: |
Mon, 8 Jul 2019 17:04:42 +0100 |
User-agent: |
Mutt/1.12.0 (2019-05-25) |
On Mon, Jul 08, 2019 at 11:24:34AM +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
> address, and save/load from org.qemu.VMState1 owners on migration.
>
> 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).
The downside of using the bus daemon is that we have to spawn a new
instance of dbus-daemon for every QEMU VM that's running on the host,
which is yet more memory overhead for each VM & another process to
manage, and yet another thing to go wrong.
QEMU already has a direct UNIX socket connection to the helper
processes in question. I'd much rather we just had another direct
UNIX socket connection to that helper, using D-Bus peer-to-peer.
The benefit of debugging doesn't feel compelling enough to justify
running an extra daemon for each VM.
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 :|