From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MoYf1-0002s8-12 for qemu-devel@nongnu.org; Fri, 18 Sep 2009 04:17:43 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MoYew-0002kM-AQ for qemu-devel@nongnu.org; Fri, 18 Sep 2009 04:17:42 -0400 Received: from [199.232.76.173] (port=35527 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MoYew-0002jy-4H for qemu-devel@nongnu.org; Fri, 18 Sep 2009 04:17:38 -0400 Received: from david.siemens.de ([192.35.17.14]:21757) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1MoYev-0002jH-LH for qemu-devel@nongnu.org; Fri, 18 Sep 2009 04:17:38 -0400 Message-ID: <4AB3421C.3090207@siemens.com> Date: Fri, 18 Sep 2009 10:17:32 +0200 From: Jan Kiszka MIME-Version: 1.0 References: <1253237786.7425.145.camel@athens.parenthephobia.org.uk> <20090918015213.GA22922@shareable.org> <1253259746.7425.182.camel@athens.parenthephobia.org.uk> In-Reply-To: <1253259746.7425.182.camel@athens.parenthephobia.org.uk> Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] Re: [RFC][PATCH] Option to continue after migration List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Nathan Baum Cc: qemu-devel@nongnu.org, lirans@il.ibm.com 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