[pve-devel] proxmox 2018 : add support for "virtual" network and network plugins ?

Alexandre DERUMIER aderumier at odiso.com
Tue Jan 2 15:04:33 CET 2018


>>the following might be possible, but not sure whether we really want to
>>do them (now/soon):
>>- integration of SDN firewall functionality
>>- integration of custom or SDN DHCP server functionality
>>
>>before writing actual code, it would probably be a good idea to discuss
>>scope and use cases with a bit more detail, and then define a plugin
>>interface (or interfaces if we split the APIs).

dhcp/firewall/ (and others possible sdn services (balancer, vrouters,...) can be managed by external sdn controllers (ovs/ovn  , opencontrail, openflow/opendaylight).
So maybe this need like for storages, some kind of integration through api



>> OVS is a bit special in this regard, as we already have some 
>>support for local OVS in /e/n/interfaces, so user might need to convert 
>>this when switching to full blown OVS on a cluster level? we could 
>>differentiate those two by generating interfaces.d files for OVS 
>>networks defined via /etc/pve/networks.cfg or some mechanism like that? 
>>the interfaces.d folder is currently not used at all by our 
>>parser/writer..

for ovs, I think ovn project in the right way to manage it at cluster level
http://openvswitch.org/support/slides/OVN-Vancouver.pdf
we could still manage the ovs switch locally, and the ovn controller manage the vxlan, routing, flow, ... 



I think we have 2 kind of setup:

- basic local vswitch (bridge, ovs, snabwitch,....) : can be easily setup with systemd-network + some tap/eth plug/unplug scripts.
- bigger sdn setup, with external controllers. (which could manage networks across multiple proxmox clusters too)



----- Mail original -----
De: "Fabian Grünbichler" <f.gruenbichler at proxmox.com>
À: "pve-devel" <pve-devel at pve.proxmox.com>
Envoyé: Mardi 2 Janvier 2018 11:55:05
Objet: Re: [pve-devel] proxmox 2018 : add support for "virtual" network and network plugins ?

On Sat, Dec 30, 2017 at 04:15:29PM +0100, Alexandre DERUMIER wrote: 
> Hi everybody, 
> 
> First, merry X-mas and happy new year to all proxmox team. 
> (You have made a great job in 2017, a lot of polish and cleanup to current proxmox code !). 
> 
> 
> I looking for 2018, to add support for network plugins (like for storage), and "virtual networks". 
> 
> 
> By virtual network, I mean, to be able to define new kind of sdn networks or abstract of "vmbr+vlan" 
> for exapple 
> 
> "customerA network" -> which could be "vmbrX + vlan" 
> "customerB network" -> which could be "ovs vmbrX + vxlan" 
> "customerC network" -> which could be "ovs+dpdk" 
> "customerD network" -> which could be "another kind of network (opencontrail vrouter, vpp, snabswitch, midonet ..." 
> 
> also be able to defined network range, that user could use by network. 
> 
> and a Custom Plugin directory , like for storage, where users could defined they own plugins. 
> 
> 
> 
> Something like /etc/pve/networks.cfg (like storage.cfg, with network-plugins-options) 
> 
> 
> What do you think about it ? 

sounds like a good idea in general IMHO, but needs to be well-prepared 
and thought through. some initial brain storming results below.. 

maybe a first step might be to refactor the existing OVS and ifupdown 
support into two basic plugins for (local) network management, and then 
extend it to support systemd-networkd with a third plugin (since the 
feature set and scope is very similar, this should be easy enough). 
a fourth (or rather, first) base plugin implementing all the stuff that 
falls into "here is a kernel netdev, do operation FOO" where the 
underlying stack is not important is probably a good idea to reduce code 
duplication ;) 

a next step would then be to think about whether extending this API to 
software defined non-local networks make sense, or whether we need a 
more high-level split between local and cluster-wide network management 
plugins (potentially with implementations of both for a single 
technology?). 

from the top of my head, the following functionality would be needed: 
- link/device setup 
-- physical devices 
-- bridges 
-- bonds 
[ -- tunnels ? ] 
- address and prefix assignment to devices 
- route management 
- guest device plug/unplug 
- QoS/shaping 

the following might be possible, but not sure whether we really want to 
do them (now/soon): 
- integration of SDN firewall functionality 
- integration of custom or SDN DHCP server functionality 

before writing actual code, it would probably be a good idea to discuss 
scope and use cases with a bit more detail, and then define a plugin 
interface (or interfaces if we split the APIs). 

there is also the question of whether a cluster-wide networks.cfg makes 
sense for the non-SDN config. I think auto-detecting existing 
/etc/network/interfaces and systemd-networkd configurations is all that 
is needed for the local config, and we only need a cluster-wide file for 
the SDNs. OVS is a bit special in this regard, as we already have some 
support for local OVS in /e/n/interfaces, so user might need to convert 
this when switching to full blown OVS on a cluster level? we could 
differentiate those two by generating interfaces.d files for OVS 
networks defined via /etc/pve/networks.cfg or some mechanism like that? 
the interfaces.d folder is currently not used at all by our 
parser/writer.. 

_______________________________________________ 
pve-devel mailing list 
pve-devel at pve.proxmox.com 
https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel 




More information about the pve-devel mailing list