All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jan Kiszka <jan.kiszka@siemens.com>
To: Nathan Baum <nathan@parenthephobia.org.uk>
Cc: qemu-devel@nongnu.org, lirans@il.ibm.com
Subject: [Qemu-devel] Re: [RFC][PATCH] Option to continue after migration
Date: Fri, 18 Sep 2009 10:17:32 +0200	[thread overview]
Message-ID: <4AB3421C.3090207@siemens.com> (raw)
In-Reply-To: <1253259746.7425.182.camel@athens.parenthephobia.org.uk>

Nathan Baum wrote:
> I see from browsing the list a little more that I should have stuck
> [RFC] in my subject lin.
> 
> On Fri, 2009-09-18 at 02:52 +0100, Jamie Lokier wrote:
>> Nathan Baum wrote:
>>> Hello,
>>>
>>> This patch adds a -c "continue" option to the migrate command which
>>> causes the originating VM to remain running after migration, assuming it
>>> was running before.
>>>
>>> I've done this primarily so that I can do "migrate -d -c exec:cat>file"
>>> to take a snapshot without needing to have a snapshot-capable drive
>>> attached, or wait until migration is complete and continue the VM
>>> manually.
>> When you later resume from the snapshot, isn't the state of virtual
>> disks corrupted by the activity after the snapshot was taken?  When
>> the guest resumes, even though the disks will be corrupted, it won't
>> _know_ they are corrupted (unlike a reboot), so may proceed to make
>> things worse.
> 
> Yes. This is not specific to my patch, but it does limit its
> applicability.
> 
> You probably only want to snapshot-and-continue if you have no writable
> media -- i.e. you're booting a LiveCD, or you have writable media in
> snapshot mode, have stopped and committed immediately before saving the
> state this way, and haven't committed since.
> 
> In this latter case, my patch wouldn't be useful to you since you
> stopped the VM prior to the commit anyway, and my patch only continues
> if the VM is still running at the end of the migration. (Maybe it should
> force a continue; then you could chuck "stop\ncommit all\nmigrate -d
> -c ..." at the monitor.)
> 
> I think a far superior alternative approach would be to add "-snapshots
> file" option (or similar) to specify a file savevm/loadvm should use for
> VM state, and a "-snapshotsdir dir" option which makes QEMU quietly
> replace each not-snapshot-capable drive with a qcow2 based on it in that
> directory. (Or all the snapshot data could be in the snapshots file;
> that looks more complicated to implement.)

"Migration without shared storage" should once solve this, see Liran's
patches [1]. Your patch will be very helpful in that scenario.

Jan

[1] http://permalink.gmane.org/gmane.comp.emulators.qemu/52252

-- 
Siemens AG, Corporate Technology, CT SE 2
Corporate Competence Center Embedded Linux

  reply	other threads:[~2009-09-18  8:17 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-09-18  1:36 [Qemu-devel] [PATCH] Option to continue after migration Nathan Baum
2009-09-18  1:52 ` Jamie Lokier
2009-09-18  7:42   ` [Qemu-devel] [RFC][PATCH] " Nathan Baum
2009-09-18  8:17     ` Jan Kiszka [this message]
2009-09-30 13:46 ` [Qemu-devel] [PATCH] " Anthony Liguori

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=4AB3421C.3090207@siemens.com \
    --to=jan.kiszka@siemens.com \
    --cc=lirans@il.ibm.com \
    --cc=nathan@parenthephobia.org.uk \
    --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 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.