From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LPwHv-0001Fi-6p for qemu-devel@nongnu.org; Thu, 22 Jan 2009 04:55:51 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LPwHq-00015E-8J for qemu-devel@nongnu.org; Thu, 22 Jan 2009 04:55:50 -0500 Received: from [199.232.76.173] (port=47023 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LPwHq-00014p-3U for qemu-devel@nongnu.org; Thu, 22 Jan 2009 04:55:46 -0500 Received: from ns.suse.de ([195.135.220.2]:47711 helo=mx1.suse.de) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1LPwHp-00058Y-GC for qemu-devel@nongnu.org; Thu, 22 Jan 2009 04:55:45 -0500 Received: from Relay1.suse.de (mail2.suse.de [195.135.221.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.suse.de (Postfix) with ESMTP id 4333D43B5B for ; Thu, 22 Jan 2009 10:55:41 +0100 (CET) Message-ID: <4978440C.5040301@suse.de> Date: Thu, 22 Jan 2009 11:01:48 +0100 From: Kevin Wolf MIME-Version: 1.0 Subject: Re: [Qemu-devel] Combining "loadvm" and "-snapshot" References: <18806.25890.35889.274762@amuro.CS.Berkeley.EDU> <4976E704.7020607@suse.de> <18807.36599.764676.138289@amuro.CS.Berkeley.EDU> In-Reply-To: <18807.36599.764676.138289@amuro.CS.Berkeley.EDU> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Stephen McCamant schrieb: >>>>>> "KW" == Kevin Wolf writes: > > KW> Stephen McCamant schrieb: > > SMcC> I've tried implementing an alternate approach that makes > SMcC> "loadvm" work under "-snapshot" by finding and loading the VM > SMcC> state from the backing image, if a snapshot with that name isn't > SMcC> found in the scratch image. In some preliminary testing, this > SMcC> seems to do what I want; you can also make new snapshots with > SMcC> savevm that live only in the scratch image (and so go away at > SMcC> the end of the session). > > KW> I think, this is the point where your approach will break. A > KW> snapshot in the scratch image is still based on a snapshot in the > KW> backing image. So on loading the scratch snapshot you would also > KW> need to load the snapshot for the backing file. However, you don't > KW> know which one because qcow2 can't save a snapshot name for the > KW> backing file. > > Ah yes, I think I understand the problem you're referring to. For > instance, if you have two states snap1 and snap2 in the backing image, > and then you save a snapshot "snap1a" in the scratch image based on > snap1, then load snap2, then try to load snap1a, the disk will have an > inconsistent state that's a mixture of snap2 and the differences > between snap1 and snap1a. By playing around with file and directory > contents in snapshots (and unmounting and remounting to bypass the > buffer cache), I can make this show up as corrupted file contents. Right, this is the scenario I meant. > I think you could work around this problem by loading the appropriate > backing disk snapshot first, but the need for that isn't intuitive, so > I can see it easily tripping users up. (I presume you can get into > similar trouble if you modify a backing image that a persistent > scratch image is pointing to, though in that case it's clearer what > you're doing wrong.) We really should avoid to even make it possible to get in such states. It means that at least the scratch image will be horribly corrupted (which is even worse if you don't limit this scenario to -snapshot). I really don't want to imagine what happens when you commit to the backing file then... > As you suggest, the right fix would seem to be to have the scratch > disk snapshots remember what backing disk state they're based on, > though there's no field for that in the current QCOW2 format. It looks > like there is some space left for expansion at the end of the snapshot > structure, though that would be a bigger change. Or if you limit > yourself to the "-snapshot" case, and not persistent backed disk > images, it would be enough to keep the information in memory. Yes, that should work in any case. Only being able to use it with -snapshot is a major limitation, though. But you're right that there seems to be this extra_data_size field in the snapshot structure that I completely missed until now. I don't know if it's respected everywhere, but I think this could be worth a try. If it works this would be a really nice feature. Kevin