search

xapi-project / xcp-networkd

The XCP networking daemon
Other
14 stars 42 forks source link

CA-311211: Fix destroy_existing_vlan_bridge when enic workaround is e… #157

Closed robhoes closed 5 years ago

robhoes commented 5 years ago

…nabled

The function destroy_existing_vlan_bridge is called from Bridge.create if the bridge to be created is for a VLAN. The purpose is to get rid of any existing bridge for the same VLAN but with a different name. This was not working properly if case the enic workaround is in place, and the Linux bridge backend is used.

The main use of this is installing a host with the management interface on a VLAN, where early in the host boot process, xcp-networkd creates a temporary bridge for the VLAN, called xentemp. This is because xcp-networkd does not yet know the final name of the VLAN bridge, which is determined later by xapi. When firstboot scripts run, a VLAN is created through xapi, with a new bridge name that is meant to replace the xentemp bridge.

For example, for VLAN 123, the output of brctl show would be like this after xcp-network has started:

bridge name        bridge id                STP enabled       interfaces
xenbr0             8000.0cc47ae6872c        no                eth0
xentemp            8000.0cc47ae6872d        no                eth0.123

The desired state after the firstboot scripts run is:

bridge name        bridge id                STP enabled       interfaces
xenbr0             8000.0cc47ae6872c        no                eth0
xapi0              8000.0cc47ae6872d        no                eth0.123

Now, the problem occurred when running on a Cisco UCS host, with the "enic workaround" enabled. What happens then, is that not the eth0, but a VLAN0 device eth0.0 is added to the "parent" bridge xenbr0:

bridge name        bridge id                STP enabled       interfaces
xenbr0             8000.0cc47ae6872c        no                eth0.0
xentemp            8000.0cc47ae6872d        no                eth0.123

The function destroy_existing_vlan_bridge did not take this into account. It is fixed by push the call to this function further down into Bridge.create, below the point where the enic workaround has been dealt with. It turned out easier to split the function into separate OVS and Linux bridge versions.

Signed-off-by: Rob Hoes rob.hoes@citrix.com

robhoes commented 5 years ago

Hint: it is best to review the diff with whitespace suppressed.