All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Dr. David Alan Gilbert" <dgilbert@redhat.com>
To: "Daniel P. Berrange" <berrange@redhat.com>
Cc: Max Reitz <mreitz@redhat.com>, Eric Blake <eblake@redhat.com>,
	Richard Palethorpe <richiejp@f-m.fm>,
	qemu-devel@nongnu.org, Qemu-block <qemu-block@nongnu.org>,
	quintela@redhat.com, armbru@redhat.com, rpalethorpe@suse.com
Subject: Re: [Qemu-devel] [PATCH 1/2] Add save-snapshot, load-snapshot and delete-snapshot to QAPI
Date: Thu, 11 Jan 2018 13:23:05 +0000	[thread overview]
Message-ID: <20180111132304.GD2669@work-vm> (raw)
In-Reply-To: <20180111130427.GG8326@redhat.com>

* Daniel P. Berrange (berrange@redhat.com) wrote:
> On Thu, Jan 11, 2018 at 01:46:38PM +0100, Max Reitz wrote:
> > On 2018-01-08 14:52, Eric Blake wrote:
> > > On 01/07/2018 06:23 AM, Richard Palethorpe wrote:
> > >> Add QAPI wrapper functions for the existing snapshot functionality. These
> > >> functions behave the same way as the HMP savevm, loadvm and delvm
> > >> commands. This will allow applications, such as OpenQA, to programmatically
> > >> revert the VM to a previous state with no dependence on HMP or qemu-img.
> > > 
> > > That's already possible; libvirt uses QMP's human-monitor-command to
> > > access these HMP commands programmatically.
> > > 
> > > We've had discussions in the past about what it would take to have
> > > specific QMP commands for these operations; the biggest problem is that
> > > these commands promote the use of internal snapshots, and there are
> > > enough performance and other issues with internal snapshots that we are
> > > not yet ready to commit to a long-term interface for making their use
> > > easier.  At this point, our recommendation is to prefer external snapshots.
> > 
> > We already have QMP commands for internal snapshots, though.  Isn't the
> > biggest issue that savevm takes too much time to be a synchronous QMP
> > command?
> 
> Ultimately savevm/loadvm are using much of the migration code internally,
> but are not exposed as URI schemes. Could we perhaps take advantage of
> the internal common layer and define a migration URI scheme
> 
>    snapshot:<name>
> 
> where '<name>' is the name of the internal snapshot in the qcow2 file.

I had wondered about that; I'd just thought of doing the migration
saving to a block device rather than the rest of the snapshot activity around it; 
but I guess that's possible.

> Then you could just use the regular migrate QMP commands for loading
> and saving snapshots.  Might need a little extra work on the incoming
> side, since we need to be able to load snapshots, despite QEMU not
> being started with '-incoming defer', but might still be doable ?
> This would theoretically give us progress monitoring, cancellation,
> etc for free.

What actually stops this working other than the sanity check in
migrate_incoming ?

Dave

> 
> 
> 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 :|
--
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK

  reply	other threads:[~2018-01-11 13:23 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-01-07 12:23 [Qemu-devel] [PATCH 1/2] Add save-snapshot, load-snapshot and delete-snapshot to QAPI Richard Palethorpe
2018-01-07 12:23 ` [Qemu-devel] [PATCH 2/2] Add test cases for saving, loading and deleting snapshots using QAPI Richard Palethorpe
2018-01-08 13:52 ` [Qemu-devel] [PATCH 1/2] Add save-snapshot, load-snapshot and delete-snapshot to QAPI Eric Blake
2018-01-10 16:19   ` Richard Palethorpe
2018-01-10 16:48     ` Eric Blake
2018-02-03 13:28       ` Markus Armbruster
2018-01-11 12:46   ` Max Reitz
2018-01-11 13:04     ` Daniel P. Berrange
2018-01-11 13:23       ` Dr. David Alan Gilbert [this message]
2018-01-11 13:36         ` Daniel P. Berrange
2018-01-11 16:55           ` Juan Quintela
2018-02-12 13:25             ` Richard Palethorpe
2018-02-13 10:50       ` [Qemu-devel] [Qemu-block] " Kevin Wolf
2018-02-13 11:43         ` Dr. David Alan Gilbert
2018-02-13 11:51           ` Daniel P. Berrangé
2018-02-13 13:20             ` Kevin Wolf
2018-02-13 13:25               ` Daniel P. Berrangé
     [not found]         ` <20180213143001.GA2354@rkaganb.sw.ru>
2018-02-13 14:36           ` Daniel P. Berrangé
2018-02-13 14:45             ` Kevin Wolf
2018-02-13 14:48               ` Daniel P. Berrangé
2018-02-13 14:51                 ` Denis V. Lunev
2018-02-13 14:59                 ` Dr. David Alan Gilbert
2018-02-13 15:01                   ` Denis V. Lunev
2018-02-13 15:05                     ` Dr. David Alan Gilbert
     [not found]                       ` <20180213151352.GF2307@rkaganb.sw.ru>
2018-02-13 15:27                         ` Dr. David Alan Gilbert
2018-02-13 15:29                           ` Denis V. Lunev
2018-02-13 16:01                       ` Denis Plotnikov
2018-02-15 15:21                         ` Dr. David Alan Gilbert
2018-02-13 16:46                 ` Eric Blake
2018-02-13 19:45                   ` Denis V. Lunev
2018-02-13 14:43           ` Kevin Wolf
2018-02-13 14:50             ` Denis V. Lunev
2018-02-13 14:58             ` Daniel P. Berrangé
2018-02-13 15:23               ` Kevin Wolf
2018-02-13 15:30                 ` Daniel P. Berrangé
2018-02-13 15:51                   ` Kevin Wolf
2018-02-13 16:14             ` Denis Plotnikov
2018-01-10  6:17 ` [Qemu-devel] " Peter Xu

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=20180111132304.GD2669@work-vm \
    --to=dgilbert@redhat.com \
    --cc=armbru@redhat.com \
    --cc=berrange@redhat.com \
    --cc=eblake@redhat.com \
    --cc=mreitz@redhat.com \
    --cc=qemu-block@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    --cc=quintela@redhat.com \
    --cc=richiejp@f-m.fm \
    --cc=rpalethorpe@suse.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.