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

["Michael S. Tsirkin" <mst@redhat.com>]

On Mon, Nov 14, 2011 at 10:16:10AM +0000, Daniel P. Berrange wrote:
> On Sat, Nov 12, 2011 at 12:25:34PM +0200, Avi Kivity wrote:
> > On 11/11/2011 12:15 PM, Kevin Wolf wrote:
> > > Am 10.11.2011 22:30, schrieb Anthony Liguori:
> > > > Live migration with qcow2 or any other image format is just not going to work 
> > > > right now even with proper clustered storage.  I think doing a block level flush 
> > > > cache interface and letting block devices decide how to do it is the best approach.
> > >
> > > I would really prefer reusing the existing open/close code. It means
> > > less (duplicated) code, is existing code that is well tested and doesn't
> > > make migration much of a special case.
> > >
> > > If you want to avoid reopening the file on the OS level, we can reopen
> > > only the topmost layer (i.e. the format, but not the protocol) for now
> > > and in 1.1 we can use bdrv_reopen().
> > >
> > 
> > Intuitively I dislike _reopen style interfaces.  If the second open
> > yields different results from the first, does it invalidate any
> > computations in between?
> > 
> > What's wrong with just delaying the open?
> 
> If you delay the 'open' until the mgmt app issues 'cont', then you loose
> the ability to rollback to the source host upon open failure for most
> deployed versions of libvirt. We only fairly recently switched to a five
> stage migration handshake to cope with rollback when 'cont' fails.
> 
> Daniel

I guess reopen can fail as well, so this seems to me to be an important
fix but not a blocker.

> -- 
> |: 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 :|