qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: "Daniel P. Berrange" <berrange@redhat.com>
To: Kevin Wolf <kwolf@redhat.com>
Cc: Stefan Hajnoczi <stefanha@linux.vnet.ibm.com>,
	Juan Quintela <quintela@redhat.com>,
	qemu-devel <qemu-devel@nongnu.org>, Avi Kivity <avi@redhat.com>,
	Christoph Hellwig <hch@lst.de>
Subject: Re: [Qemu-devel] Storage requirements for live migration
Date: Fri, 11 Nov 2011 09:55:24 +0000	[thread overview]
Message-ID: <20111111095524.GB8472@redhat.com> (raw)
In-Reply-To: <4EBCED0C.80601@redhat.com>

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	other threads:[~2011-11-11  9:55 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-11-11  0:11 [Qemu-devel] Storage requirements for live migration Anthony Liguori
2011-11-11  6:27 ` Mark Wu
2011-11-11  9:15   ` Kevin Wolf
2011-11-11  9:38 ` Kevin Wolf
2011-11-11  9:55   ` Daniel P. Berrange [this message]
2011-11-11 10:01     ` Kevin Wolf
2011-11-11 14:08     ` Anthony Liguori
2011-11-11 14:05   ` Anthony Liguori
2011-11-11 22:43 ` Ryan Harper
2011-11-11 23:23   ` Anthony Liguori

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20111111095524.GB8472@redhat.com \
    --to=berrange@redhat.com \
    --cc=avi@redhat.com \
    --cc=hch@lst.de \
    --cc=kwolf@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=quintela@redhat.com \
    --cc=stefanha@linux.vnet.ibm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).