----- 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 > > 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... Regards, Alon _______________________________________________ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
