qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH 1/2] Reopen files after migration


From: Kevin Wolf
Subject: Re: [Qemu-devel] [PATCH 1/2] Reopen files after migration
Date: Thu, 10 Nov 2011 12:30:55 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:7.0) Gecko/20110927 Thunderbird/7.0

Am 09.11.2011 22:16, schrieb Anthony Liguori:
> On 11/09/2011 03:10 PM, Juan Quintela wrote:
>> Anthony Liguori<address@hidden>  wrote:
>>> On 11/09/2011 01:16 PM, Juan Quintela wrote:
>>>> We need to invalidate the Read Cache on the destination, otherwise we
>>>> have corruption.  Easy way to reproduce it is:
>>>>
>>>> - create an qcow2 images
>>>> - start qemu on destination of migration (qemu .... -incoming tcp:...)
>>>> - start qemu on source of migration and do one install.
>>>> - migrate at the end of install (when lot of disk IO has happened).
>>>>
>>>> Destination of migration has a local copy of the L1/L2 tables that existed
>>>> at the beginning, before the install started.  We have disk corruption at
>>>> this point.  The solution (for NFS) is to just re-open the file.  
>>>> Operations
>>>> have to happen in this order:
>>>>
>>>> - source of migration: flush()
>>>> - destination: close(file);
>>>> - destination: open(file)
>>>>
>>>> it is not necesary that source of migration close the file.
>>>>
>>>> Signed-off-by: Juan Quintela<address@hidden>
>>>
>>> Couple thoughts:
>>>
>>> 1) Pretty sure this would break -snapshot.  I do test migration with
>>> -snapshot so please don't break it.
>>
>> Can you give me one example?  I don't know how to use -snapshot with 
>> migration.
> 
> This is totally unsafe but has always worked for me.  On the same box:
> 
> $ qemu -hda foo.img -snapshot
> 
> $ qemu -hda foo.img -snapshot -incoming tcp:localhost:1025

It's always amazing to see how people depend on insane things like this. :-)

> This is not the *only* way I test migration but it's very convenient for 
> sniff 
> testing.  The problem with your patch is that it assumes that once you've 
> opened 
> a file, the name still exists.  But that is not universally true.  It needs 
> to 
> degrade in a useful way.
> 
> I think just deferring open is probably the best strategy.

One of the problems with deferring open was that we want to detect
simple errors (typo in the file name, or whatever) before doing the real
live migration. The proposed solution was a read-only open/close
sequence at the start, but I believe this would break your use of
-snapshot as well.

Kevin



reply via email to

[Prev in Thread] Current Thread [Next in Thread]