Re: cpr-transfer with caveats

[Steven Sistare <steven.sistare@oracle.com>]

On 10/25/2024 11:54 AM, Daniel P. Berrangé wrote:
> On Fri, Oct 25, 2024 at 11:01:27AM -0400, Steven Sistare wrote:
>> Hi Peter, are you OK if we proceed with cpr-transfer as is, without the
>> precreate phase?  Here are the problems that motivated it:
>>
>> * migration test wants to enable migration events on the dest.
>>    fix: enable on dest qemu using -global.  only for the test.
>>
>> * migration test needs to fetch the dynamically assigned migration
>>      listen port number
>>    Fix: require unix domain socket for cpr-transfer, or a fixed port
>>    number. Document it.
>>
>> * migration test hangs connecting to the qtest socket.
>>    fix: in the qtest code, defer connection.
>>
>> Document that one cannot set migration caps or params on the dest
>> for cpr-transfer.
>>
>> Document that for -incoming defer, mgmt must send the migrate command
>> to the src first (so dest reads cpr state and progresses to start the
>> monitor), then send the hotplug monitor commands to the dest.
>>
>> Daniel, are you OK with that last bit?
> 
> I guess it depends on what happens inside QEMU between reading the
> cpr state and libvirt being able to access the monitor. Libvirt does
> various things with the monitor during QEMU startup, before guest
> vCPUs start. Mostly this is around host resource placement/mgmt
> that needs to be done before the guest CPUs start.

When the monitor starts, there will be no difference in observable VM state.
The only difference is how you get there -- libvirt must issue the migrate
command up front, rather than issuing it after issuing migrate_incoming.

- Steve