From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from [140.186.70.92] (port=41028 helo=eggs.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1P8COt-0006L7-53
	for qemu-devel@nongnu.org; Tue, 19 Oct 2010 09:38:48 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <stefanha@gmail.com>) id 1P8COr-00076k-J9
	for qemu-devel@nongnu.org; Tue, 19 Oct 2010 09:38:47 -0400
Received: from mail-gw0-f45.google.com ([74.125.83.45]:61740)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <stefanha@gmail.com>) id 1P8COr-00076a-Ex
	for qemu-devel@nongnu.org; Tue, 19 Oct 2010 09:38:45 -0400
Received: by gwj16 with SMTP id 16so1257435gwj.4
	for <qemu-devel@nongnu.org>; Tue, 19 Oct 2010 06:38:44 -0700 (PDT)
MIME-Version: 1.0
In-Reply-To: <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> <4CBD9E2D.6030208@codemonkey.ws>
Date: Tue, 19 Oct 2010 14:38:34 +0100
Message-ID: <AANLkTikAeWo-HXSSSHHEOmKzVw=zuX8iamFPxOHvnRS3@mail.gmail.com>
Subject: Re: [Qemu-devel] Re: KVM call agenda for Oct 19
From: Stefan Hajnoczi <stefanha@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
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.nongnu.org/archive/html/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: Anthony Liguori <anthony@codemonkey.ws>
Cc: chrisw@redhat.com, kvm@vger.kernel.org, Juan Quintela <quintela@redhat.com>, dlaor@redhat.com, qemu-devel@nongnu.org, Chris Wright <chrisw@sous-sol.org>, Ayal Baron <abaron@redhat.com>, Avi Kivity <avi@redhat.com>, "Venkateswararao Jujjuri (JV)" <jvrao@linux.vnet.ibm.com>

On Tue, Oct 19, 2010 at 2:33 PM, Anthony Liguori <anthony@codemonkey.ws> wr=
ote:
> On 10/19/2010 08:27 AM, Avi Kivity wrote:
>>
>> =A0On 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 wor=
k.
>> =A0We should eventually be able to create a snapshot without stalling vc=
pus
>> (stalling I/O of course allowed).
>
> If we had another block-level command, like bdrv_aio_freeze(), that queue=
d
> all pending requests until the given callback completed, it would be very
> easy to do this entirely asynchronously. =A0For instance:
>
> bdrv_aio_freeze(create_snapshot)
>
> create_snapshot():
> =A0bdrv_aio_flush(done_flush)
>
> done_flush():
> =A0bdrv_open(...)
> =A0bdrv_close(...)
> =A0...
>
> Of course, closing a device while it's being frozen is probably a recipe =
for
> disaster but you get the idea :-)

bdrv_aio_freeze() or any mechanism to deal with pending requests in
the generic block code would be a good step for future "live" support
of other operations like truncate.

Stefan