qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] Storage requirements for live migration


From: Daniel P. Berrange
Subject: Re: [Qemu-devel] Storage requirements for live migration
Date: Fri, 11 Nov 2011 09:55:24 +0000
User-agent: Mutt/1.5.21 (2010-09-15)

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 :|



reply via email to

[Prev in Thread] Current Thread [Next in Thread]