Hugh Brock wrote:
Daniel P. Berrange wrote:
3. The way I think you re suggesting - a libvirt server on every remote
host which calls into the regular libvirt internal driver model to
proxy remote calls. So even if the hypervisor in question provides a
remote network management API, we will always use the local API and
do *all* remote networking via the libvirt server
http://people.redhat.com/berrange/libvirt/libvirt-arch-remote-2.png
This strikes me as *much* easier to manage, and the most consistent
thus far with the idea that libvirt should remain as
hypervisor-neutral as possible.
I guess the management issue is going to be versioning the protocol. If
the protocol is just a direct mapping of vir* calls and structures then
you'll quickly end up in a situation where even the smallest change
requires you to upgrade the world or old versions have to be maintained
indefinitely.
That's not saying I don't like the idea.
Rich.
--
Red Hat UK Ltd.
64 Baker Street, London, W1U 7DF
Mobile: +44 7866 314 421 (will change soon)
--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
