proxmox 7.0 sdn beta test

Ok, I know that this is not strictly related to the new SDN features but as ifupdown2 was modified....

first question: is it supposed to work a switch from linux bridge to OVS bridge without a reboot?

I've made these tests:
1)
FROM: Linux bridge (single NIC) assigned ip -> TO: OVS bond (slaved to OVS bridge (same name)) + OVS intPort (same ip)
RESULT: Proxmox ip always reachable (negligible interruption) but VMs lost connectivity. After VMs restart, VMs regain connectivity without rebooting Proxmox.


2) (inverse process)
FROM: OVS bond + OVS intPort in OVS bridge -> TO: Linux bridge (single NIC) same ip as OVS intport
RESULT: networking lost (either Proxmox and VMs). After a reboot everything restart ok.

Is this the expected behavior?

By the way: without changing the main bridge (ovs or linux) everything seems to work fine (ip change, adding vlans

I'm using:
libpve-network-perl/now 0.4-6 all [installed,local]
ifupdown2/now 3.0.0-1+pve2 all [installed,local]
openvswitch-switch/stable,now 2.12.0-1 amd64 [installed]
 
@Mike Lupe

last packages from pvetest have a lof of fixes, cleanup for openvswitch. It should works really fine now with vlan|qinq plugins, without breaking your existing vms directly plugged on vmbrX.

Thanks @spirit , I've followed this thread for the past days in the background :) Great job!

What's the ETA for these updates in no-sub repo?
 
Ok, I know that this is not strictly related to the new SDN features but as ifupdown2 was modified....

first question: is it supposed to work a switch from linux bridge to OVS bridge without a reboot?

mmm, i could works if you change name of vmbrX. (switch from vmbr0 bridge to vmbr1 ovs, or vmbr0 ovs to vmbr1 linux bridge)
I'm not sure it's possible to change from "vmbr0" linux bridge to "vmbr0" ovs. (maybe bridge->ovs, but not in the reverse way)



For the vms, yes, this is expected to loss, because proxmox plug them dynamically, and the interfaces are not defined in /etc/network/interfaces.
I should forbid to delete a bridge if tap interfaces are still running. I'm not sure about ovs. and maybe it's not working when you keep name same.

I'll try to see if i can improve this, at least throw an error to tell user to reboot in this case. This is really the most complex action on reload.
 
I'll try to see if i can improve this, at least throw an error to tell user to reboot in this case. This is really the most complex action on reload.

Thanks for answer.

IMHO it's not worth to waste time improving this kind of dynamic switch.
What we have now is more than enough.
Definetely a warning that switching from OVS to Linux bridge may require a reboot we'll be fine.

I'll keep on testing.
 
Maybe I found a problem.
After updating ifupdown2 some nics don't come up at boot time anymore.

This is the setup:
Code:
auto lo
iface lo inet loopback

iface eno1 inet manual
iface eno2 inet manual

auto unt
iface unt inet static
        address 192.168.200.232/24
        gateway 192.168.200.254
        ovs_type OVSIntPort
        ovs_bridge vmbr0

auto bond0
iface bond0 inet manual
        ovs_bonds eno1 eno2
        ovs_type OVSBond
        ovs_bridge vmbr0
        ovs_options bond_mode=balance-slb

auto vmbr0
iface vmbr0 inet manual
        ovs_type OVSBridge
        ovs_ports bond0 unt

I have this setup with different rigs: using Intel nics (igb module) everything it's fine, using Broadcom nics (tg3 module) the nics don't go up at boot time.
If after boot I pull them manually up (ip link set eno1 up) everything work again,
It seems like boot script pulls up only the bond but this is not always enough to pull nics up.
 
Found another problem.
libpve-network-perl_0.4-6 breaks LXC; container don't start.
Was working with libpve-network-perl_0.4-4
 
I have this setup with different rigs: using Intel nics (igb module) everything it's fine, using Broadcom nics (tg3 module) the nics don't go up at boot time.
If after boot I pull them manually up (ip link set eno1 up) everything work again,
it's missing "auto eno1", "auto eno2"

It seem that ifupdown2 + linux bond , is ifuping underlying interfaces even if auto is missing.
I'll try to fix that soon for ovs plugin.
But "auto <enoX>" is really the cleanest way.
 
Last edited:
Yes, sure but this is not required with other nics.
Anyway it's enough easy to remember to flag Autostart in the gui.
I really don't known why it's working with other nics.
Without auto, it's some kinds of hack in scripts to try to start the interfaces when they are in a bond.

I'll fix the proxmox code, to add "auto ethX" when they are in a bond. (It's not done currently)
 
