On 10/9/2024 6:08 PM, Fabiano Rosas wrote:
Peter Xu <pet...@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).
