Re: Third version of virDomainMigrate API (was: Re: [Libvir] [PATCH 0/2] virDomainMigrate (for discussion only!))
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 -=|