GaMMachiPo

New Member
May 12, 2023
4
0
1
Swiss
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.

Code:
# 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


1690622486340.png

Regards
 

Attachments

  • 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.

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'.
 

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 your own in 60 seconds.

Buy now!