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

[Daniel P. Berrange]

On Mon, Jul 16, 2007 at 10:29:36PM +0100, Richard W.M. Jones wrote:
> 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);

In terms of the set of data we need for a basic impl, I think these
are resonable. That said I've been thinking about this in relation to 
the earlier points in this  thread about cancellation, and progress info,
etc. I'm wondering if we would be well served by introducing a new object 
to co-ordinate the whole thing. 

  /* Prepare for migration to dconn */
  virDomainMigratePtr mig = virDomainMigratePrepare(dom, dconn)

  /* Optionally specify a custom transport */
  virDomainMigrateTransport(mig, "ssh://root@dest/");

  /* Optionally throttle */
  virDomainMigrateBandwidth(mig, 10);

  /* Perform the migration */
  virDomainMigrateRun(mig, flags);

  /* Release resources */
  virDomainMigrateFree(mig);

This would make it easier for us to extend the capabilities in the
future. eg adding more properties, or add APIs to run async, or 
getting progress info, etc, etc.

eg, if flags request ASYNC, then one could imagine cancellation via

   virDomainMigrateAbort(mig);

Or to poll for completion...

   virDomainMigrateStatus(mig);


Finally we could have a convenience API

   virDomainMigrate(dom, dconn);

For apps which don't care about custom transports, etc, etc

> 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>

Seems like a reasonable suggestion to add this to the capabilities XML
to allow detection of host / HV support.

Dan.
-- 
|=- Red Hat, Engineering, Emerging Technologies, Boston.  +1 978 392 2496 -=|
|=-           Perl modules: http://search.cpan.org/~danberr/              -=|
|=-               Projects: http://freshmeat.net/~danielpb/               -=|
|=-  GnuPG: 7D3B9505   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505  -=|