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

[David Hildenbrand]

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.

-- 
Thanks,

David / dhildenb