Open vSwitch Issue - Proxmox 3.2 Beta

[Rhongomiant]

Hello,

Can someone walk me through creating an internal only network? One that is not attached to a network interface that reaches outside the server so that VMs can communicate with each other. Is it simply creating a bridge without a bridge port? if so, is it better to use Open vSwitch for these?

The following is not a rant or a complaint or my ability to understand what "for now" means, but I did not see anything that explains current limitations or future plans for Open vSwitch.

Is vxlan currently supported and if it is how can I configure this via the GUI? if not, vxlan support planned?

I guess I am confused about the addition of Open vSwitch. My thought was that it would eliminate the need to reboot when making network changes if Open vSwitch is used. This is not the case at all. Creating Open vSwitch bridges, bonds and IntPorts all require reboots. Other than Open vSwitch having a 3rd option, IntPort, which makes creating vlan interfaces a little less confusing (the linux bridge config would be less confusing for this if there was a vlan field rather than requiring people to know they need to enter eth1.215 for vlan 215 on eth1), what benefit does Open vSwitch bring to Proxmox in it's current or will it bring in it's planned implementation? One of the listed benefits of Open vSwitch is the ability o migrate VMs between servers keeping the network config which would indicate being able to make dynamic network changes to VM servers which Proxmox does not support with or without Open vSwitch.

Given that the addition of Open vSwitch does not resolve the one issue preventing me from making Proxmox my production system, I would request that the Proxmox team consider allowing network changes to be made from the GUI without rebooting the server. Yes, an experienced Linux admin can do this via the CLI, but not everyone that adds VMs to the system will be experienced Linux admins.


Thanks for your help,

Rhonogmiant

 

[m.ardito]

Hello,
Can someone walk me through creating an internal only network? One that is not attached to a network interface that reaches outside the server so that VMs can communicate with each other. Is it simply creating a bridge without a bridge port? if so, is it better to use Open vSwitch for these?

a bridge with no eth slave ports does what you need. Need to restart? If you dont't wanto to mess with CLI, yes (I am not sure how to do that, though). Open vSwitch is still beta/test package in pve, so it's not ready for production servers, atm (aka "for now" ;-D). let's wait next releases, 3.2 probably.

in that other sticky thread I asked for similar info
"what is the current benefit of open vswitch? and, what is the purpose of OVS intport?"

and dietmar (one of the main pve developers, afaik) said:
"support for sflow, and slightly better performance when there is high load.
But I still prefer the standard linux network stack."

does this answer help you? to me, is enough for now.

also, imho, pve has many cool features, but being mostly a production tool, is not necessarily bleeding edge, and aims to stability: new features are often introduced aside old ones, and their usage can grow with time, updates, new releases, if there's an evident advantage over previous ones.

eg: sheepdog fs was introduced some time ago but is not yet recommended, and considered still beta.

Give developers time to test ovs and find the best way it could fit pve usage, but don't expect pve to fully support software which are not compatible with iptables too soon. That will not happen easily.

But perhaps some pve wizard will lighten us more, hopefully!

All the best,
Marco