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