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

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



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

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


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