[Libvir] [PATCH 1/2] virDomainMigrate implementation (Xen only, no remote, no qemu, no virsh)

[Richard W.M. Jones]

Dan Smith wrote:
> RJ>  * Params is a linked list of hypervisor-specific parameters.  Each
> RJ>  * element is a virMigrateParamPtr containing the following fields:
> RJ>  *   name               Parameter name being set.
> RJ>  *   value              A union expressing the value.
> RJ>  *     value.strv         A string value.
> RJ>  *     value.longv        A long value.
> RJ>  *   next               Next in linked list (or NULL for end of list).
> 
> This should allow us to pass URIs to qemu, as well.  I like it :)

Can you give us some idea of how QEMU migration works?

KVM added a "migrate" function to the qemu console ("migrate <URI>"). 
For example: "migrate tcp://hostname:4444" and "migrate ssh://hostname". 
  I'm not sure if that is in qemu upstream, or whether qemu upstream is 
doing something else.

I think that we shouldn't pass URIs, but instead we should construct the 
URI from the hostname and port number, and something like an optional 
"VIR_KVM_TRANSPORT" virMigrateParamPtr.

(This implies that port number, like hostname, becomes a main argument 
to virDomainMigrate).

Incidentally, KVM also supports cancelling migrations (this interface 
doesn't), getting the status of migrations (this interface assumes the 
migration is synchronous and is supposed to only return when the 
migration is done), and setting resource limits.  The latter implies 
that resource limits should be a non-Xen-specific parameter.

[Source: http://kvm.qumranet.com/kvmwiki/Migration]

> RJ> +    /* Try to migrate. */
> RJ> +    ddomain = conn->driver->domainMigrate (domain, dconn, flags,
> RJ> +                                           dname,
> RJ> +                                           hostname ? hostname : nchostname,
> RJ> +                                           params);
> 
> As was previously mentioned, don't we need a call to the remote side
> to let it know that the domain is coming before we start the actual
> migration?  Are you expecting the driver implementation to do this?

Yes, I'm expecting the driver to do it.  Xen doesn't require anything at 
the moment.  It's quite happy to "engage" any caller :-)

Rich.

-- 
Emerging Technologies, Red Hat - http://et.redhat.com/~rjones/
Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod
Street, Windsor, Berkshire, SL4 1TE, United Kingdom.  Registered in
England and Wales under Company Registration No. 03798903
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3237 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20070716/f35dc610/attachment-0001.bin>