[Libvir] Re: [PATCH 1/2] virDomainMigrate implementation (Xen only, no remote, no qemu, no virsh)

[Anthony Liguori]

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
>
>