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