From: Markus Armbruster <armbru@redhat.com>
To: "Daniel P. Berrangé" <berrange@redhat.com>
Cc: Kevin Wolf <kwolf@redhat.com>,
qemu-block@nongnu.org, Juan Quintela <quintela@redhat.com>,
qemu-devel@nongnu.org, Max Reitz <mreitz@redhat.com>,
Pavel Dovgalyuk <pavel.dovgaluk@ispras.ru>,
Paolo Bonzini <pbonzini@redhat.com>, John Snow <jsnow@redhat.com>,
"Dr. David Alan Gilbert" <dgilbert@redhat.com>
Subject: Re: [PATCH v9 11/11] migration: introduce snapshot-{save, load, delete} QMP commands
Date: Wed, 20 Jan 2021 15:39:36 +0100 [thread overview]
Message-ID: <878s8npt93.fsf@dusky.pond.sub.org> (raw)
In-Reply-To: <20210120104411.3084801-12-berrange@redhat.com> ("Daniel P. Berrangé"'s message of "Wed, 20 Jan 2021 10:44:11 +0000")
Daniel P. Berrangé <berrange@redhat.com> writes:
> savevm, loadvm and delvm are some of the few HMP commands that have never
> been converted to use QMP. The reasons for the lack of conversion are
> that they blocked execution of the event thread, and the semantics
> around choice of disks were ill-defined.
>
> Despite this downside, however, libvirt and applications using libvirt
> have used these commands for as long as QMP has existed, via the
> "human-monitor-command" passthrough command. IOW, while it is clearly
> desirable to be able to fix the problems, they are not a blocker to
> all real world usage.
>
> Meanwhile there is a need for other features which involve adding new
> parameters to the commands. This is possible with HMP passthrough, but
> it provides no reliable way for apps to introspect features, so using
> QAPI modelling is highly desirable.
>
> This patch thus introduces new snapshot-{load,save,delete} commands to
> QMP that are intended to replace the old HMP counterparts. The new
> commands are given different names, because they will be using the new
> QEMU job framework and thus will have diverging behaviour from the HMP
> originals. It would thus be misleading to keep the same name.
>
> While this design uses the generic job framework, the current impl is
> still blocking. The intention that the blocking problem is fixed later.
> None the less applications using these new commands should assume that
> they are asynchronous and thus wait for the job status change event to
> indicate completion.
>
> In addition to using the job framework, the new commands require the
> caller to be explicit about all the block device nodes used in the
> snapshot operations, with no built-in default heuristics in use.
>
> Note that the existing "query-named-block-nodes" can be used to query
> what snapshots currently exist for block nodes.
>
> Acked-by: Markus Armbruster <armbru@redhat.com>
> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Looks good to me, my Acked-by stands.
next prev parent reply other threads:[~2021-01-20 14:41 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-01-20 10:44 [PATCH v9 00/11] migration: bring improved savevm/loadvm/delvm to QMP Daniel P. Berrangé
2021-01-20 10:44 ` [PATCH v9 01/11] block: push error reporting into bdrv_all_*_snapshot functions Daniel P. Berrangé
2021-01-20 10:44 ` [PATCH v9 02/11] migration: Make save_snapshot() return bool, not 0/-1 Daniel P. Berrangé
2021-01-20 18:46 ` Eric Blake
2021-01-20 18:48 ` Eric Blake
2021-01-25 16:41 ` Dr. David Alan Gilbert
2021-01-20 10:44 ` [PATCH v9 03/11] migration: stop returning errno from load_snapshot() Daniel P. Berrangé
2021-01-20 10:44 ` [PATCH v9 04/11] block: add ability to specify list of blockdevs during snapshot Daniel P. Berrangé
2021-01-20 10:44 ` [PATCH v9 05/11] block: allow specifying name of block device for vmstate storage Daniel P. Berrangé
2021-01-20 10:44 ` [PATCH v9 06/11] block: rename and alter bdrv_all_find_snapshot semantics Daniel P. Berrangé
2021-01-20 18:48 ` Eric Blake
2021-01-20 10:44 ` [PATCH v9 07/11] migration: control whether snapshots are ovewritten Daniel P. Berrangé
2021-01-20 10:44 ` [PATCH v9 08/11] migration: wire up support for snapshot device selection Daniel P. Berrangé
2021-01-20 17:31 ` Eric Blake
2021-01-20 10:44 ` [PATCH v9 09/11] migration: introduce a delete_snapshot wrapper Daniel P. Berrangé
2021-01-20 17:32 ` Eric Blake
2021-01-20 10:44 ` [PATCH v9 10/11] iotests: add support for capturing and matching QMP events Daniel P. Berrangé
2021-01-20 18:38 ` Eric Blake
2021-01-20 10:44 ` [PATCH v9 11/11] migration: introduce snapshot-{save, load, delete} QMP commands Daniel P. Berrangé
2021-01-20 14:39 ` Markus Armbruster [this message]
2021-01-20 18:58 ` Eric Blake
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=878s8npt93.fsf@dusky.pond.sub.org \
--to=armbru@redhat.com \
--cc=berrange@redhat.com \
--cc=dgilbert@redhat.com \
--cc=jsnow@redhat.com \
--cc=kwolf@redhat.com \
--cc=mreitz@redhat.com \
--cc=pavel.dovgaluk@ispras.ru \
--cc=pbonzini@redhat.com \
--cc=qemu-block@nongnu.org \
--cc=qemu-devel@nongnu.org \
--cc=quintela@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.