From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from [140.186.70.92] (port=38558 helo=eggs.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1OvS7K-0004UH-T0
	for qemu-devel@nongnu.org; Tue, 14 Sep 2010 05:47:59 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69)
	(envelope-from <avi@redhat.com>) id 1OvS7J-0005wG-P3
	for qemu-devel@nongnu.org; Tue, 14 Sep 2010 05:47:58 -0400
Received: from mx1.redhat.com ([209.132.183.28]:23336)
	by eggs.gnu.org with esmtp (Exim 4.69)
	(envelope-from <avi@redhat.com>) id 1OvS7J-0005w7-HM
	for qemu-devel@nongnu.org; Tue, 14 Sep 2010 05:47:57 -0400
Message-ID: <4C8F44C5.6090908@redhat.com>
Date: Tue, 14 Sep 2010 11:47:49 +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>
In-Reply-To: <4C8E367B.8070609@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/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
2) dst> open
3) dst> start guest

There are two failure scenarios with this model:

1. dst cannot open the image

We fix that by killing dst and continuing src (which has to re-open its 
images).

2. dst cannot open the image, and src cannot as well

In this case, what would be gained by having an image handle open in one 
of the hosts, but no way to open it again?  As soon as the surviving 
qemu exited (or crashed), the image would be lost for ever.

To get (1) working correctly we need an event that tells management that 
all initialization has completed and the guest is ready to run (so 
management can terminate the source).

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