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]

 



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. :-(

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