From mboxrd@z Thu Jan  1 00:00:00 1970
From: Anthony Liguori <anthony@codemonkey.ws>
Subject: Re: [Qemu-devel] Re: KVM call agenda for Oct 19
Date: Tue, 19 Oct 2010 08:33:33 -0500
Message-ID: <4CBD9E2D.6030208@codemonkey.ws>
References: <m3ocar5wxn.fsf@trasno.mitica> <20101019021117.GI25455@sequoia.sous-sol.org> <4CBD93B8.9070002@redhat.com> <4CBD9B87.9010008@codemonkey.ws> <4CBD9CB3.5080609@redhat.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: dlaor@redhat.com, Chris Wright <chrisw@sous-sol.org>,
	Juan Quintela <quintela@redhat.com>, chrisw@redhat.com,
	"Venkateswararao Jujjuri (JV)" <jvrao@linux.vnet.ibm.com>,
	qemu-devel@nongnu.org, kvm@vger.kernel.org,
	Ayal Baron <abaron@redhat.com>
To: Avi Kivity <avi@redhat.com>
Return-path: <kvm-owner@vger.kernel.org>
Received: from mail-vw0-f46.google.com ([209.85.212.46]:58608 "EHLO
	mail-vw0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1758542Ab0JSNdh (ORCPT <rfc822;kvm@vger.kernel.org>);
	Tue, 19 Oct 2010 09:33:37 -0400
Received: by vws2 with SMTP id 2so1383635vws.19
        for <kvm@vger.kernel.org>; Tue, 19 Oct 2010 06:33:36 -0700 (PDT)
In-Reply-To: <4CBD9CB3.5080609@redhat.com>
Sender: kvm-owner@vger.kernel.org
List-ID: <kvm.vger.kernel.org>

On 10/19/2010 08:27 AM, Avi Kivity wrote:
>  On 10/19/2010 03:22 PM, Anthony Liguori wrote:
>>
>> I had assumed that this would involve:
>>
>> qemu -hda windows.img
>>
>> (qemu) snapshot ide0-disk0 snap0.img
>>
>> 1) create snap0.img internally by doing the equivalent of `qemu-img 
>> create -f qcow2 -b windows.img snap0.img'
>> 2) bdrv_flush('ide0-disk0')
>> 3) bdrv_open(snap0.img)
>> 4) bdrv_close(windows.img)
>> 5) rename('windows.img', 'windows.img.tmp')
>> 6) rename('snap0.img', 'windows.img')
>> 7) rename('windows.img.tmp', 'snap0.img')
>>
>
> Looks reasonable.
>
> Would be interesting to look at this as a use case for the threading 
> work.  We should eventually be able to create a snapshot without 
> stalling vcpus (stalling I/O of course allowed).

If we had another block-level command, like bdrv_aio_freeze(), that 
queued all pending requests until the given callback completed, it would 
be very easy to do this entirely asynchronously.  For instance:

bdrv_aio_freeze(create_snapshot)

create_snapshot():
   bdrv_aio_flush(done_flush)

done_flush():
   bdrv_open(...)
   bdrv_close(...)
   ...

Of course, closing a device while it's being frozen is probably a recipe 
for disaster but you get the idea :-)

Regards,

Anthony Liguori