[PVE-User] Prevent tap interfaces from being added to OVS bridge automatically

[Josh Knight]

Hello all,

Is there a way to have a VM network interface setup in bridge mode so that
it still has the unique tap interfaces on the host, but does not become
automatically added to the selected network bridge?

My use case is that I'm using OVS and using scripts/automation via the
ovs-vsctl command to setup different network topologies to each VM (for
example, bonding two of the tap interfaces.) As a result, if the VM is
manually stopped/started from the UI, the removing/adding of the tap
interfaces to the OVS bridge can conflict with the custom OVS
configuration, and in some cases prevent the VM from starting.

For example, if I have tap107i2 and tap107i3 bonded

Bridge "vmbr2"
Port "bond69"
trunks: [696]
Interface "tap107i3"
Interface "tap107i2"

When the VM is stopped

Bridge "vmbr2"
Port "bond69"
trunks: [696]
Interface "tap107i3"
error: "could not open network device tap107i3 (No such
device)"
Interface "tap107i2"
error: "could not open network device tap107i2 (No such
device)"

Attempting to start the VM results in the following error:
ovs-vsctl: cannot create a port named tap107i2 because an interface named
tap107i2 already exists on bridge vmbr2

If I use ovs-vsctl find Interface name=tap107i2 and i3, I can see that the
interfaces are still present in the database. As soon as I delete that
bond69 interface, I can start the VM successfully.

These VMs are used for testing various NFV applications, so while I realize
it may not make total sense to bond two virtual interfaces and run LACP,
it's just a function of the testing environment that these systems are in.
We have enough automation around setting the networking up that we don't
actually need proxmox to automatically add the tap interfaces to the bridge
for us. Any suggestions would be appreciated!

Thanks,
Josh

[Josh Knight]

One workaround I've thought of is to have all VMs start out on a "staging"
bridge, vmbr3, where the proxmox ui config would never conflict with
anything custom. Then as a part of our automated setup script, it would
remove the ports from vmbr3 and add to vmbr2 and then do its custom network
configuration. The downside is that stopping/starting a VM would break the
network setup, however it would at least allow the VM to always start. Then
the user just reruns the network setup script to fix it.

But ideally not having it on any bridge to start out with would be great.

Josh

Post by Josh Knight
Hello all,
Is there a way to have a VM network interface setup in bridge mode so that
it still has the unique tap interfaces on the host, but does not become
automatically added to the selected network bridge?
My use case is that I'm using OVS and using scripts/automation via the
ovs-vsctl command to setup different network topologies to each VM (for
example, bonding two of the tap interfaces.) As a result, if the VM is
manually stopped/started from the UI, the removing/adding of the tap
interfaces to the OVS bridge can conflict with the custom OVS
configuration, and in some cases prevent the VM from starting.
For example, if I have tap107i2 and tap107i3 bonded
Bridge "vmbr2"
Port "bond69"
trunks: [696]
Interface "tap107i3"
Interface "tap107i2"
When the VM is stopped
Bridge "vmbr2"
Port "bond69"
trunks: [696]
Interface "tap107i3"
error: "could not open network device tap107i3 (No such
device)"
Interface "tap107i2"
error: "could not open network device tap107i2 (No such
device)"
ovs-vsctl: cannot create a port named tap107i2 because an interface named
tap107i2 already exists on bridge vmbr2
If I use ovs-vsctl find Interface name=tap107i2 and i3, I can see that the
interfaces are still present in the database. As soon as I delete that
bond69 interface, I can start the VM successfully.
These VMs are used for testing various NFV applications, so while I
realize it may not make total sense to bond two virtual interfaces and run
LACP, it's just a function of the testing environment that these systems
are in. We have enough automation around setting the networking up that we
don't actually need proxmox to automatically add the tap interfaces to the
bridge for us. Any suggestions would be appreciated!
Thanks,
Josh