From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:53456) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ROrk9-0002Tr-7j for qemu-devel@nongnu.org; Fri, 11 Nov 2011 09:06:10 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ROrk3-00036c-JO for qemu-devel@nongnu.org; Fri, 11 Nov 2011 09:06:09 -0500 Received: from mail-yx0-f173.google.com ([209.85.213.173]:40301) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ROrk3-00036X-Gw for qemu-devel@nongnu.org; Fri, 11 Nov 2011 09:06:03 -0500 Received: by yenr8 with SMTP id r8so3646623yen.4 for ; Fri, 11 Nov 2011 06:06:02 -0800 (PST) Message-ID: <4EBD2BC7.8080407@codemonkey.ws> Date: Fri, 11 Nov 2011 08:05:59 -0600 From: Anthony Liguori MIME-Version: 1.0 References: <4EBC683C.7090700@codemonkey.ws> <4EBCED0C.80601@redhat.com> In-Reply-To: <4EBCED0C.80601@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] Storage requirements for live migration List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Kevin Wolf Cc: qemu-devel , Avi Kivity , Christoph Hellwig , Stefan Hajnoczi , Juan Quintela On 11/11/2011 03:38 AM, Kevin Wolf wrote: > Am 11.11.2011 01:11, schrieb Anthony Liguori: >> I did a brain dump of my understanding of the various storage requirements for >> live migration. I think it's accurate but I may have misunderstand some details >> so I would appreciate review. >> >> I think given sections (1) and (2), the only viable thing is to require >> cache=none unless we get new interfaces to flush caches. > > Yes, I think we should strongly recommend cache=none/directsync, but not > enforce it. As you said, for clustered filesystems other options should > work, so we should allow users to choose to make use of that. > >> Section (3) talks about image formats. As I mentioned elsewhere in the thread, >> I think the best we can do right now is have a block layer interface to quiesce >> the image format. I think reopen may be a viable short term strategy for qcow2 >> but I think for raw, we should just make the quiesce operation a nop. > > I don't agree with making it a nop on raw. You say it's safe without any > further action if you avoid online resize, but we don't disallow online > resize during migration, so this is an invalid assumption. And did you > review all the code to make sure that we don't cache more? It's not just that. We cache information outside of the block layer (like the CHS). This means that reopening isn't even enough because that only drops the cached data in the block layer. The file size is also cached by devices. Regards, Anthony Liguori > > I believe it's better anyway to have all formats behave the same. > > Kevin >