Trying to get OVS working on PVE7. I saw former threads saying that the Openvswitch-switch package should be installed from the pve-no-subscription repository, but this is for older versions of PVE. I can't locate the package in the bullseye pve-no-subscription repo. Should I just be installing the debian version at this point? I tried config'ing using the debian package and a known good "interfaces" config that was working on PVE6, but it doesn't work on PVE7. I can't remember from which repo I got OVS prior for PVE6, but don't remember having to jump through any hoops to do it.
PVE7 Openvswitch-switch repository
- Thread starter ndoggac
- Start date
ok, I finally got it working. for others info.
On PVE7 the debian package openvswitch-switch is what you want. The package is not in the bullseye pve-no-subscription repository. Also, a change from PVE6 in the requirements in the OVS config. Before you did not need "auto <interface>", or "auto <vlan>" to get things working in PVE6, but you now need them in PVE7. Also, I believe PVE7 already had ifupdown2 installed.
Here is my working /etc/network/interfaces implementing OVS with a VLAN. The 10gb interface (enp2s0) is my main network connection to my L3 switch, while the 1gb interface (eno1) is normally not connected, but I can manually connect if something with the main interface goes wrong.
On PVE7 the debian package openvswitch-switch is what you want. The package is not in the bullseye pve-no-subscription repository. Also, a change from PVE6 in the requirements in the OVS config. Before you did not need "auto <interface>", or "auto <vlan>" to get things working in PVE6, but you now need them in PVE7. Also, I believe PVE7 already had ifupdown2 installed.
Here is my working /etc/network/interfaces implementing OVS with a VLAN. The 10gb interface (enp2s0) is my main network connection to my L3 switch, while the 1gb interface (eno1) is normally not connected, but I can manually connect if something with the main interface goes wrong.
Code:
auto lo
iface lo inet loopback
allow-ovs vmbr0
iface vmbr0 inet manual
ovs_type OVSBridge
ovs_ports enp2s0 vlan2
ovs_mtu 1500
#Master Bridge
allow-ovs vmbr1
iface vmbr1 inet static
address 192.168.1.99/24
ovs_type OVSBridge
ovs_ports eno1
#1Gb Emergency Access
auto enp2s0
allow-vmbr0 enp2s0
iface enp2s0 inet manual
ovs_type OVSPort
ovs_bridge vmbr0
auto eno1
allow-vmbr1 eno1
iface eno1 inet manual
ovs_type OVSPort
ovs_bridge vmbr1
auto vlan2
allow-vmbr0 vlan2
iface vlan2 inet static
ovs_type OVSIntPort
ovs_bridge vmbr0
ovs_options tag=2
address 192.168.2.99
netmask 255.255.255.0
gateway 192.168.2.1
ovs_mtu 1500
#Proxmox Admin
Last edited:
Curious as to why the openvswitch-switch repository location keeps going back and forth between debian & pve-no-subscription repos? If both repos are enabled, and the package exists in both, will an "apt install" grab from the pve repo rather than the debian? Or would you have to temporarily disable the debian repo, or issue a more precise apt command, to ensure you get the correct package?
They
They are no openvswitch package in proxmox7 repos
Code:
# apt policy openvswitch-switch
openvswitch-switch:
Installed: (none)
Candidate: 2.15.0+ds1-2
Version table:
2.15.0+ds1-2 990
990 http://ftp.be.debian.org/debian bullseye/main amd64 PackagesYes, I stated that exactly in my previous post. My initial question was referring to the fact that they have had that package in the pve-no-subscription repository in the past, and now they don't. Why the change? The latter part of my question applies to that previous situation where/when the package was in the pve-no-subscription, it's safe to assume that it was also available in the debian repository at the time. When this is the case, how would the package repo be chosen? I'm assuming it's a function of the logic in apt, perhaps just as simple as taken in order of repos listed in sources.list?
Last edited:
apt in that case chooses the higher version if the package name is the same. In the past, the PVE packages that were duplicated in the Debian repository all had newer/higher version numbers and "apt dist-upgrade" would check dependencies to pick the right ones. Personally, I set a preference for the PVE repositories to make it even more deterministic with:
Code:
# cat /etc/apt/preferences.d/10pverepo
# Always prefer packages from the Proxmox repository
Package: *
Pin: release o=Proxmox
Pin-Priority: 900Thus, for a PVE 6 cluster:
Code:
# apt policy openvswitch-switch
openvswitch-switch:
Installed: 2.12.3-1
Candidate: 2.12.3-1
Version table:
*** 2.12.3-1 900
900 http://download.proxmox.com/debian/pve buster/pve-no-subscription amd64 Packages
100 /var/lib/dpkg/status
2.12.0-1 900
900 http://download.proxmox.com/debian/pve buster/pve-no-subscription amd64 Packages
2.10.7+ds1-0+deb10u1 500
500 http://security.debian.org/debian-security buster/updates/main amd64 Packages
2.10.0+2018.08.28+git.8ca7c82b7d+ds1-12+deb10u2 500
500 http://deb.debian.org/debian buster/main amd64 PackagesHope that helps
If you have no special configuration in apt then the higher version number will be installed.
But there is no openvswitch package in the pve repo - so the debian repo will be choosen.
They changed this because they do not need special patches anymore or a higher version then provided in the debian repos
But there is no openvswitch package in the pve repo - so the debian repo will be choosen.
They changed this because they do not need special patches anymore or a higher version then provided in the debian repos
Great info and example. Thanks!
Thanks!
One last question? Why did PVE6 not need "auto <interface>" or "auto <vlan id", while PVE7 does? Was this a change in the OVS config defaults? I looked at my old PVE6 OVS working config and it didn't have any "auto" except for on the loopback interface.
It's needed by ifupdown2 package.
"allow ..." syntax was needed by ifupdown1 to correctly manage dependencies between ovs interfaces and startup order.
ifupdown2 can manage this nativelity, so simply use classic "auto .." syntax.
About ovs package, proxmox6 have his own version because previous debian version was too old for the proxmox kernel. Proxmox kernel is based on ubuntu kernel, so more recent then debian, and sometime ovs is too old. It's possible than in the future, if proxmox7 upgrade the kernel to next ubuntu lts, a newer openvswitch package will be include again in proxmox7 repo.