qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Kevin Wolf <kwolf@redhat.com>
To: Eric Blake <eblake@redhat.com>
Cc: Programmingkid <programmingkidx@gmail.com>,
	Peter Maydell <peter.maydell@linaro.org>,
	qemu-devel qemu-devel <qemu-devel@nongnu.org>
Subject: Re: [Qemu-devel] Adding Save States menu items
Date: Fri, 7 Oct 2016 10:46:40 +0200	[thread overview]
Message-ID: <20161007084640.GB4589@noname.redhat.com> (raw)
In-Reply-To: <e378bbfc-f592-7e2a-826e-10c2adf43eb8@redhat.com>

[-- Attachment #1: Type: text/plain, Size: 1126 bytes --]

Am 06.10.2016 um 21:59 hat Eric Blake geschrieben:
> Libvirt also learned that the qemu 'migrate-to-disk' format (used by
> 'savevm' or 'migrate') is NOT self-descriptive - in order to fully and
> safely revert to an earlier state, you HAVE to store the command line
> (or a way to regenerate the command line) that was associated with the
> qemu whose state you saved, along with tracking all hotplugs.  Since a
> mere 'savevm' REQUIRES external information to safely be restored, you
> would have to figure out a way to store this additional information
> alongside whatever save files you plan on creating (and please don't
> change the qcow2 file format to become a dumping grounds for this
> additional information).

Have we made any progress regarding this in the past few years? I know
we once intended to get to a state where the migration stream could
include information about which devices exist in the first place.

I guess that's somehow linked to the idea of starting with an empty
machine and then creating all devices and backends with QMP rather than
the command line before actually starting the VM.

Kevin

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

  parent reply	other threads:[~2016-10-07  8:46 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-10-06 14:22 [Qemu-devel] Adding Save States menu items Programmingkid
2016-10-06 14:28 ` Peter Maydell
2016-10-06 14:42   ` Programmingkid
2016-10-06 15:35     ` Paolo Bonzini
2016-10-06 15:48       ` Programmingkid
2016-10-06 15:49         ` Paolo Bonzini
2016-10-06 16:04           ` Programmingkid
2016-10-06 16:17             ` Paolo Bonzini
2016-10-06 17:43               ` Programmingkid
2016-10-06 17:49                 ` Peter Maydell
2016-10-06 17:51                   ` Programmingkid
2016-10-06 20:03               ` Eric Blake
2016-10-06 19:59 ` Eric Blake
2016-10-06 20:10   ` Programmingkid
2016-10-06 20:26     ` Eric Blake
2016-10-07  7:21       ` Paolo Bonzini
2016-10-07  9:14         ` Daniel P. Berrange
2016-10-07 14:39           ` Programmingkid
2016-10-06 20:47   ` Peter Maydell
2016-10-06 21:07     ` Programmingkid
2016-10-07  8:46   ` Kevin Wolf [this message]
2016-10-07  9:09   ` Daniel P. Berrange
2016-10-07 14:55     ` Programmingkid
2016-10-07 14:57       ` Daniel P. Berrange
2016-10-07 14:59       ` Peter Maydell

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=20161007084640.GB4589@noname.redhat.com \
    --to=kwolf@redhat.com \
    --cc=eblake@redhat.com \
    --cc=peter.maydell@linaro.org \
    --cc=programmingkidx@gmail.com \
    --cc=qemu-devel@nongnu.org \
    /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).