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