qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH v7 22/42] migrate_start_postcopy: Command to tri


From: Dr. David Alan Gilbert
Subject: Re: [Qemu-devel] [PATCH v7 22/42] migrate_start_postcopy: Command to trigger transition to postcopy
Date: Thu, 24 Sep 2015 15:20:11 +0100
User-agent: Mutt/1.5.24 (2015-08-30)

* Juan Quintela (address@hidden) wrote:
> "Dr. David Alan Gilbert" <address@hidden> wrote:
> > * Juan Quintela (address@hidden) wrote:
> >> "Dr. David Alan Gilbert (git)" <address@hidden> wrote:
> >> > From: "Dr. David Alan Gilbert" <address@hidden>
> >> >
> >> > Once postcopy is enabled (with migrate_set_capability), the migration
> >> > will still start on precopy mode.  To cause a transition into postcopy
> >> > the:
> >> >
> >> >   migrate_start_postcopy
> >> >
> >> > command must be issued.  Postcopy will start sometime after this
> >> > (when it's next checked in the migration loop).
> >> >
> >> > Issuing the command before migration has started will error,
> >> > and issuing after it has finished is ignored.
> >> >
> >> > Signed-off-by: Dr. David Alan Gilbert <address@hidden>
> >> > Reviewed-by: Eric Blake <address@hidden>
> >> 
> >> > diff --git a/include/migration/migration.h 
> >> > b/include/migration/migration.h
> >> > index a5951ac..e973490 100644
> >> > --- a/include/migration/migration.h
> >> > +++ b/include/migration/migration.h
> >> > @@ -111,6 +111,9 @@ struct MigrationState
> >> >      int64_t xbzrle_cache_size;
> >> >      int64_t setup_time;
> >> >      int64_t dirty_sync_count;
> >> > +
> >> > +    /* Flag set once the migration has been asked to enter postcopy */
> >> > +    bool start_postcopy;
> >> >  };
> >> >  
> >> >  void process_incoming_migration(QEMUFile *f);
> >> > diff --git a/migration/migration.c b/migration/migration.c
> >> > index e77b8b4..6fc47f9 100644
> >> > --- a/migration/migration.c
> >> > +++ b/migration/migration.c
> >> > @@ -465,6 +465,28 @@ void qmp_migrate_set_parameters(bool 
> >> > has_compress_level,
> >> >      }
> >> >  }
> >> >  
> >> > +void qmp_migrate_start_postcopy(Error **errp)
> >> > +{
> >> > +    MigrationState *s = migrate_get_current();
> >> > +
> >> > +    if (!migrate_postcopy_ram()) {
> >> > +        error_setg(errp, "Enable postcopy with migration_set_capability 
> >> > before"
> >> > +                         " the start of migration");
> >> > +        return;
> >> > +    }
> >> > +
> >> > +    if (s->state == MIGRATION_STATUS_NONE) {
> >> 
> >> I would claim that this check should be:
> >> 
> >>     if (s->state != MIGRATION_STATUS_ACTIVE) {
> >> ??
> >> 
> >> FAILED, COMPLETED, CANCELL* don't make sense, right?
> >
> > What I'm trying to catch here is people doing:
> >      migrate_start_postcopy
> >      migrate tcp:pppp:whereever
> >
> >   which wont work, because migrate_init reinitialises
> > the flag that start previously set.
> >
> > However, I also don't want to create a race, since what you do is
> > typically:
> >      migrate  tcp:pppp:whereever
> >    <wait some time, get bored>
> >      migrate_start_postcopy
> >
> > if you're unlucky, and the migration finishes just
> > at the same time you do the migrate_start_postcopy, do you
> > want migrate_start_postcopy to fail?  My guess was it
> > was best for it not to fail, in this case.
> 
> Change the order, if it is ACTIVE: do the postcopy thing, otherwise, do
> the clause that is protected now?  Moving to postcopy only make sense if
> we are in active.

The problem is that produces a race-condition for the command.
If you wait too long and the migration finishes before you issue the command
you get an error, when the migration has completed perfectly happily.

Dave

> 
> Later, Juan.
> 
> 
> >
> > Dave
> >
> >> 
> >> Thanks, Juan.
> > --
> > Dr. David Alan Gilbert / address@hidden / Manchester, UK
--
Dr. David Alan Gilbert / address@hidden / Manchester, UK



reply via email to

[Prev in Thread] Current Thread [Next in Thread]