Re: [PATCH 6/6] qemu: Use fd: protocol for migration

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

 



On Mon, Aug 15, 2011 at 18:04:07 +0800, Daniel Veillard wrote:
> On Mon, Aug 15, 2011 at 09:58:16AM +0200, Jiri Denemark wrote:
> > By opening a connection to remote qemu process ourselves and passing the
> > socket to qemu we get much better errors than just "migration failed"
> > when the connection is opened by qemu.
> > ---
> >  src/qemu/qemu_migration.c |  128 ++++++++++++++++++++++++++++++++++-----------
> >  1 files changed, 98 insertions(+), 30 deletions(-)
> > 
> > diff --git a/src/qemu/qemu_migration.c b/src/qemu/qemu_migration.c
> > index c29ea9e..537e57e 100644
> > --- a/src/qemu/qemu_migration.c
> > +++ b/src/qemu/qemu_migration.c
> > @@ -1269,6 +1269,7 @@ cleanup:
...
> >  enum qemuMigrationDestinationType {
> >      MIGRATION_DEST_HOST,
> >      MIGRATION_DEST_UNIX,
> > +    MIGRATION_DEST_FD,
> >  };
> >  
> >  enum qemuMigrationForwardType {
> > @@ -1287,9 +1288,14 @@ struct _qemuMigrationSpec {
> >          } host;
> >  
> >          struct {
> > -            const char *file;
> > +            char *file;
> >              int sock;
> >          } unics; /* this sucks but "unix" is a macro defined to 1 */
> > +
> > +        struct {
> > +            int qemu;
> > +            int local;
> > +        } fd;
> >      } dest;
> >  
> >      enum qemuMigrationForwardType fwdType;
> > @@ -1472,6 +1478,14 @@ qemuMigrationRun(struct qemud_driver *driver,
> >              ret = qemuMonitorMigrateToCommand(priv->mon, migrate_flags, args);
> >          }
> >          break;
> > +
> > +    case MIGRATION_DEST_FD:
> > +        if (spec->fwdType != MIGRATION_FWD_DIRECT)
> > +            fd = spec->dest.fd.local;
> > +        ret = qemuMonitorMigrateToFd(priv->mon, migrate_flags,
> > +                                     spec->dest.fd.qemu);
> > +        VIR_FORCE_CLOSE(spec->dest.fd.qemu);
> 
>   Hum, I find dubious that we set up fd variable before
> calling qemuMonitorMigrateToFd but don't use that variable, smells fishy
> but I could be wrong since I don't get the full function context, so
> to double check.

The fd variable contains local end of a pipe or socket, that is it's the file
descriptor we will later read migration data from and forward through
virStream.

>   Okay, I guess the best is to apply and run the verious test suites on
> it ! Out of curiosity did you ran dan's migration suite with those
> patches ?

Unfortunately, I still don't have the setup for doing that. However, I did
test all kinds (normal, p2p, tunneled) of migration after the refactoring
patch, after switching unix socket creation to virNetSocket, and after this
patch and all tests (after fixing some bugs and hitting some other unrelated
bugs that will be fixed later) went fine.

Jirka

--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list


[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]