Am 11.11.2011 15:03, schrieb Anthony Liguori:
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.
Yes. But image formats are the only thing that is really completely
broken today. For NFS etc. we can tell users to use
cache=none/directsync and they will be good. There is no such option
that makes image formats safe.
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.
Yes, this is nasty. But on the other hand: Today migration is broken for
all qcow2 images, with the reopen it's only broken for encrypted ones.
Certainly an improvement, even though there's still a bug left.
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.
Nobody says it's a regression, but it's a bad bug and you're blocking a
solution for it for over a year now because the solution isn't perfect
enough in your eyes. :-(