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
-- Libvir-list mailing list Libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list