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

[Fabiano Rosas <farosas@suse.de>]

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.

(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).