From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1LAskU-0006SX-CN
	for qemu-devel@nongnu.org; Thu, 11 Dec 2008 16:07:06 -0500
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1LAskR-0006Qj-R4
	for qemu-devel@nongnu.org; Thu, 11 Dec 2008 16:07:06 -0500
Received: from [199.232.76.173] (port=33334 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1LAskR-0006Qd-Id
	for qemu-devel@nongnu.org; Thu, 11 Dec 2008 16:07:03 -0500
Received: from mail-qy0-f20.google.com ([209.85.221.20]:49218)
	by monty-python.gnu.org with esmtp (Exim 4.60)
	(envelope-from <anthony@codemonkey.ws>) id 1LAskQ-0007ei-Oh
	for qemu-devel@nongnu.org; Thu, 11 Dec 2008 16:07:03 -0500
Received: by qyk13 with SMTP id 13so1718937qyk.10
	for <qemu-devel@nongnu.org>; Thu, 11 Dec 2008 13:07:01 -0800 (PST)
Message-ID: <494180F2.1010904@codemonkey.ws>
Date: Thu, 11 Dec 2008 15:06:58 -0600
From: Anthony Liguori <anthony@codemonkey.ws>
MIME-Version: 1.0
Subject: Re: [Qemu-devel] [PATCH] Fix handling of disk-only snapshots
References: <493D3678.1040406@suse.de>
In-Reply-To: <493D3678.1040406@suse.de>
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit
Reply-To: qemu-devel@nongnu.org
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/pipermail/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: qemu-devel@nongnu.org

Kevin Wolf wrote:
> When creating a snapshot with multiple qcow2 disks attached, the current
> behaviour is that qemu creates a disk snapshot on all of them and
> chooses one to write the VM state to.
>
> Despite having the state only in one image, loadvm tries to restore the
> VM state from the middle of nowhere if you run qemu a second time with
> only one of the other images attached. In the lucky case it will fail
> because there simply is no state, but it also can happen that it loads
> the state of a different snapshot (the one this new one is based upon).
>
> The fix is to write a zero VM state size to the images which don't
> contain the state, and check this in loadvm.
>
> I agree that you probably have to provoke such things intentionally to
> get in a state like this with qemu itself. However, with my second patch
> that adds snapshot support to qemu-img it could become a reasonable use
> case to have snapshots with and without VM states on the same image.
>
> Signed-off-by: Kevin Wolf <kwolf@suse.de>
>   

Applied.  Thanks.

Regards,

Anthony Liguori