[SOLVED] Bug in openvswitch implementation?

[grumpy-sysadmin]

I just started using Proxmox last night, but immediately run into issues with Openvswitch unfortunately.

I'm porting a setup that I had on Ubuntu, and used your Openvswitch guide as a reference. Unfortunately something isn't right.

What I'm trying to achieve is to tag the interface and trunk a few VLANs (which will then be used in the VMs).

My config looks like this (generated by the web interface):

allow-vmbr0 eno1
  iface eno1 inet manual
  ovs_type OVSPort
  ovs_bridge vmbr0

auto vmbr0
  iface vmbr0 inet static
  address 192.168.200.2
  netmask 255.255.255.0
  gateway 192.168.200.1
  ovs_type OVSBridge
  ovs_ports eno1
  ovs_options tag=200 trunk=10,201,202 vlan_mode=native-tagged

However, when I reboot, the interface does not come up. Digging deeper, I find that I cannot cleanly restart the networking service.

If I comment out the `ovs_options`, it starts just fine.

I also tried using just a subset (such as `ovs_options tag=200`), but that doesn't work either.

I read on the forums that it could be an issue with the wrong openvswitch module being used, so I ensured that I got the one from your repository.

root@nuc:~# dpkg -l openvswitch*
Desired=Unknown/Install/Remove/Purge/Hold
|
Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name Version Architecture Description
+++-=============================================-===========================-===========================-===============================================================================================
ii openvswitch-common 2.7.0-2 amd64 Open vSwitch common components
un openvswitch-datapath-module (no description available)
ii openvswitch-switch 2.7.0-2 amd64 Open vSwitch switch
implementations

I've also ensured that the server is updated as of today:

root@nuc:~# apt update && apt upgrade
[...]
Reading package lists... Done
Building dependency tree
Reading state information... Done
All packages are up to date.
Reading package lists... Done
Building dependency tree
Reading state information... Done
Calculating upgrade... Done
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.

Please advise. I need this server up and running tonight.

 

[wolfgang]

Hi,

I don't know why you have to set the trunk manual because it is not necessary.
For this setup openv-switch is a bit to much. All this can be done with Linux bridge.

try this

allow-vmbr0 eno0
iface eno0 inet manual
    ovs_type OVSPort
    ovs_bridge vmbr0

auto vmbr0
iface vmbr0 inet manual
    ovs_type OVSBridge
    ovs_ports eno0 vlan200

allow-vmbr0 vlan200
iface vlan200 inet static
    address 192.168.200.2
    netmask 255.255.255.0
    gateway 192.168.200.1
    ovs_type OVSIntPort
    ovs_bridge vmbr0
    ovs_options tag=200

 

[grumpy-sysadmin]

Hi,

I don't know why you have to set the trunk manual because it is not necessary.
For this setup openv-switch is a bit to much. All this can be done with Linux bridge.

try this

allow-vmbr0 eno0
iface eno0 inet manual
    ovs_type OVSPort
    ovs_bridge vmbr0

auto vmbr0
iface vmbr0 inet manual
    ovs_type OVSBridge
    ovs_ports eno0 vlan200

allow-vmbr0 vlan200
iface vlan200 inet static
    address 192.168.200.2
    netmask 255.255.255.0
    gateway 192.168.200.1
    ovs_type OVSIntPort
    ovs_bridge vmbr0
    ovs_options tag=200

I need Openvswitch for future things. This is just a POC deployment, but I need to know Openvswitch works. Besides, the performance is better in openvswitch than in bridges.

In any case, i need 'ovs_options' on the vmbr0 interface, as i need to set 'vlan_mode=native-tagged' and it appears as the ifup routine chokes when this option is present.

 

[tom]

Besides, the performance is better in openvswitch than in bridges.

How did you benchmark, can you provide numbers?

 

[grumpy-sysadmin]

I did some testing a while ago but not scientific enough. Might revisit that.

There are however other major benefits, like being able to pass on a set of tagged VLANs to a VM on a single interface.

Besides, if I'm not mistaken, Openstack adopted openvswitch so that is likely where things are moving anyways.

 

[grumpy-sysadmin]

I hate to be that guy, but openvswitch is officially supported in Proxmox. I would assume that it should work. That's why I bought a license to test with. Would really like to get this working today.

 

[Alwin]

trunk=10,201,202

shouldn't it be trunks? And what does the dmesg/syslog say?

 

[grumpy-sysadmin]

shouldn't it be trunks? And what does the dmesg/syslog say?

I'm not sure, but assuming this is just a wrapper around ovs-vsctl it should work (as it accepts that argument).

In any case, I also tried with just 'tag=X' and that failed in the same way, so my best guess is that it is something in that wrapper.

I did look in check the systemd logs with journalctl but nothing useful was found there (other than that it failed to start) unfortunately. Not sure if there are other in systemctl / dmesg. It's bit tricky to extract logs as i need to manually reconfigure the networking every time I reconnect it.

Also, FYI my previous setup was largely based on this setup https://forum.pfsense.org/index.php?topic=139045.0

 

[Alwin]

In the post, the used OVS version is 2.5.2. There might be syntax changes since then. Try to increase the logging in openvswitch.
https://developers.redhat.com/blog/2016/09/27/logging-in-open-vswitch/

 

[grumpy-sysadmin]

Just wanted to report in that I did get it working (but without trunks unfortunately), so I had to create multiple tagged interfaces on the VM. I didn't have enough time to experiment any further with trunks, but it seems like the UI in Proxmox isn't geared towards supporting trunks at the moment.

Thanks @Wulfgang for the config.