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.
--
Libvir-list mailing list
Libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list