[vdsm] Future of Vdsm network configuration

Alon Bar-Lev alonbl at redhat.com
Tue Nov 13 08:03:15 UTC 2012


----- Original Message ----- 

> From: "Mark Wu" <wudxw at linux.vnet.ibm.com>
> To: "Alon Bar-Lev" <alonbl at redhat.com>
> Cc: "Dan Kenigsberg" <danken at redhat.com>, vdsm-devel at fedorahosted.org
> Sent: Tuesday, November 13, 2012 5:39:12 AM
> Subject: Re: [vdsm] Future of Vdsm network configuration

> On 11/11/2012 10:46 PM, 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.
> 
> Do you mean just using the utilities (brctl, iproute) on demand and
> not keeping any network configuration
> on vdsm host? Then manager needs reconfigure network on every host
> reboot. Actually, I like this way.
> It could be more flexible than libvirt's virInterface (netcf or NM)
> and have fine-grained control to handle some tough cases. Moreover,
> it's clean than the current mangling network configuration files.

Yes, exactly. 

> > I know this derive some more work, but I don't think it is that
> > complex to implement and maintain.
> 

> > Just my 2 cents...
> 

> > Regards,
> 
> > Alon
> 
> > _______________________________________________
> 
> > vdsm-devel mailing list vdsm-devel at lists.fedorahosted.org
> > https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
> 


More information about the vdsm-devel mailing list