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