From: "Daniel P. Berrangé" <berrange@redhat.com>
To: Kevin Wolf <kwolf@redhat.com>
Cc: Peter Krempa <pkrempa@redhat.com>,
qemu-block@nongnu.org, Juan Quintela <quintela@redhat.com>,
qemu-devel@nongnu.org, Markus Armbruster <armbru@redhat.com>,
Pavel Dovgalyuk <pavel.dovgaluk@ispras.ru>,
Paolo Bonzini <pbonzini@redhat.com>,
Max Reitz <mreitz@redhat.com>,
"Dr. David Alan Gilbert" <dgilbert@redhat.com>
Subject: Re: [PATCH 5/6] migration: support excluding block devs in QMP snapshot commands
Date: Tue, 7 Jul 2020 10:14:56 +0100 [thread overview]
Message-ID: <20200707091456.GD2649462@redhat.com> (raw)
In-Reply-To: <20200706155708.GD5052@linux.fritz.box>
On Mon, Jul 06, 2020 at 05:57:08PM +0200, Kevin Wolf wrote:
> Am 02.07.2020 um 19:57 hat Daniel P. Berrangé geschrieben:
> > This wires up support for a new "exclude" parameter to the QMP commands
> > for snapshots (savevm, loadvm, delvm). This parameter accepts a list of
> > block driver state node names.
> >
> > One use case for this would be a VM using OVMF firmware where the
> > variables store is a raw disk image. Ideally the variable store would be
> > qcow2, allowing its contents to be included in the snapshot, but
> > typically today the variable store is raw. It is still useful to be able
> > to snapshot VMs using OVMF, even if the varstore is excluded, as the
> > main OS disk content is usually the stuff the user cares about.
> >
> > Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
>
> Wouldn't it be better to take an optional list of nodes to _include_
> that just defaults to our current set of nodes?
>
> The problem with excluding is that we already don't snapshot many nodes,
> and the criteria to choose the right ones weren't entirely obvious, so
> we just went with something that seemed to make the most sense. But the
> management application may actually want to snapshot more nodes than we
> cover by default.
>
> I feel things become clearer and less surprising if the client just
> tells us explicitly which images are supposed to be snapshotted instead
> of adding exceptions on top of a default selection that we're already
> not really sure about.
I thought that QEMU just excluded nodes which are not capable of being
snapshotted. By using exclusions, the mgmt apps don't have to know
about what types of storage driver QEMU supports snapshots on, just let
QEMU decide. It also felt simpler to use exclusions as normal case would
be to snapshot everything. Both inclusions/exclusions are easy to
implement in QEMU though.
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:[~2020-07-07 9:16 UTC|newest]
Thread overview: 47+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-07-02 17:57 [PATCH 0/6] migration: bring savevm/loadvm/delvm over to QMP Daniel P. Berrangé
2020-07-02 17:57 ` [PATCH 1/6] migration: improve error reporting of block driver state name Daniel P. Berrangé
2020-07-02 18:36 ` Eric Blake
2020-07-02 19:13 ` Dr. David Alan Gilbert
2020-07-02 17:57 ` [PATCH 2/6] migration: introduce savevm, loadvm, delvm QMP commands Daniel P. Berrangé
2020-07-02 18:12 ` Eric Blake
2020-07-02 18:24 ` Daniel P. Berrangé
2020-07-03 15:49 ` Dr. David Alan Gilbert
2020-07-03 16:02 ` Daniel P. Berrangé
2020-07-03 16:10 ` Dr. David Alan Gilbert
2020-07-03 16:16 ` Daniel P. Berrangé
2020-07-03 16:22 ` Dr. David Alan Gilbert
2020-07-03 16:49 ` Daniel P. Berrangé
2020-07-03 17:00 ` Dr. David Alan Gilbert
2020-07-03 17:10 ` Daniel P. Berrangé
2020-07-03 17:26 ` Dr. David Alan Gilbert
2020-07-03 16:24 ` Peter Krempa
2020-07-03 16:26 ` Dr. David Alan Gilbert
2020-07-06 16:15 ` Kevin Wolf
2020-07-07 6:38 ` Peter Krempa
2020-07-07 10:33 ` Kevin Wolf
2020-07-07 10:41 ` Peter Krempa
2020-07-03 17:22 ` Denis V. Lunev
2020-07-02 17:57 ` [PATCH 3/6] block: add ability to filter out blockdevs during snapshot Daniel P. Berrangé
2020-07-02 17:57 ` [PATCH 4/6] block: allow specifying name of block device for vmstate storage Daniel P. Berrangé
2020-07-02 17:57 ` [PATCH 5/6] migration: support excluding block devs in QMP snapshot commands Daniel P. Berrangé
2020-07-06 15:57 ` Kevin Wolf
2020-07-07 9:14 ` Daniel P. Berrangé [this message]
2020-07-07 10:11 ` Kevin Wolf
2020-07-02 17:57 ` [PATCH 6/6] migration: support picking vmstate disk " Daniel P. Berrangé
2020-07-02 18:19 ` Eric Blake
2020-07-03 8:37 ` Daniel P. Berrangé
2020-07-02 18:53 ` [PATCH 0/6] migration: bring savevm/loadvm/delvm over to QMP no-reply
2020-07-02 19:07 ` no-reply
2020-07-03 17:15 ` Denis V. Lunev
2020-07-03 17:22 ` Daniel P. Berrangé
2020-07-03 17:29 ` Denis V. Lunev
2020-07-06 14:28 ` Daniel P. Berrangé
2020-07-06 16:07 ` Denis V. Lunev
2020-07-06 15:27 ` Kevin Wolf
2020-07-06 15:29 ` Daniel P. Berrangé
2020-07-06 15:50 ` Kevin Wolf
2020-07-06 16:03 ` Daniel P. Berrangé
2020-07-06 16:10 ` Denis V. Lunev
2020-07-06 16:15 ` Daniel P. Berrangé
2020-07-06 16:21 ` Kevin Wolf
2020-07-07 9:07 ` Daniel P. Berrangé
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=20200707091456.GD2649462@redhat.com \
--to=berrange@redhat.com \
--cc=armbru@redhat.com \
--cc=dgilbert@redhat.com \
--cc=kwolf@redhat.com \
--cc=mreitz@redhat.com \
--cc=pavel.dovgaluk@ispras.ru \
--cc=pbonzini@redhat.com \
--cc=pkrempa@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 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).