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

[Anthony Liguori]

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?

No, this is not going to block the release.

You can't dump patches on the ML during -rc for an issue that has been 
understood for well over a year simply because it's release time.

If this was so important, it should have been fixed a year ago in the proper 
way.

Regards,

Anthony Liguori

> If we have to delay the release for a month to get it right, we should.
> Not that I think we have to.