----- Original Message ----- > From: "Mark Wu" <wu...@linux.vnet.ibm.com> > To: "Alon Bar-Lev" <alo...@redhat.com> > Cc: "Dan Kenigsberg" <dan...@redhat.com>, vdsm-de...@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" <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. > > 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@lists.fedorahosted.org > > https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel > _______________________________________________ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel