On Wed, Jan 03, 2018 at 09:38:52AM +0100, Juan Quintela wrote:
> Peter Xu <pet...@redhat.com> wrote:
> > When reaching here if we are still "active" it means we must be in colo
> > state. Assert it instead of check it in if condition.
>
> I don't think so.
>
> > Finally I want to use "switch" here rather than lots of complicated if
> > clauses.
> >
> > Signed-off-by: Peter Xu <pet...@redhat.com>
> > ---
> > migration/migration.c | 3 ++-
> > 1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/migration/migration.c b/migration/migration.c
> > index 4de3b551fe..0ee4b4c27c 100644
> > --- a/migration/migration.c
> > +++ b/migration/migration.c
> > @@ -2309,7 +2309,8 @@ static void *migration_thread(void *opaque)
> > }
> > runstate_set(RUN_STATE_POSTMIGRATE);
> > } else {
> > - if (s->state == MIGRATION_STATUS_ACTIVE && enable_colo) {
> > + if (s->state == MIGRATION_STATUS_ACTIVE) {
>
> We want to run this code iff:
> - we are in ACTIVE state
> - we are using colo
>
> We can be doing a normal migration, with colo compliled in, but not
> enabled, no?
If COLO is not enabled (even if it is compiled in), IMHO we won't
reach this state. Note that we have this in migration_completion():
if (!migrate_colo_enabled()) {
migrate_set_state(&s->state, current_active_state,
MIGRATION_STATUS_COMPLETED);
}
That's where we kept the ACTIVE state, and that should be the only
place. And, this is exactly what this patch is going to do - I want to
remove COLO hacks if possible.
Thanks,
--
Peter Xu
