[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH v2 2/2] qapi: Allow introspecting fix for savevm's cooperatio
From: |
Eric Blake |
Subject: |
Re: [PATCH v2 2/2] qapi: Allow introspecting fix for savevm's cooperation with blockdev |
Date: |
Tue, 1 Oct 2019 16:07:29 -0500 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.1.0 |
On 10/1/19 2:34 PM, Markus Armbruster wrote:
Peter Krempa <address@hidden> writes:
savevm was buggy as it considered all monitor owned block device nodes
Recommend "monitor-owned block device nodes" or "block device nodes
owned by a monitor"
for snapshot. With introduction of -blockdev the common usage made all
nodes including protocol nodes monitor owned and thus considered for
snapshot.
What exactly is / was the problem?
Old way: using QMP add_device, you create a drive backend with two BDS
(format and protocol) assigned to it; the drive backend has your given
name, and both BDS have a generated name (beginning with '#'). The two
BDS are not monitor-owned, rather, the drive is.
New way: using QMP blockdev_add, you create the two BDS manually with
names of your choice, then plug that blockdev into an unnamed
blockbackend (the drive no longer needs a name, because you can get at
everything through the BDS name). You _could_ do this in one step (the
QAPI allows self-recursion where you can define both the format and
protocol in one step), but it is easier to do in two steps (define the
protocol BDS first, then define the format BDS using a "string" name of
the protocol BDS instead of a { "driver":..., args... } object of the
protocol layer. But by making two calls, now both BDS are monitor-owned.
At snapshot-time, the code currently looks for all monitor-owned nodes
when deciding what to snapshot. In the old way, this finds the named
drive, picks up its associated top-most node, and snapshots the format
layer. In the new way, the drive is unnamed so it is skipped, while
there are two named BDS, but we don't want a snapshot of the protocol layer.
This was fixed but clients need to be able to detect whether
this fix is present.
Fixed where? Commit hash, if possible.
Pull request:
https://lists.gnu.org/archive/html/qemu-devel/2019-09/msg04773.html
(assuming it doesn't need a respin before landing, 8ec72832)
Since savevm does not have an QMP alternative add the feature for the
Comma after alternative.
'human-monitor-command' backdoor which is used to call this command in
modern use.
Eww. I don't have better ideas short of "design and implement a sane
QMP interface to internal snapshots", which is too much work.
Signed-off-by: Peter Krempa <address@hidden>
---
qapi/misc.json | 9 ++++++++-
1 file changed, 8 insertions(+), 1 deletion(-)
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3226
Virtualization: qemu.org | libvirt.org