Am 11.11.2011 15:35, schrieb Anthony Liguori: > 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 Then please send a fix that fails migration with non-raw images. Not breaking images silently during migration is critical for 1.0, IMO. 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
