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