Richard W.M. Jones wrote:
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?Hugh Brock wrote:Daniel P. Berrange wrote: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.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.pngI 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.
--H