On Tue, Jan 16, 2007 at 04:42:21PM +0000, 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. We only have to be able to safely add new functions, because we are already anticipating having to maintain 100% ABI compatability for existing public facing structs & functions indefinitely. Regards, Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|
