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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 11/10/2011 04:41 AM, Kevin Wolf wrote:
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 don't think reopen is good enough without delaying CHS probing too. That information is still potentially out of date. I don't think you can fix this problem without delaying CHS probing at least.

Regards,

Anthony Liguori


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


[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux