[libvirt] [RFC/Experimental]: Tunnelled migration
Chris Lalancette
clalance at redhat.com
Tue Jul 28 07:04:39 UTC 2009
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
More information about the libvir-list
mailing list