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
