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

[Kevin Wolf]

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/address@hidden

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