Re: [PATCH V2 13/13] migration: cpr-transfer mode

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

On 10/9/2024 6:08 PM, Fabiano Rosas wrote:
> Peter Xu <peterx@redhat.com> writes:
> 
>> On Wed, Oct 09, 2024 at 04:18:31PM -0400, Steven Sistare wrote:
>>> Yes, I am also brainstorming along these lines, looking for more gotcha's,
>>> but its a big design change. I don't love it so far.
>>>
>>> These issues all creep in because of transfer mode.  Exec mode did not have this
>>> problem, as cpr-state is written to an in-memory file.
>>
>> I understand.  Hopefully we're getting there very soon..
>>
>> I still have concern on having -global used in productions, and meanwhile
> 
> Agree, but for qtests it should be fine at least.
> 
>> it might still be challenging for handshake to work as early as cpr stage
>> even for later, because at least in my mind the handshake still happens in
>> the main migration channel (where it includes channel establishments etc,
>> which is not proper during cpr stage).
> 
> I don't think any form of handshake will be implemented in a
> month. Maybe it's best we keep that to the side for now.

Agreed, and a handshake in the main migration channel, which would be the
cleanest to implement, occurs too late. We should not rely on it to solve this
cpr problem.

I have a new proposal which I will send in a new thread.

- Steve

> (still, thinking about that virtio-net USO thread, an early handshake
> could be a good idea, so we could perhaps inform about device
> incompatibility, etc.)
> 
>>
>> I don't really know whether that'll work at last..
>>
>> So in my mind the previous two-steps proposal is so far the only one that
>> all seem to work, with no unpredictable side effects.
>>
>> Said that, maybe we can still think about simpler solutions in the
>> following days or see others opinions, we don't need to make a decision
>> today, so maybe there's still better way to go.
> 
> I thought of putting the caps on the configuration vmstate and using
> that to set them on the destination, but there's a bit of a chicken and
> egg problem because we need capabilities set as soon as
> qemu_start_incoming_migration(). Unless we sent those via the cpr
> channel. We could split migration_object_init() a bit so we can
> instantiate some parts of the migration state earlier (I'm not even sure
> what are the actual dependencies are).