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);
But then you'd also have:
virDomainMigrate(dom, connPtr);
So I'm not necessarily arguing that there shouldn't be an agnostic
interface, but rather that the lower bits should be exposed too.
Regards,
Anthony Liguori
regards
john
--
Libvir-list mailing list
Libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list