On Mon, Jul 16, 2007 at 10:58:18AM -0500, Anthony Liguori wrote:
John Levon wrote:
On Mon, Jul 16, 2007 at 10:47:59AM -0500, Anthony Liguori wrote:
If we need to express some choice of data channel, TCP, vs SSH, vs SSL/TLS then figure out a way to expose that in the API with an hypervisor agnostic way. Exposing raw QEMU migration URIs is *not* hypervisor agnostic.
Why? If nothing but QEMU support ssh:// then exposing an API to do SSH migration isn't really hypervisor agnostic. It's an API for QEMU.
You're presuming things never change (and that new backends never get added to libvirt!)
There's a big difference between taking two implements of SSH migration, finding the commonality, and building an abstraction verses just modeling the KVM ssh:// URI. The chances that a second implementation can be exposed nicely through the later is small.
What I'd rather see is something that exposed the bits of both KVM and Xen and then a second "agnostic" interface. For instance, for KVM you may have:
virDomainMigrateKVM(..., URI);
For Xen you'd have:
virDomainMigrateXen(..., hostname, port);
I don't see the point in having separate methods for those when Xen's hostname+port can be formatted as a URI too.
But then you'd also have:
virDomainMigrate(dom, connPtr);
So perhaps we should think about 2 possible APIs: - One based on a URI string - One based on a pre-existing virConnectPtr Or, have 1 API, and have the URI string optional and virConnectPtr be compulsory ? 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 -=|