Re: [PATCH v2 00/13] migrate/ram: Fix resizing RAM blocks while migrating

[David Hildenbrand]

On 24.02.20 18:45, Peter Xu wrote:
> On Mon, Feb 24, 2020 at 10:09:19AM +0100, David Hildenbrand wrote:
>> On 21.02.20 19:04, Peter Xu wrote:
>>> On Fri, Feb 21, 2020 at 05:41:51PM +0100, David Hildenbrand wrote:
>>>> I was now able to actually test resizing while migrating. I am using the
>>>> prototype of virtio-mem to test (which also makes use of resizable
>>>> allocations). Things I was able to reproduce:
>>>
>>> The test cases cover quite a lot.  Thanks for doing that.
>>>
>>>> - Resize while still running on the migration source. Migration is canceled
>>>> -- Test case for "migraton/ram: Handle RAM block resizes during precopy"
>>>
>>>> - Resize (grow+shrink) on the migration target during postcopy migration
>>>>   (when syncing RAM blocks), while not yet running on the target
>>>> -- Test case for "migration/ram: Discard new RAM when growing RAM blocks
>>>>    and the VM is stopped", and overall RAM size synchronization. Seems to
>>>>    work just fine.
>>>
>>> This won't be able to trigger without virtio-mem, right?
>>
>> AFAIK all cases can also be triggered without virtio-mem (not just that
>> easily :) ). This case would be "RAM block is bigger on source than on
>> destination.".
>>
>>>
>>> And I'm also curious on how to test this even with virtio-mem.  Is
>>> that a QMP command to extend/shrink virtio-mem?
>>
>> Currently, there is a single qom property that can be modifed via
>> QMP/HMP - "requested-size". With resizable resizable memory backends,
>> increasing the requested size will also implicitly grow the RAM block.
>> Shrinking the requested size will currently result in shrinking the RAM
>> block on the next reboot.
>>
>> So, to trigger growing of a RAM block (assuming requested-size was
>> smaller before, e.g., 1000M)
>>
>> echo "qom-set vm1 requested-size 6000M" | sudo nc -U $MON
>>
>> To trigger shrinking (assuming requested-size was bigger before)
>>
>> echo "qom-set vm1 requested-size 100M" | sudo nc -U $MON
>> echo 'system_reset' | sudo nc -U $MON
>>
>>
>> Placing these at the right spots during a migration allows to test this
>> very reliably.
> 
> I see, thanks for the context.  The question was majorly about when
> you say "during postcopy migration (when syncing RAM blocks), while
> not yet running on the target" - it's not easy to do so imho, because:

This case is very easy to trigger, even with acpi. Simply have a ram
block on the source be bigger than one on the target. The sync code
(migration/ram.c:qemu_ram_resize()) will perform the resize during
precopy. Postcopy misses to discard the additional memory.

Maybe my description was confusing. But this really just triggers when

- Postcopy is advised and discards memory on all ram blocks
- Precopy grows the RAM block when syncing the RAM block sizes with the
source

Postcopy misses to discard the new RAM.

> 
>   - it's a very short transition period between precopy and postcopy,
>     so I was curious about how you made sure that the grow/shrink
>     happened exactly during that period
> 
>   - during the period, IIUC it was still in the main thread, which
>     means logically QEMU should not be able to respond to any QMP/HMP
>     command at all...  So even if you send a command, I think it'll
>     only be executed later after the transition completes
> 
>   - this I'm not sure, but ... even for virtio-mem, the resizing can
>     only happen after guest ack it, right?  During the precopy to
>     postcopy transition period, the VM is stopped, AFAICT, so
>     logically we can't trigger resizing during the transition
> 
> So it's really a question/matter of whether we still even need to
> consider that transition period for resizing event for postcopy.
> Maybe we don't even need to.

It's synchronous and not a race. So it does matter very much :)

-- 
Thanks,

David / dhildenb