----- Original Message -----
> From: "Dan Kenigsberg" <dan...@redhat.com>
> To: vdsm-de...@fedorahosted.org
> Sent: Sunday, November 11, 2012 4:07:30 PM
> Subject: [vdsm] Future of Vdsm network configuration
> 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
> 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,
> to use NetCF, via its libvirt virInterface* wrapper.
> I have minor worries about NetCF's breadth of testing and usage; I
> 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
> usage for quite a while.
> NetworkManager has become ubiquitous, and we'd better integrate with
> better than our current setting of NM_CONTROLLED=no. But as DPB tells
> 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
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
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
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...
vdsm-devel mailing list