[vdsm] Future of Vdsm network configuration

Daniel P. Berrange berrange at redhat.com
Mon Nov 12 10:11:05 UTC 2012


On Sun, Nov 11, 2012 at 04:07:30PM +0200, Dan Kenigsberg wrote:
> Hi,
> 
> Nowadays, when vdsm receives the setupNetowrk verb, it mangles
> /etc/sysconfig/network-scripts/ifcfg-* files and restarts the network
> service, so they are read by the responsible SysV service.
> 
> This is very much Fedora-oriented, and not up with the new themes
> in Linux network configuration. Since we want oVirt and Vdsm to be
> distribution agnostic, and support new features, we have to change.
> 
> setupNetwork is responsible for two different things:
> (1) configure the host networking interfaces, and
> (2) create virtual networks for guests and connect the to the world over (1).
> 
> Functionality (2) is provided by building Linux software bridges, and
> vlan devices. I'd like to explore moving it to Open vSwitch, which would
> enable a host of functionalities that we currently lack (e.g.
> tunneling). One thing that worries me is the need to reimplement our
> config snapshot/recovery on ovs's database.
> 
> As far as I know, ovs is unable to maintain host level parameters of
> interfaces (e.g. eth0's IPv4 address), so we need another
> tool for functionality (1): either speak to NetworkManager directly, or
> to use NetCF, via its libvirt virInterface* wrapper.
> 
> I have minor worries about NetCF's breadth of testing and usage; I know
> it is intended to be cross-platform, but unlike ovs, I am not aware of a
> wide Debian usage thereof. On the other hand, its API is ready for vdsm's
> usage for quite a while.
> 
> NetworkManager has become ubiquitous, and we'd better integrate with it
> better than our current setting of NM_CONTROLLED=no. But as DPB tells
> us,
> https://lists.fedorahosted.org/pipermail/vdsm-devel/2012-November/001677.html
> we'd better offload integration with NM to libvirt.

NM is not entirely ubiquitous, and I think you'll find that even with
NM having proper bridging/bonding/etc support there will be many sysadmins
and distros who will not be prepared to mandate its use. This is where I
see libvirt's value in being. The virInterface drivers will be able to
take care of providing a consistent API for configuration regardless of
whether the host is using legacy initscripts network config, network
manager, or even conman. In other words if you don't use libvirt for
this, I think you'll find yourself re-inventing libvirt's functionality
in the end.


Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|


More information about the vdsm-devel mailing list