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

[Anthony Liguori <anthony@codemonkey.ws>]

On 11/11/2011 04:15 AM, 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.

Just to be clear, reopen only addresses image format migration.  It does not 
address NFS migration since it doesn't guarantee close-to-open semantics.

The problem I have with the reopen patches are that they introduce regressions 
and change at semantics for a management tool.  If you look at the libvirt 
workflow with encrypted disks, it would break with the reopen patches.

>
> 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().

I don't view not supporting migration with image formats as a regression as it's 
never been a feature we've supported.  While there might be confusion about 
support around NFS, I think it's always been clear that image formats cannot be 
used.

Given that, I don't think this is a candidate for 1.0.

Regards,

Anthony Liguori


>
> Kevin
>