From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:33761) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ROnpj-0004Gf-Pa for qemu-devel@nongnu.org; Fri, 11 Nov 2011 04:55:44 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ROnpe-0004Ku-FX for qemu-devel@nongnu.org; Fri, 11 Nov 2011 04:55:39 -0500 Received: from mx1.redhat.com ([209.132.183.28]:51165) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ROnpd-0004Kp-OZ for qemu-devel@nongnu.org; Fri, 11 Nov 2011 04:55:34 -0500 Date: Fri, 11 Nov 2011 09:55:24 +0000 From: "Daniel P. Berrange" Message-ID: <20111111095524.GB8472@redhat.com> References: <4EBC683C.7090700@codemonkey.ws> <4EBCED0C.80601@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <4EBCED0C.80601@redhat.com> Subject: Re: [Qemu-devel] Storage requirements for live migration Reply-To: "Daniel P. Berrange" List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Kevin Wolf Cc: Stefan Hajnoczi , Juan Quintela , qemu-devel , Avi Kivity , Christoph Hellwig On Fri, Nov 11, 2011 at 10:38:20AM +0100, 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. WRT libvirt, we have a concept of 'tainting' for guests. We set taint flags whenever the management application requests a config, or performs an action that we know to be potentially dangerous. These end up as log messages in the per-guest logfile, so when users report bugs we can see from the log that something "bad" has been done to the guest. At the very least, it sounds like we should make libvirt mark guests as tainted, if they have been migrated with cache != none, so this is easily identifiable by BZ support people. We might also want to make a libvirt host level config option to allow host admins forbid migration without cache=none. Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|