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

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.