[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

[libvirt] Update on host interface configuration



Hi,

I thought I'd write an update of what I've been doing with the host
interface configuration previously discussed[1] 

After talking with Dan Williams, who is working in NetworkManager, it is
clear that the network interface functionality for libvirt is also
useful for NM and would help them with handling system-wide interface
configuration. To accomodate that, I will implement network interface
configuration in a separate library (inspiringly called 'netcf', until
somebody thinks of something catchier) and add public API to libvirt
that will use netcf to do the actual work.

One thorny issue is how libvirt's public API and netcf's public API
relate to each other, especially since both libvirt and netcf use XML
descriptions to describe network interfaces (netcf does that for exactly
the same reasons that libvirt does it, since it will have to deal with
similar stability issues)

For the time being, I am assuming that the two XML descriptions are
identical, with no guarantee that that will always be the case. If and
when we run into a case where libvirt's and netcf's needs diverge, we'll
break that identity. On the implementation side, that means that, for
now, netcf will do all the validation and pass errors back to libvirt.

In more concrete terms, I put up a git repo[2] for netcf. There's hardly
any code in there, the things I'd particularly appreciate
review/feedback on are

      * the RelaxNG specification of the interface XML (in
        xml/interface.rng) together with examples of such interface
        specifications (in tests/interface/)
      * the (very rough) sketch of the netcf public API, which should
        map almost 1-1 to the public libvirt API in src/netcf.h

I know that the XML schema doesn't cover everything we've discussed in
[1], but I think it's a small enough subset to tackle relatively quickly
and large enough to be useful. So, one of the main things to think about
when looking at the schema is places where the schema would make it hard
to make desirable enhancements in the near future (like Marius' point
about default routes/gateways)

One important point about the model of network config in the schema is
that it is centered around what NM calls a 'connection' (though it's
called 'interface' in the schema): a grouping of the components that
make up the interface the user really cares about (a bridge or a bond)
together with the components subordinate to it (e.g. ethernet interfaces
enslaved to the bridge or bond) It's those groups that netcf deals with,
i.e. if eth0 is enslaved to br0, netcf won't list eth0 as an interface,
but only br0, with eth0 as a subinterface.

For the implementation, netcf will have a separate backend for each
network configuration regime (initscripts for
Fedora/RHEL, /etc/network/interfaces for Debian, ...) - once the
initscripts backend is done, I'd be very grateful for contributions for
the other backends.

To sketch out the initscripts implementation, I wrote two XSL
stylesheets, xml/initscripts-get.xml that goes from interface XML ->
initscripts files (via Augeas) and xml/initscripts-put.xml to go the
other way for querying; I'll use those for the core of the initscripts
backend. Whether other backands can be done in a similar manner is TBD.

David

[1] https://www.redhat.com/archives/libvir-list/2009-January/msg00350.html
[2] http://git.et.redhat.com/?p=netcf.git;a=tree



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]