New Member
May 12, 2023

I would like to know how the ifupdown2 and OvS implementation in proxmox works because on a VM of my pve, I have a trunk that comes from the OvS of my PVE but when the VM is restarted the OvS service requires a restart for the flows to work whereas when I restart the pve it works directly.

I tried to compile from the proxmox sources the slightly different version from the debian ifupdown2 repositories but same result. Concerning OvS on my pve and on the VM, both packages come from the debian repository.

# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

source /etc/network/interfaces.d/*

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
allow-hotplug ens18
iface ens18 inet static

auto vmbr0
iface vmbr0 inet manual
         ovs_type OVSBridge
        ovs_ports ens19
          ovs_extra set port vmbr0 tag=3

auto ens19
iface ens19 inet manual
        ovs_bridge vmbr0
        ovs_type OVSPort




  • vm2sys.log
    16.1 KB · Views: 3
Last edited:
I feel like I'm in this situation (see after), but even without using ifupdown2, the OvS service requires a reboot after boot to work.

Notes on dependencies:

openvswitch-switch depends on $network, $named $remote_fs and $syslog to start.
This creates some startup dependency issues.

* Since openvswitch utilities are placed in /usr and /usr can be mounted
through NFS, openvswitch has to start after it. But if a user uses openvswitch
for all his networking needs and hence to mount NFS, there will be a deadlock.
So, if /usr is mounted through NFS and openvswitch is used for all networking,
the administrator should figure out a way to mount NFS before starting OVS.
One way to do this is in initramfs.

* Since openvswitch starts after $network, $remote_fs and $syslog, any startup
script that depends on openvswitch but starts before it, needs to be changed
to depend on openvswitch-switch too.

* Ideally, an admin should not add openvswitch bridges in the 'auto'
section of the 'interfaces' file (i.e., if "br0" is a OVS bridge, you should
not have a line "auto br0"). This is because, when ifupdown starts
working on bridges listed in 'auto', openvswitch has not yet started.

But, if the admin wants to go down this route and adds openvswitch bridges
in the 'auto' section, openvswitch-switch will forcefully be started when
ifupdown kicks in. In a case like this, the admin needs to make sure that /usr
has already been mounted and that a remote $syslog (if used) is ready to
receive openvswitch logs.

* With systemd, adding openvswitch bridges in the 'auto' section of the
'interfaces' file can cause race conditions (i.e., if "br0" is a OVS bridge,
you should not have a line "auto br0"). Debian systems have added a
systemd ifup@.service file. This file will call ifdown and ifup on interfaces
in "auto" section automatically when the interfaces disappear and appear
respectively. This will cause race conditions if you delete and add the same
bridges using tools like "ovs-vsctl" or "ovs-dpctl". This is also a problem
when you upgrade your openvswitch kernel module using commands like


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!