All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kevin Wolf <kwolf@redhat.com>
To: Anthony Liguori <anthony@codemonkey.ws>
Cc: Juan Quintela <quintela@redhat.com>,
	Christoph Hellwig <hch@lst.de>,
	qemu-devel <qemu-devel@nongnu.org>,
	Stefan Hajnoczi <stefanha@linux.vnet.ibm.com>,
	Avi Kivity <avi@redhat.com>
Subject: Re: [Qemu-devel] Storage requirements for live migration
Date: Fri, 11 Nov 2011 10:38:20 +0100	[thread overview]
Message-ID: <4EBCED0C.80601@redhat.com> (raw)
In-Reply-To: <4EBC683C.7090700@codemonkey.ws>

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?

I believe it's better anyway to have all formats behave the same.

Kevin

  parent reply	other threads:[~2011-11-11  9:35 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 [this message]
2011-11-11  9:55   ` Daniel P. Berrange
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=4EBCED0C.80601@redhat.com \
    --to=kwolf@redhat.com \
    --cc=anthony@codemonkey.ws \
    --cc=avi@redhat.com \
    --cc=hch@lst.de \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.