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!
----- Original Message -----
From: "Mark Wu" wudxw@linux.vnet.ibm.com To: "VDSM Project Development" vdsm-devel@lists.fedorahosted.org, arch@ovirt.org Sent: Wednesday, August 1, 2012 8:59:14 AM Subject: 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?
good place to start : https://fedoraproject.org/wiki/Quantum_and_oVirt
Any comments? Thanks!
Arch mailing list Arch@ovirt.org http://lists.ovirt.org/mailman/listinfo/arch
Am Mittwoch, den 01.08.2012, 09:56 -0400 schrieb Andrew Cathrow:
From: "Mark Wu" wudxw@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
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?
BTW - Can you please send the link to the feature request for netcf to support restore?
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.
when discussing the modeling of 802.1Qbg we should also look into 802.1Qbh, the modeling of the two should have a lot in common.
We looked into modeling the above two in the past but did not get a chance to actually work on it yet.
When adding support for a new technology in ovirt, especially in the modeling phase I think it is important to understand how ovirt users are going to use this technology and how the engine and vdsm together are going to provide a complete solution for our users.
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?
We had some discussions on integration with Quntum which included a few upstream calls to discuss the gaps we have in order to use quantum in ovirt. We had Gary that is working on quantum in these sessions and the link to the summary of our work so far was sent earlier on this thread.
Other than the above I maintain a wiki page with all the gaps we are aware of for networking in Ovirt -
http://wiki.ovirt.org/wiki/Networking
There you can see that there was a proposal to use Network-Manager in VDSM.
I see that Fabian split the page to features and technologies, thanks Fabian :)
Livnat
Any comments? Thanks!
Arch mailing list Arch@ovirt.org http://lists.ovirt.org/mailman/listinfo/arch
Hi Livnat,
Many thanks for your reply! Please see my inline comments.
On 08/05/2012 01:06 AM, 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.
Sure, I am glad to join. Thanks for your invitation.
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 am going to implement a prototype for it. Probably, we can find more what's missing in netcf during the prototype development.
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?
BTW - Can you please send the link to the feature request for netcf to support restore?
Here's the feature request, and I have added you to the cc list :) https://bugzilla.redhat.com/show_bug.cgi?id=737149
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.
when discussing the modeling of 802.1Qbg we should also look into 802.1Qbh, the modeling of the two should have a lot in common.
We looked into modeling the above two in the past but did not get a chance to actually work on it yet.
When adding support for a new technology in ovirt, especially in the modeling phase I think it is important to understand how ovirt users are going to use this technology and how the engine and vdsm together are going to provide a complete solution for our users.
Make sense. We need collect more customer use case of them before modelling it.
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?
We had some discussions on integration with Quntum which included a few upstream calls to discuss the gaps we have in order to use quantum in ovirt. We had Gary that is working on quantum in these sessions and the link to the summary of our work so far was sent earlier on this thread.
Other than the above I maintain a wiki page with all the gaps we are aware of for networking in Ovirt -
http://wiki.ovirt.org/wiki/Networking
There you can see that there was a proposal to use Network-Manager in VDSM.
I see that Fabian split the page to features and technologies, thanks Fabian :)
Livnat
Any comments? Thanks!
Arch mailing list Arch@ovirt.org http://lists.ovirt.org/mailman/listinfo/arch
On 06/08/12 10:16, Mark Wu wrote:
Hi Livnat,
Many thanks for your reply! Please see my inline comments.
On 08/05/2012 01:06 AM, 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.
Sure, I am glad to join. Thanks for your invitation.
An invite was sent to the lists.
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 am going to implement a prototype for it. Probably, we can find more what's missing in netcf during the prototype development.
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?
BTW - Can you please send the link to the feature request for netcf to support restore?
Here's the feature request, and I have added you to the cc list :) https://bugzilla.redhat.com/show_bug.cgi?id=737149
thank you
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.
when discussing the modeling of 802.1Qbg we should also look into 802.1Qbh, the modeling of the two should have a lot in common.
We looked into modeling the above two in the past but did not get a chance to actually work on it yet.
When adding support for a new technology in ovirt, especially in the modeling phase I think it is important to understand how ovirt users are going to use this technology and how the engine and vdsm together are going to provide a complete solution for our users.
Make sense. We need collect more customer use case of them before modelling it.
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?
We had some discussions on integration with Quntum which included a few upstream calls to discuss the gaps we have in order to use quantum in ovirt. We had Gary that is working on quantum in these sessions and the link to the summary of our work so far was sent earlier on this thread.
Other than the above I maintain a wiki page with all the gaps we are aware of for networking in Ovirt -
http://wiki.ovirt.org/wiki/Networking
There you can see that there was a proposal to use Network-Manager in VDSM.
I see that Fabian split the page to features and technologies, thanks Fabian :)
Livnat
Any comments? Thanks!
Arch mailing list Arch@ovirt.org http://lists.ovirt.org/mailman/listinfo/arch
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.
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@lists.fedorahosted.org