[netcf-devel] [libvirt] [RFC] Reporting host interface status/statistics via netcf/libvirt, and listing active vs. inactive interfaces

Daniel P. Berrange berrange at redhat.com
Mon Jun 22 09:50:31 UTC 2009


On Mon, Jun 22, 2009 at 10:58:49AM +0200, Jonas Eriksson wrote:
> On Thu, Jun 18, 2009 at 05:14:44PM +0000 David Lutterkort wrote:
> [..]
> > There's a few more options we need to add for completeness, at least
> > PERSISTENT_DHCLIENT, DHCPRELEASE, and DHCLIENT_IGNORE_GATEWAY are
> > supported by initscripts.
> 
> This raises a question - how should the features of some backends
> and the deficiencies of other backends be handled? Should netcf
> aim to handle just about everything? What about libvirt in the
> case that the netcf XML API is extended and the libvirt XML API
> is incompatible? What about features that are very similar but
> not exactly the same (an example is the SuSE STARTMODE which
> allows an interface to be started automatically at boot, when the
> if is hotplugged, from ifplugd (!= hotplugged, apparently), or
> autostarted but never automatically shut down)?

libvirt does not require that all functionality is present on
all platforms. So as long as an error is raised if the user
requests an unsupported configuration, we're fine.  As for the
XML question, libvirt requires 100% backwards compatability so
its XML format is essentially "append" only, existing features
cannot be dropped/changed. libvirt will be parsing & reformatting
all XML coming to/from netcf to guarentee that it is compliant
with libvirt's advertised schema (even if this happens to be the
same as netcf's)


Daniel
-- 
|: Red Hat, Engineering, London   -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org  -o-  http://virt-manager.org  -o-  http://ovirt.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-  F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|




More information about the libvir-list mailing list