Third version of virDomainMigrate API (was: Re: [Libvir] [PATCH 0/2] virDomainMigrate (for discussion only!))

[Richard W.M. Jones]

I think the conversation is heading towards a consensus around an API 
looking like that below.  Let me know overnight if there are problems, 
otherwise I'll produce an implementation for consideration tomorrow morning.

A hypervisor-agnostic call would look like this:

   ddom =
     virDomainMigrate (dom, dconn, VIR_MIGRATE_LIVE,
                       NULL, NULL, 0);

A hypervisor-specific call would look like this:

   ddom =
     virDomainMigrate (dom, dconn, VIR_MIGRATE_LIVE,
                       NULL, "ssh://root@dest/", 10);

/**
  * virDomainMigrate:
  * @domain: a domain object
  * @dconn: destination host (a connection object)
  * @flags: flags
  * @dname: (optional) rename domain to this at destination
  * @uri: (optional) dest hostname/URI as seen from the source host
  * @resource: (optional) specify resource limit in Mbps
  *
  * 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 path from the source to the destination.  This is the purpose
  * of the uri parameter.  If uri is NULL, then libvirt will try to
  * find the best method.  Uri may specify the hostname or IP address
  * of the destination host as seen from the source.  Or uri may be
  * a URI giving transport, hostname, user, port, etc. in the usual
  * form.  Refer to driver documentation for the particular URIs
  * supported.
  *
  * The maximum bandwidth (in Mbps) that will be used to do migration
  * can be specified with the resource parameter.  If set to 0,
  * libvirt will choose a suitable default.  Some hypervisors do
  * not support this feature and will return an error if resource
  * is not 0.
  *
  * Returns the new domain object if the migration was successful,
  *   or NULL in case of error.
  */

virConnectGetCapabilities[1] will be extended to return information 
about supported values for flags, domain renaming, URI formats and 
whether the hypervisor supports the resource parameter.  My suggested 
extension would be:

<capabilities>
   <host>
     <migration_features>
       <live/>           <!-- live migration supported -->
       <resource/>       <!-- resource limits supported -->
       <domain_rename/>  <!-- can rename domains -->
       <uri_transports>
         <uri_transport>ssh</uri_transport>
         <uri_transport>tcp</uri_transport>  (etc)
       </uri_transports>
     </migration_features>
   </host>
</capabilities>

(I think that's enough for now).

Rich.

[1] http://libvirt.org/format.html#Capa1

-- 
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/2378111d/attachment-0001.bin>