qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] qemu and qemu.git -> Migration + disk stress introduces


From: Anthony Liguori
Subject: Re: [Qemu-devel] qemu and qemu.git -> Migration + disk stress introduces qcow2 corruptions
Date: Thu, 10 Nov 2011 12:27:30 -0600
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.21) Gecko/20110831 Lightning/1.0b2 Thunderbird/3.1.13

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



reply via email to

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