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 >>> [email protected] >>> http://lists.ovirt.org/mailman/listinfo/arch >>> > _______________________________________________ Arch mailing list [email protected] http://lists.ovirt.org/mailman/listinfo/arch