I really don't known why it's working with other nics.
Without auto, it's some kinds of hack in scripts to try to start the interfaces when they are in a bond.

I'll fix the proxmox code, to add "auto ethX" when they are in a bond. (It's not done currently)

I have sent patch to dev mailing list to add 'auto xxx" on bond slaves interfaced
 
I have sent patch to dev mailing list to add 'auto xxx" on bond slaves interfaced
Fine thanks! IMHO this is the right way. I can confirm that adding 'auto ...' fix the problem.

BTW: other tests are all going fine! (OVS + VXLAN)
 
pve-manager 6.2-5 (6.2-6 same) seems to introduce a bug with sdn.
Creating a zone the zone is listed within nodes items (without icon).
Till 6.2-4 clicking on it a vnet lists is shown also allowing to set permissions.
After 6.2-5 clicking on it breaks extjs interface.

Is this bug known?
 
Hi

First off thanks for the excellent work.

I am trying to test a vxlan using sdn on a cluster setup on Hetzner dedicated servers.

I have these interfaces working on my dedicated server as per recommended hetzner setup.

Code:
### Hetzner Online GmbH installimage

source /etc/network/interfaces.d/*

auto lo
iface lo inet loopback
iface lo inet6 loopback

auto enp0s31f6
iface enp0s31f6 inet static
  address 5.9.x.x
  netmask 255.255.255.224
  gateway 5.9.x.x
  # route 5.9.x.x/27 via 5.9.x.x
  up route add -net 5.9.x.x netmask 255.255.255.224 gw 5.9.x.x dev enp0s31f6

iface enp0s31f6 inet6 static
  address 2a01:4f8:x:x::2
  netmask 64
  gateway fe80::1

auto enp0s31f6.4001
iface enp0s31f6.4001 inet static
  address 192.168.100.5
  netmask 255.255.255.0
  vlan-raw-device enp0s31f6
  mtu 1400


I have a few doubts / issues:
1 - I have private vlan interfaces setup on the hetzner vlan. My assumption is that I cannot use this to create the local proxmox host bridge (see https://forum.proxmox.com/threads/qinq-on-hetzner-vswitch.62071/ "they confirmed to me that neither QinQ nor VXLAN is possible on top of the Hetzner vSwitches"). Is this hetzner vlan setup interfering with the proxmox sdn even if I'm not using for proxmox?

2 - Should I use the public or private hetzner vlan interfaces to create the proxmox cluster? My expectation is that both should work, but since they are using the same physical nic, I might as well use the physical public interface.

3 - On the documentation, I read:
Code:
auto vmbr0
iface vmbr0 inet static
        address 192.168.0.1/24
        gateway 192.168.0.254
        bridge-ports eno1
        bridge-stp off
        bridge-fd 0
        mtu 1500


source /etc/network/interfaces.d/*

Where is the eno1 identifier coming from? Is that the name of my physical public interface?

4 - I like to edit files rather than messing around with the GUI. After I modify /etc/network/interfaces, what is the command to run on the host to reload the config? I have found a multitude of ways of achieving that and I really don't want to reboot the host every time.

Many thanks and apologies if some of this is trivial, I'm new to this.
Regards
MR
 

About

The Proxmox community has been around for many years and offers help and support for Proxmox VE, Proxmox Backup Server, and Proxmox Mail Gateway.
We think our community is one of the best thanks to people like you!

Get your subscription!

The Proxmox team works very hard to make sure you are running the best software and getting stable updates and security enhancements, as well as quick enterprise support. Tens of thousands of happy customers have a Proxmox subscription. Get yours easily in our online shop.

Buy now!