From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from [140.186.70.92] (port=37243 helo=eggs.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1Punh6-0008UJ-8E
	for qemu-devel@nongnu.org; Wed, 02 Mar 2011 10:10:29 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <anthony@codemonkey.ws>) id 1Punh5-0006ZV-1j
	for qemu-devel@nongnu.org; Wed, 02 Mar 2011 10:10:28 -0500
Received: from mail-vx0-f173.google.com ([209.85.220.173]:52876)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <anthony@codemonkey.ws>) id 1Punh4-0006ZI-VL
	for qemu-devel@nongnu.org; Wed, 02 Mar 2011 10:10:27 -0500
Received: by vxb41 with SMTP id 41so29551vxb.4
	for <qemu-devel@nongnu.org>; Wed, 02 Mar 2011 07:10:26 -0800 (PST)
Message-ID: <4D6E5D49.4080101@codemonkey.ws>
Date: Wed, 02 Mar 2011 10:07:53 -0500
From: Anthony Liguori <anthony@codemonkey.ws>
MIME-Version: 1.0
Subject: Re: [Qemu-devel] Re: [patch 2/3] Add support for live block copy
References: <20110222170004.808373778@redhat.com>	<4D64266A.3060106@codemonkey.ws>	<20110222230935.GA11082@amt.cnet>	<4D644343.4050800@codemonkey.ws>	<4D65051A.6070707@redhat.com>	<4D651B20.70405@codemonkey.ws>	<4D652852.60505@redhat.com>	<4D652F73.3000305@codemonkey.ws>	<4D65324A.5080408@redhat.com>	<4D65359E.3040008@codemonkey.ws>	<4D65416D.8040803@redhat.com>	<4D656B97.5030301@codemonkey.ws>	<4D661CB8.6010305@redhat.com>	<4D667287.9010005@codemonkey.ws>	<4D6677BE.2030009@redhat.com>	<4D669C46.40909@codemonkey.ws>	<4D6A150B.8030205@redhat.com>	<4D6A58E0.9020607@codemonkey.ws>	<4D6A6E38.4030700@redhat.com>	<4D6A8CC9.4090304@codemonkey.ws>	<4D6B5EFA.8060106@redhat.com>	<4D6B98FD.7020103@codemonkey.ws>	<4D6BA16A.2020204@redhat.com>	<AANLkTinROrJiTQKVCTWX2s+tAgOO9scoXrvT_96uSuyA@mail.gmail.com>	<4D6BDFA1.3000100@redhat.com>	<AANLkTi=GmhnJ3Vz2MemDuVu59EyZ3NJS72bf3yN0kMQY@mail.gmail.com>	<4D6CB556.5060401@redhat.c!
	om> <4D6E3A65.7090502@codemonke! y.ws>
	<4D6E3F57.8050804@redhat.com>
In-Reply-To: <4D6E3F57.8050804@redhat.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
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: Avi Kivity <avi@redhat.com>
Cc: Jes.Sorensen@redhat.com, dlaor@redhat.com, qemu-devel@nongnu.org, Marcelo Tosatti <mtosatti@redhat.com>

On 03/02/2011 08:00 AM, Avi Kivity wrote:
> On 03/02/2011 02:39 PM, Anthony Liguori wrote:
>>
>> Here is where your race is:
>>
>> 2. Management sends a switch command
>>
>> 3. QEMU receives switch command
>>
>> 4. QEMU stops doubling IO and switches to the destination
>>
>> 5. QEMU sends acknowledgement of switch command
>>
>> 6. Management receives acknowledge of switch command
>>
>> 7. Management changes internal state definition to reflect the new 
>> destination
>>
>> If QEMU or the management tool crashes after step 4 and before step 
>> 6, when the management tool restarts QEMU with the source image, data 
>> loss will have occurred (and potentially corruption if a flush had 
>> happened).
>
> No.  After step 2, any qemu restart will be with the destination 
> image.  If the management tool restarts, it can query the state (or 
> just re-issue the switch command, which is idempotent).

Yeah, I think you're right, although I need to think through it a bit more.

Regards,

Anthony Liguori