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