[vdsm] Future of Vdsm network configuration

Adam Litke agl at us.ibm.com
Wed Nov 14 16:01:54 UTC 2012


On Wed, Nov 14, 2012 at 11:53:06AM +0200, Livnat Peer wrote:
> On 14/11/12 00:28, Adam Litke wrote:
> > On Sun, Nov 11, 2012 at 09:46:43AM -0500, Alon Bar-Lev wrote:
> >>
> >>
> >> ----- Original Message -----
> >>> From: "Dan Kenigsberg" <danken at redhat.com>
> >>> To: vdsm-devel at fedorahosted.org
> >>> Sent: Sunday, November 11, 2012 4:07:30 PM
> >>> Subject: [vdsm] Future of Vdsm network configuration
> >>>
> >>> 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.
> >>>
> >>> We would like to take Network configuration in VDSM to the next level
> >>> and make it distribution agnostic in addition for setting the
> >>> infrastructure for more advanced features to be used going forward.
> >>> The path we think of taking is to integrate with OVS and for feature
> >>> completeness use NetCF, via its libvirt virInterface* wrapper. Any
> >>> comments or feedback on this proposal is welcomed.
> >>>
> >>> Thanks to the oVirt net team members who's input has helped writing
> >>> this
> >>> email.
> >>
> >> Hi,
> >>
> >> As far as I see this, network manager is a monster that is a huge dependency
> >> to have just to create bridges or configure network interfaces... It is true
> >> that on a host where network manager lives it would be not polite to define
> >> network resources not via its interface, however I don't like we force network
> >> manager.
> >>
> >> libvirt is long not used as virtualization library but system management
> >> agent, I am not sure this is the best system agent I would have chosen.
> >>
> >> I think that all the terms and building blocks got lost in time... and the
> >> result integration became more and more complex.
> >>
> >> Stabilizing such multi-layered component environment is much harder than
> >> monolithic environment.
> >>
> >> I would really want to see vdsm as monolithic component with full control over
> >> its resources, I believe this is the only way vdsm can be stable enough to be
> >> production grade.
> >>
> >> Hypervisor should be a total slave of manager (or cluster), so I have no
> >> problem in bypassing/disabling any distribution specific tool in favour of
> >> atoms (brctl, iproute), in non persistence mode.
> >>
> >> I know this derive some more work, but I don't think it is that complex to
> >> implement and maintain.
> >>
> >> Just my 2 cents...
> > 
> > I couldn't disagree more.  What you are suggesting requires that we reimplement
> > every single networking feature in oVirt by ourselves.  If we want to support
> > the (absolutely critical) goal of being distro agnostic, then we need to
> > implement the same functionality across multiple distros too.  This is more work
> > than we will ever be able to keep up with.  If you think it's hard to stabilize
> > the integration of an external networking library, imagine how hard it will be
> > to stabilize our own rewritten and buggy version.  This is not how open source
> > is supposed to work.  We should be assembling distinct, modular, pre-existing
> > components together when they are available.  If NetworkManager has integration
> > problems, let's work upstream to fix them.  If it's dependencies are too great,
> > let's modularize it so we don't need to ship the parts that we don't need.
> > 
> 
> I agree with Adam on this one, reimplementing the networking management
> layer by ourselves using only atoms seems like duplication of work that
> was already done and available for our use both by NM and by libvirt.
> 
> Yes, it is not perfect (far from it actually) but I think we better
> focus our efforts around adding new functionalities to VDSM and
> improving the current robustness of the code (we have issues regardless
> of any external component we're using).
> 
> For the sake of being distribution agnostic I support the original plan
> proposed by danken, using OVS combined with libvirt virInterface* wrapper.

ACK.

-- 
Adam Litke <agl at us.ibm.com>
IBM Linux Technology Center



More information about the vdsm-devel mailing list