From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=58953 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Ov9J2-00005d-ES for qemu-devel@nongnu.org; Mon, 13 Sep 2010 09:42:49 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1Ov9J1-0004sO-7t for qemu-devel@nongnu.org; Mon, 13 Sep 2010 09:42:48 -0400 Received: from e32.co.us.ibm.com ([32.97.110.150]:59915) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Ov9J1-0004sA-1M for qemu-devel@nongnu.org; Mon, 13 Sep 2010 09:42:47 -0400 Received: from d03relay01.boulder.ibm.com (d03relay01.boulder.ibm.com [9.17.195.226]) by e32.co.us.ibm.com (8.14.4/8.13.1) with ESMTP id o8DDYDCt021764 for ; Mon, 13 Sep 2010 07:34:13 -0600 Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by d03relay01.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id o8DDgj2n121616 for ; Mon, 13 Sep 2010 07:42:45 -0600 Received: from d03av02.boulder.ibm.com (loopback [127.0.0.1]) by d03av02.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id o8DDgi9x020468 for ; Mon, 13 Sep 2010 07:42:45 -0600 Message-ID: <4C8E2A52.1000708@linux.vnet.ibm.com> Date: Mon, 13 Sep 2010 08:42:42 -0500 From: Anthony Liguori MIME-Version: 1.0 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> In-Reply-To: <4C8E2981.7000304@redhat.com> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] Re: [PATCH 3/3] disk: don't read from disk until the guest starts List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Kevin Wolf Cc: Anthony Liguori , Juan Quintela , qemu-devel@nongnu.org, Stefan Hajnoczi On 09/13/2010 08:39 AM, Kevin Wolf wrote: >> Yeah, one of the key design points of live migration is to minimize the >> number of failure scenarios where you lose a VM. If someone typed the >> wrong command line or shared storage hasn't been mounted yet and we >> delay failure until live migration is in the critical path, that would >> be terribly unfortunate. >> > We would catch most of them if we try to open the image when migration > starts and immediately close it again until migration is (almost) > completed, so that no other code can possibly use it before the source > has really closed it. > I think the only real advantage is that we fix NFS migration, right? But if we do invalidate_cache() as you suggested with a close/open of the qcow2 layer, and also acquire and release a lock in the file layer by propagating the invalidate_cache(), that should work robustly with NFS. I think that's a simpler change. Do you see additional advantages to delaying the open? Regards, anthony Liguori > Kevin >