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

[Richard W.M. Jones]

To cut to the chase, this is the proposed additional libvirt call to 
support migration.  Please also read my explanation below.

/**
  * virDomainMigrate:
  * @domain: a domain object
  * @dconn: destination host (a connection object)
  * @flags: flags
  * @dname: (optional) rename domain to this at destination
  * @hostname: (optional) remote hostname as seen from the source host
  * @params: linked list of hypervisor-specific parameters
  *
  * Migrate the domain object from its current host to the destination
  * host given by dconn (a connection to the destination host).
  *
  * Flags may be one of more of the following:
  *   VIR_MIGRATE_LIVE   Attempt a live migration.
  *
  * If a hypervisor supports renaming domains during migration,
  * then you may set the dname parameter to the new name (otherwise
  * it keeps the same name).  If this is not supported by the
  * hypervisor, dname must be NULL or else you will get an error.
  *
  * Since typically the two hypervisors connect directly to each
  * other in order to perform the migration, you may need to specify
  * a hostname, which is the hostname or IP address of the destination
  * host as seen from the source host.  If in doubt, leave this as
  * NULL and libvirt will attempt to work out the correct hostname.
  *
  * Params is a linked list of hypervisor-specific parameters.  Each
  * element is a virMigrateParamPtr containing the following fields:
  *   name               Parameter name being set.
  *   value              A union expressing the value.
  *     value.strv         A string value.
  *     value.longv        A long value.
  *   next               Next in linked list (or NULL for end of list).
  *
  * Parameter names for Xen are:
  *   VIR_MIGRATE_XEN_PORT     (long) Override the default port number.
  *   VIR_MIGRATE_XEN_RESOURCE (long) Set maximum resource usage (Mbps).
  *
  * Set params to NULL if you do not want to pass any hypervisor-specific
  * parameters.
  *
  * Returns the new domain object if the migration was successful,
  *   or NULL in case of error.
  */

As discussed previously on this list, you need to have libvirt 
connections to both the source and destination hosts.

I've tried to separate out what I believe will be common features of 
migration across hypervisors, and what is currently supported by Xen.

What I think will be common features are:
  * live migration
  * direct host<->host connections
  * renaming domains during migration

These are supported with explicit parameters.  Drivers should check the 
parameters and any which are not supported should be rejected (eg. Xen 
cannot rename a domain when it is migrating, although this seems like it 
ought to be a common thing to want to do -- to prevent name clashes on 
the destination host which would otherwise make it impossible to migrate 
a domain).

The explicit parameters include a general "flags" parameter, which we 
can extend with other boolean flags later.  For host<->host connections 
you'll want some way to specify the hostname / IP address of the 
destination host as seen at the source.  In the remote management case 
it's not always so easy to work this out.  We can try using 
virConnectGetHostname, but we also allow the caller to override.

On the other hand, there will be some hypervisor-specific features, and 
these are enabled through a linked list of parameters.  For Xen these 
include setting port and resource usage.  I guess other hypervisors will 
have their own parameters -- eg. security settings.

In the current (Xen) implementation, any parameters which it doesn't 
understand are rejected with VIR_ERR_NO_SUPPORT.

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: libvirt-xen-migrate-20070716.patch
Type: text/x-patch
Size: 14030 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20070716/1d48ad02/attachment-0002.bin>
-------------- 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/1d48ad02/attachment-0003.bin>