[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

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

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 :-)


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

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]