Richard W.M. Jones wrote:
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.
True enough... we're guaranteeing we're going to have backwards
compatibility problems. On the other hand the libvirt API is supposed to
be held pretty stable. DV, any thoughts?
--H
