On Fri, Oct 11, 2019 at 06:11:33PM +0100, Dr. David Alan Gilbert wrote:
> * Jens Freimann (address@hidden) wrote:
> > This patch adds a new migration state called wait-unplug. It is entered
> > after the SETUP state and will transition into ACTIVE once all devices
> > were succesfully unplugged from the guest.
> >
> > So if a guest doesn't respond or takes long to honor the unplug request
> > the user will see the migration state 'wait-unplug'.
> >
> > In the migration thread we query failover devices if they're are still
> > pending the guest unplug. When all are unplugged the migration
> > continues. We give it a defined number of iterations including small
> > waiting periods before we proceed.
> >
> > Signed-off-by: Jens Freimann <address@hidden>
[..]
> > + while (i < FAILOVER_UNPLUG_RETRIES &&
> > + s->state == MIGRATION_STATUS_WAIT_UNPLUG) {
> > + i++;
> > + qemu_sem_timedwait(&s->wait_unplug_sem,
FAILOVER_GUEST_UNPLUG_WAIT);
> > + all_unplugged = qemu_savevm_state_guest_unplug_pending();
> > + if (all_unplugged) {
> > + break;
> > + }
> > + }
> > +
> > + if (all_unplugged) {
> > + migrate_set_state(&s->state, MIGRATION_STATUS_WAIT_UNPLUG,
> > + MIGRATION_STATUS_ACTIVE);
> > + } else {
> > + migrate_set_state(&s->state, MIGRATION_STATUS_WAIT_UNPLUG,
> > + MIGRATION_STATUS_CANCELLING);
> > + }
>
> I think you can get rid of both the timeout and the count and just make
> sure that migrate_cancel works at this point.
I see, I need to add the new state to migration_is_setup_or_active() or
a cancel won't work.