On 11/11/2011 08:29 AM, Kevin Wolf wrote:
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.
This sounds like a good thing to work through in the next release.
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. :-(
This patch was posted a year ago. Feedback was provided and there was never any
follow up[1]. I've never Nack'd this approach. I can't see how I was blocking
this since I never even responded in the thread. If this came in before soft
freeze, I wouldn't have objected if you wanted to go in this direction.
This is not a bug fix, this is a new feature. We're long past feature freeze.
It's not a simple and obvious fix either. It only partially fixes the problem
and introduces other problems. It's not a good candidate for making an
exception at this stage in the release.
[1] http://mid.gmane.org/cover.1294150511.git.quintela@xxxxxxxxxx
Regards,
Anthony Liguori
Kevin
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
