Re: [Qemu-devel] [PATCH 0/4] Add ignore-external migration capability

[Yury Kotov]

11.01.2019, 23:55, "Eduardo Habkost" <address@hidden>:
> On Fri, Jan 11, 2019 at 06:49:53PM +0300, Yury Kotov wrote:
>>  10.01.2019, 23:12, "Dr. David Alan Gilbert" <address@hidden>:
>>  > * Yury Kotov (address@hidden) wrote:
>>  >> Hi,
>>  >>
>>  >> The series adds migration capability which allows to skip 'external' RAM 
>> blocks
>>  >> during migration. External block is a RAMBlock which available from the 
>> outside
>>  >> of current QEMU process (e.g. file in /dev/shm). It's useful for fast 
>> local
>>  >> migration to update QEMU for the running guests.
>>  >
>>  > Hi Yury,
>>  > There have been a few similar patch series around from people wanting
>>  > to do similar things.
>>  > In particular Lai Jiangshan's 
>> https://lists.nongnu.org/archive/html/qemu-devel/2018-03/msg07511.html
>>  > and Cédric Le Goater wanted to skip regions for a different reason.
>>  >
>>  > We merged some of Cédric's code last year so that we now
>>  > have the qemu_ram_is_migratable() function - and we should be reusing
>>  > that to skip things rather than adding a new check that we have to add
>>  > everywhere.
>>  >
>>
>>  I didn't see the series, so I'll check it, thanks!
>>  But I saw qemu_ram_is_migratable() function and corresponding patch.
>>  It's very close to my needs, but it works a bit different IIUC:
>>  1. Not migratable blocks isn't validated (existence and size) during 
>> migration,
>>  2. "Migratable" state is determined during the block creation time.
>>     Such case isn't valid because of it:
>>     * Source has one migratable and one not migratable RAM blocks,
>>     * Target has the same (idstr) blocks, but both are not migratable.
>>     Thus, target will not expect pages for not migratable blocks.
>>
>>  > Also, ypu're skipping 'external' things, I think the other suggestion
>>  > was to skip 'shared' things (i.e. anything with share=0); skipping
>>  > share=on cases sounds easier to me.
>>
>>  I agree that introducing new term is a complication, but 'share' and 
>> 'external'
>>  terms have important differences (I'll describe it below).
>>
>>  Just to clarify:
>>  * 'share' means that other processes has an access to such memory,
>>  * 'external' means file backed memory.
>
> If you use file backed memory with share=off, writes are not
> propagated to the file (they are mapped with MAP_PRIVATE). Would
> you really want to skip file backed memory if it has share=off?
>

Yes, you're right. I was sure it would work, but share=on is also needed in
my case.

>>  There is another use case I wanted to support (I had to write about it in
>>  the cover letter, sorry..):
>>  1. Migrate source VM to file and kill source,
>>  2. Start target VM and migrate it from file.
>>  In such case source VM may have memory-backend-ram with share=off, it's ok.
>>
>>  Thus, in the new migration capability I want to migrate memory that meets
>>  three conditions:
>>  1. The source will not use the memory after migration ends,
>>  2. The source may exit before target starts (migrate to file),
>>  3. The target has an access to the memory.
>>
>>  I think 'external' fits them better than 'share'.
>
> In either case, defining "external" seems tricky. A memory
> region might be backed by a file on tmpfs or hugetlbfs that was
> deleted, which makes the file "internal" for practical purposes.
> QEMU has no way to tell if (3) is really true.
>
> --
> Eduardo

Agree. Perhaps the best is a separate flag, as suggested by Dave.

Regards,
Yury