How work OvS with ifupdown2 in proxmox

[GaMMachiPo]

Hello,

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
  address 10.0.0.2/18
  gateway 10.0.0.1

auto vmbr0
iface vmbr0 inet manual
        address 10.0.64.10/18
         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

Regards

 

[GaMMachiPo]

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.

https://raw.githubusercontent.com/openvswitch/ovs/master/debian/openvswitch-switch.README.Debian

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
'force-reload-kmod'.