[Libvir] Re: [PATCH 1/2] virDomainMigrate implementation (Xen only, no remote, no qemu, no virsh)
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.