Re: [vdsm] Host network management roadmap inquiry
On Mon, Aug 13, 2012 at 02:44:07PM +0300, Dan Kenigsberg wrote: On Sat, Aug 04, 2012 at 08:06:28PM +0300, Livnat Peer wrote: On 01/08/12 15:59, Mark Wu wrote: Sorry for cross-posting! I would like to inquiry about the roadmap of host network management in oVirt in order to make sure the ideas to be worked on are welcomed by community. I did some initial investigation on the following topics. I am not very familiar with them, so the information may contain some inaccuracies or errors. Hi Mark, My name is Livnat Peer, I'm focused on Networking in oVirt. I am wondering if there is an interest for a monthly meeting on networking in oVirt. I think we can discuss the current status in networking features/bugs and the road map for future oVirt versions. netcf: It provides cross-platform network configuration library/tool by converting the XML definition of an interface into local config file. It's already used by libvirt to manage host network interfaces.It supports all network entities including bridge, vlan, bond, nic. And it also supports configuration rollback. The benefit for vdsm is making host network stack configuration easy to port to other distros. Problems found: It doesn't restore interface live state during config transaction now. There's a feature request submit for it. There're some advanced settings not supported in netcf, like 'NM_CONTROLLED' and some less used bonding options. It doesn't provide python binding officially. But we can use libvirt API to integrate it into vdsm. It shouldn't have any impact on engine side. Making it easy to consume vdsm in other distros has great value for the ovirt project, I don't see a reason why not to do that. I think we should start with mapping the gaps of the functionality currently used by vdsm and see what is missing for us to use netcf. I think there was a proposal to use Network Manager in Fedora that also was supposed to work with netcf but I don't have more details on that, danken - do you recall something more specific? I'm afraid not - netcf-in-NM has been in the planning phase for quite some time, but NetworkManager still does its own config file parsing. Now that NM supports bridges, I have to stand corrected - bridges are on NM agenda, but they are not yet in. I'm not crazy about its dbus interface but the next statements still stand: due to its ubiquitousness on the desktop, we may want to use it as an API to managing host networking, instead of asking it don't touch our config, mister! (NM_CONTROLLED=no). Note that I haven't analysed NM's gaps for our use case, on top of my issues of trusting a package with an UpperCase name. ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] Host network management roadmap inquiry
On Sat, Aug 04, 2012 at 08:06:28PM +0300, Livnat Peer wrote: On 01/08/12 15:59, Mark Wu wrote: Sorry for cross-posting! I would like to inquiry about the roadmap of host network management in oVirt in order to make sure the ideas to be worked on are welcomed by community. I did some initial investigation on the following topics. I am not very familiar with them, so the information may contain some inaccuracies or errors. Hi Mark, My name is Livnat Peer, I'm focused on Networking in oVirt. I am wondering if there is an interest for a monthly meeting on networking in oVirt. I think we can discuss the current status in networking features/bugs and the road map for future oVirt versions. netcf: It provides cross-platform network configuration library/tool by converting the XML definition of an interface into local config file. It's already used by libvirt to manage host network interfaces.It supports all network entities including bridge, vlan, bond, nic. And it also supports configuration rollback. The benefit for vdsm is making host network stack configuration easy to port to other distros. Problems found: It doesn't restore interface live state during config transaction now. There's a feature request submit for it. There're some advanced settings not supported in netcf, like 'NM_CONTROLLED' and some less used bonding options. It doesn't provide python binding officially. But we can use libvirt API to integrate it into vdsm. It shouldn't have any impact on engine side. Making it easy to consume vdsm in other distros has great value for the ovirt project, I don't see a reason why not to do that. I think we should start with mapping the gaps of the functionality currently used by vdsm and see what is missing for us to use netcf. I think there was a proposal to use Network Manager in Fedora that also was supposed to work with netcf but I don't have more details on that, danken - do you recall something more specific? I'm afraid not - netcf-in-NM has been in the planning phase for quite some time, but NetworkManager still does its own config file parsing. Now that NM supports bridges, and due to its ubiquitousness on the desktop, we may want to use it as an API to managing host networking, instead of asking it don't touch our config, mister! (NM_CONTROLLED=no). Note that I haven't analysed NM's gaps for our use case, on top of my issues of trusting a package with an UpperCase name. ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] Host network management roadmap inquiry
Am Mittwoch, den 01.08.2012, 09:56 -0400 schrieb Andrew Cathrow: From: Mark Wu wu...@linux.vnet.ibm.com Sent: Wednesday, August 1, 2012 8:59:14 AM Subject: Host network management roadmap inquiry snip/ quantum Both the plugins openvswitch and linuxbridge stores abstract network entities (network, port) in database and create bridge/vlan via the tool ip/brctl or ovs-vsctl on demand. Only one bridge is created on one server and one vlan is created for each virtual network. That means that only one nic can be configured for vm network. It doesn't configure nic or bond even if openvswitch also supports bond. Both of traditional network stack configuration and quantum will be supported oVirt for different purpose, right? good place to start : https://fedoraproject.org/wiki/Quantum_and_oVirt Hey, besides these Quantum specific informations I'd also like to discuss where oVirt is going wrt to networking. Quantum is sure a nice solution for a project wide solution, but how can or should this be integrated into the underlying components like vdsm or node? From a Node pov (feature as well as implementation wise) it is quite interesting if we should switch to openvswitch (which can then in turn used by quantum [via vdsm?]) or keep the linux bridge stuff. There are also efforts on it's way (like teaming, the F17 feature) which we should keep an eye on, as this seems to land in network manager as an alternative(?) to the default bonding. It's also interesting how this performs with openvswitch. Many changes on many sides and we should lay out the path a bit to find a direction where to go. There is already http://wiki.ovirt.org/wiki/Networking which we could use to summarize the needed features, potential techniques and an over all plan. Greetings fabian signature.asc Description: This is a digitally signed message part ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
[vdsm] Host network management roadmap inquiry
Sorry for cross-posting! I would like to inquiry about the roadmap of host network management in oVirt in order to make sure the ideas to be worked on are welcomed by community. I did some initial investigation on the following topics. I am not very familiar with them, so the information may contain some inaccuracies or errors. netcf: It provides cross-platform network configuration library/tool by converting the XML definition of an interface into local config file. It's already used by libvirt to manage host network interfaces.It supports all network entities including bridge, vlan, bond, nic. And it also supports configuration rollback. The benefit for vdsm is making host network stack configuration easy to port to other distros. Problems found: It doesn't restore interface live state during config transaction now. There's a feature request submit for it. There're some advanced settings not supported in netcf, like 'NM_CONTROLLED' and some less used bonding options. It doesn't provide python binding officially. But we can use libvirt API to integrate it into vdsm. It shouldn't have any impact on engine side. IEEE 802.1Qbg(VEPA) It can offload network switching from server to external physical switch. It makes all VMs' traffic visible to physical switch, and therefore the existing switch functions (firewall, QoS etc) can be applied to VM immediately. The offload also frees up the server resource used by switching. Now libvirt supports it by using macvtap as vif and working with lldpad, which registers vif's mac/vlan information to the physical switch. We can just add a 'virtualport' element to an interface XML definition to add a VEPA interface. Probably, to support it in oVirt we still need configure lldpad and query available VSI types for virtualport profile. quantum Both the plugins openvswitch and linuxbridge stores abstract network entities (network, port) in database and create bridge/vlan via the tool ip/brctl or ovs-vsctl on demand. Only one bridge is created on one server and one vlan is created for each virtual network. That means that only one nic can be configured for vm network. It doesn't configure nic or bond even if openvswitch also supports bond. Both of traditional network stack configuration and quantum will be supported oVirt for different purpose, right? Any comments? Thanks! ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
