kvm.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Anthony Liguori <anthony@codemonkey.ws>
To: Avi Kivity <avi@redhat.com>
Cc: Lucas Meneghel Rodrigues <lmr@redhat.com>,
	Kevin Wolf <kwolf@redhat.com>,
	KVM mailing list <kvm@vger.kernel.org>,
	"Michael S. Tsirkin" <mst@redhat.com>,
	Marcelo Tosatti <mtosatti@redhat.com>,
	QEMU devel <qemu-devel@nongnu.org>,
	Juan Jose Quintela Carreira <quintela@redhat.com>,
	"Daniel P. Berrange" <berrange@redhat.com>,
	"libvir-list@redhat.com" <libvir-list@redhat.com>
Subject: Re: [Qemu-devel] qemu and qemu.git -> Migration + disk stress introduces qcow2 corruptions
Date: Thu, 10 Nov 2011 12:27:30 -0600	[thread overview]
Message-ID: <4EBC1792.3030004@codemonkey.ws> (raw)
In-Reply-To: <4EBB919B.7040605@redhat.com>

On 11/10/2011 02:55 AM, Avi Kivity wrote:
> On 11/09/2011 07:35 PM, Anthony Liguori wrote:
>> On 11/09/2011 11:02 AM, Avi Kivity wrote:
>>> On 11/09/2011 06:39 PM, Anthony Liguori wrote:
>>>>
>>>> Migration with qcow2 is not a supported feature for 1.0.  Migration is
>>>> only supported with raw images using coherent shared storage[1].
>>>>
>>>> [1] NFS is only coherent with close-to-open which right now is not
>>>> good enough for migration.
>>>
>>> Say what?
>>
>> Due to block format probing, we read at least the first sector of the
>> disk during start up.
>>
>> Strictly going by what NFS guarantees, since we don't open on the
>> destination *after* as close on the source, we aren't guaranteed to
>> see what's written by the source.
>>
>> In practice, because of block format probing, unless we're using
>> cache=none, the first sector can be out of sync with the source on the
>> destination.  If you use cache=none on a Linux client with at least a
>> Linux NFS server, you should be relatively safe.
>>
>
> IMO, this should be a release blocker.  qemu 1.0 only supporting
> migration on enterprise storage?
>
> If we have to delay the release for a month to get it right, we should.
> Not that I think we have to.
>

Adding libvirt to the discussion.

What does libvirt actually do in the monitor prior to migration completing on 
the destination?  The least invasive way of doing delayed open of block devices 
is probably to make -incoming create a monitor and run a main loop before the 
block devices (and full device model) is initialized.  Since this isolates the 
changes strictly to migration, I'd feel okay doing this for 1.0 (although it 
might need to be in the stable branch).

I know a monitor can run like this as I've done it before but some of the 
commands will not behave as expected so it's pretty important to be comfortable 
with what commands are actually being used in this mode.

Regards,

Anthony Liguori

  parent reply	other threads:[~2011-11-10 18:27 UTC|newest]

Thread overview: 59+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-11-09 16:29 qemu and qemu.git -> Migration + disk stress introduces qcow2 corruptions Lucas Meneghel Rodrigues
2011-11-09 16:39 ` Anthony Liguori
2011-11-09 17:02   ` [Qemu-devel] " Avi Kivity
2011-11-09 17:35     ` Anthony Liguori
2011-11-09 19:53       ` Juan Quintela
2011-11-09 20:18       ` Michael S. Tsirkin
2011-11-09 20:22         ` [Qemu-devel] " Anthony Liguori
2011-11-09 21:00           ` Michael S. Tsirkin
2011-11-09 21:01             ` Anthony Liguori
2011-11-10 10:41               ` [Qemu-devel] " Kevin Wolf
2011-11-10 16:50                 ` Juan Quintela
2011-11-10 17:59                   ` Anthony Liguori
2011-11-10 18:00                 ` [Qemu-devel] " Anthony Liguori
2011-11-09 20:57         ` Juan Quintela
2011-11-10  8:55       ` [Qemu-devel] " Avi Kivity
2011-11-10 17:50         ` Juan Quintela
2011-11-10 17:54         ` Anthony Liguori
2011-11-12 10:20           ` Avi Kivity
2011-11-12 13:30             ` Anthony Liguori
2011-11-12 14:36               ` Avi Kivity
2011-11-10 18:27         ` Anthony Liguori [this message]
2011-11-10 18:42           ` Daniel P. Berrange
2011-11-10 19:11             ` [Qemu-devel] " Anthony Liguori
2011-11-10 20:06               ` Daniel P. Berrange
2011-11-10 20:07                 ` Anthony Liguori
2011-11-10 21:30           ` Anthony Liguori
2011-11-11 10:15             ` Kevin Wolf
2011-11-11 14:03               ` [Qemu-devel] " Anthony Liguori
2011-11-11 14:29                 ` Kevin Wolf
2011-11-11 14:35                   ` Anthony Liguori
2011-11-11 14:44                     ` Kevin Wolf
2011-11-11 20:38                       ` Anthony Liguori
2011-11-12 10:27                 ` Avi Kivity
2011-11-12 13:39                   ` Anthony Liguori
2011-11-12 14:43                     ` Avi Kivity
2011-11-12 16:01                       ` Anthony Liguori
2011-11-12 10:25               ` Avi Kivity
2011-11-14  9:58                 ` Kevin Wolf
2011-11-14 10:10                   ` Michael S. Tsirkin
2011-11-15 13:28                   ` [Qemu-devel] " Avi Kivity
2011-11-14 10:16                 ` Daniel P. Berrange
2011-11-14 10:24                   ` Michael S. Tsirkin
2011-11-14 11:08                     ` Daniel P. Berrange
2011-11-14 11:21                       ` Kevin Wolf
2011-11-14 11:29                         ` [Qemu-devel] " Daniel P. Berrange
2011-11-14 11:34                           ` Michael S. Tsirkin
2011-11-14 11:37                             ` Daniel P. Berrange
2011-11-14 11:51                               ` Michael S. Tsirkin
2011-11-14 11:55                                 ` Daniel P. Berrange
2011-11-14 11:56                               ` Michael S. Tsirkin
2011-11-14 11:58                                 ` [Qemu-devel] " Daniel P. Berrange
2011-11-14 12:17                                   ` Michael S. Tsirkin
2011-11-14 11:36                           ` Gleb Natapov
2011-11-14 11:32                       ` Michael S. Tsirkin
2011-11-14 14:19                   ` Anthony Liguori
2011-11-15 13:20                     ` Juan Quintela
2011-11-15 13:56                       ` [Qemu-devel] " Anthony Liguori
2011-11-09 19:25 ` Juan Quintela
2011-11-09 23:33   ` Lucas Meneghel Rodrigues

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=4EBC1792.3030004@codemonkey.ws \
    --to=anthony@codemonkey.ws \
    --cc=avi@redhat.com \
    --cc=berrange@redhat.com \
    --cc=kvm@vger.kernel.org \
    --cc=kwolf@redhat.com \
    --cc=libvir-list@redhat.com \
    --cc=lmr@redhat.com \
    --cc=mst@redhat.com \
    --cc=mtosatti@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=quintela@redhat.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).