From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from [140.186.70.92] (port=59271 helo=eggs.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1OvVMy-00053Q-Bh
	for qemu-devel@nongnu.org; Tue, 14 Sep 2010 09:16:22 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69)
	(envelope-from <avi@redhat.com>) id 1OvVMx-0008So-8I
	for qemu-devel@nongnu.org; Tue, 14 Sep 2010 09:16:20 -0400
Received: from mx1.redhat.com ([209.132.183.28]:50776)
	by eggs.gnu.org with esmtp (Exim 4.69)
	(envelope-from <avi@redhat.com>) id 1OvVMw-0008Se-VS
	for qemu-devel@nongnu.org; Tue, 14 Sep 2010 09:16:19 -0400
Message-ID: <4C8F759B.7030805@redhat.com>
Date: Tue, 14 Sep 2010 15:16:11 +0200
From: Avi Kivity <avi@redhat.com>
MIME-Version: 1.0
Subject: Re: [Qemu-devel] Re: [PATCH 3/3] disk: don't read from disk until
	the guest starts
References: <1284213896-12705-1-git-send-email-aliguori@us.ibm.com>	<1284213896-12705-4-git-send-email-aliguori@us.ibm.com>	<4C8DE19B.9090309@redhat.com>	<4C8E2747.9090806@linux.vnet.ibm.com>	<4C8E2981.7000304@redhat.com>	<4C8E2A52.1000708@linux.vnet.ibm.com>
	<4C8E319A.4090103@redhat.com> <4C8E367B.8070609@codemonkey.ws>
	<4C8F44C5.6090908@redhat.com> <4C8F6FB6.1000503@codemonkey.ws>
In-Reply-To: <4C8F6FB6.1000503@codemonkey.ws>
Content-Type: text/plain; charset=ISO-8859-15; 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: Anthony Liguori <anthony@codemonkey.ws>
Cc: Kevin Wolf <kwolf@redhat.com>, Juan Quintela <quintela@redhat.com>, qemu-devel@nongnu.org, Stefan Hajnoczi <stefanha@linux.vnet.ibm.com>

  On 09/14/2010 02:51 PM, Anthony Liguori wrote:
> On 09/14/2010 04:47 AM, Avi Kivity wrote:
>>  On 09/13/2010 04:34 PM, Anthony Liguori wrote:
>>> On 09/13/2010 09:13 AM, Kevin Wolf wrote:
>>>>> I think the only real advantage is that we fix NFS migration, right?
>>>> That's the one that we know about, yes.
>>>>
>>>> The rest is not a specific scenario, but a strong feeling that 
>>>> having an
>>>> image opened twice at the same time feels dangerous.
>>>
>>> We've never really had clear semantics about live migration and 
>>> block driver's life cycles.  At a high level, for live migration to 
>>> work, we need the following sequence:
>>>
>>> 1) src> flush all pending writes to disk
>>> 2) <barrier>
>>> 3) dst> invalidate any cached data
>>> 4) dst> start guest
>>
>> That's pretty complicated, compared to
>>
>> 1) src> close
>
> 1.5) <barrier>
>
>> 2) dst> open
>> 3) dst> start guest
>
> You need to make sure the open happens *after* the close.
>
> You're just using close to flush all pending writes or open to 
> invalidate any cached data.


Right, that's simpler than teaching all block format drivers about 
invalidating any cached data, or using nfs locks to force the host to do 
the same.

It also complies with close-to-open consistency without relying on 
implementation details.


-- 
error compiling committee.c: too many arguments to function