Am 09.11.2011 22:01, schrieb Anthony Liguori: > On 11/09/2011 03:00 PM, Michael S. Tsirkin wrote: >> On Wed, Nov 09, 2011 at 02:22:02PM -0600, Anthony Liguori wrote: >>> On 11/09/2011 02:18 PM, Michael S. Tsirkin wrote: >>>> On Wed, Nov 09, 2011 at 11:35:54AM -0600, Anthony Liguori wrote: >>>>> On 11/09/2011 11:02 AM, Avi Kivity wrote: >>>>>> On 11/09/2011 06:39 PM, Anthony Liguori wrote: >>>>>>> >>>>>>> Migration with qcow2 is not a supported feature for 1.0. Migration is >>>>>>> only supported with raw images using coherent shared storage[1]. >>>>>>> >>>>>>> [1] NFS is only coherent with close-to-open which right now is not >>>>>>> good enough for migration. >>>>>> >>>>>> Say what? >>>>> >>>>> Due to block format probing, we read at least the first sector of >>>>> the disk during start up. >>>> >>>> A simple solution is not to do any probing before the VM is first >>>> started on the incoming path. >>>> >>>> Any issues with this? >>>> >>> >>> http://mid.gmane.org/1284213896-12705-4-git-send-email-aliguori@xxxxxxxxxx >>> I think Kevin wanted open to get delayed. >>> >>> Regards, >>> >>> Anthony Liguori >> >> So, this patchset just needs to be revived and polished up? > > What I took from the feedback was that Kevin wanted to defer open until the > device model started. That eliminates the need to reopen or have a invalidation > callback. > > I think it would be good for Kevin to comment here though because I might have > misunderstood his feedback. Your approach was to delay reads, but still keep the image open. I think I worried that we might have additional reads somewhere that we don't know about, and this is why I proposed delaying the open as well, so that any read would always fail. I believe just reopening the image is (almost?) as good and it's way easier to do, so I would be inclined to do that for 1.0. I'm not 100% sure about cases like iscsi, where reopening doesn't help. I think delaying the open doesn't help there either if you migrate from A to B and then back from B to A, you could still get old data. So for iscsi probably cache=none remains the only safe choice, whatever we do. 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