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

[Daniel P. Berrange]

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