[libvirt] [RFC/Experimental]: Tunnelled migration

[Chris Lalancette]

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