[vdsm] Future of Vdsm network configuration

Mark Wu wudxw at linux.vnet.ibm.com
Mon Nov 12 09:51:15 UTC 2012


On 11/11/2012 10:07 PM, 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
As far as I know,  ovs also supports bond. Even though it doesn't have 
as many modes as what Linux bonding has,
it supports load balancing and fail-over at least.  For vlan, we could 
make the nic port as trunk port and use libvirt's
'portgroup' feature to create an access or trunk port for vif.  Then it 
could replace Linux vlan configuration.

> 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.
Undo the ovs command could restore the ovs database to the state before 
the new configuration call. This could help in some cases.
If we can separate vm network from management network, it should not be 
a big problem.
>
> 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.
IMHO,  ip address is not useful for pure vm network. We can leave the 
network address configuration of management network to deployment. So ovs
can cover all typical network configurations.  I think we don't need to 
wait for NetworkManager is ready to consume via libvirt virInterface.
We could have multiple network management drivers in vdsm.  And part of 
openvswitch support code is also useful to integrate quantum
into oVirt.

>
> 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.
>
> Dan.
>



More information about the vdsm-devel mailing list