Daniel P. Berrange wrote: > Ah, now I understand why you were having trouble with this. > > With this patch, the flow of control is logically > > > virDomainMigrate(src, dst, uri) > +- virDomainMigratePrepare(dst) > +- virDomainMigratePerform(src, uri) > | +- dst2 = virConnectOpen(uri) > | +- virDomainMigratePrepareTunnel(dst2) > | +- while (1) > | | +- virStreamSend(dst2, data) > | +- virConnectClose(uri) > +- virDomainMigrateFinish(dst) > > > If we remember the requirement from the libvirt-qpid guys, which is > to remove the need for an application to pass in the destination > handle, this scheme won't work because 'dst' will be NULL. > > To cope with that requirement we'd need the logical flow to be > > virDomainMigrate(src, NULL, uri) > +- virDomainMigratePerform(src, uri) > +- dst = virConnectOpen(uri) > +- virDomainMigratePrepare(dst) > +- virDomainMigratePrepareTunnel(dst) > +- while (1) > | +- virStreamSend(dst, data) > +- virDomainMigrateFinish(dst) > +- virConnectClose(uri) > > > At which point, having separate virDomainMigratePrepare vs > virDomainMigratePrepareTunnel is overkill & might as well > just have virDomainMigratePrepareTunnel, which does all > the virDomainMigratePrepare logic itself, avoiding the need > to pass a TCP port around in virDomainObjPtr. OK, now I think I see your logic, and it makes sense. I'll convert my code over to this sort of logic (which should be pretty easy), and then report back. -- Chris Lalancette -- Libvir-list mailing list Libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list