[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