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