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

[Anthony Liguori]

Daniel P. Berrange wrote:
> On Mon, Jul 16, 2007 at 10:47:59AM -0500, Anthony Liguori wrote:
>   
> Its depends where you need to expose it. For any single deployment of
> do you need to be able to use all possible transports ? I think that
> some people will choose SSH, others will choose SSL, other's something
> else again, but they aren't all neccessarily used all the time. So it
> may be sufficient to specify which migration scheme to use per host.
> So libvirt can make use of all possible transports, without having to
> expose this to every single application using the API.
>   

Right, the problem is that an admin can define a new transport for QEMU 
(or at least, the will be able to soon) by adding an external URI handler.

For instance, let's say at a university they use an ldap directory to 
authenticate users and they decide to implement a migration handler that 
uses that for authentication.  They may name this "uni://" and it'll 
just work.  How would they get at this in libvirt without exposing URIs 
directly?

Regards,

Anthony Liguori

>> I think there's a balance between being hypervisor agnostic and only 
>> supporting the least common denominator.  Whenever there's a possibility 
>> to be common, I think libvirt should strive to provide a common 
>> interface but I still think it's important to unique features of the 
>> particular virtualization solution.
>>     
>
> Sure, but making use of all available capabilities in libvirt doesn't mean
> we have to expose them all in the API - some can be used 'behind the scenes'
> without apps needing to care about them.
>
> Dan.
>