Usage

VMware usage for VMware managed networks

The VMware plugin acts on the operator actions in vSphere by listening in on the vCenter event bus. The standard VMware method of creating networks is supported by the VMware plugin for Connect:

  • Create dvSwitches
  • Add uplinks
  • Create dvPortGroups

In the standard VMware managed networks model, all Fabric Services System subnets are created within a single Fabric Services System Workload VPN, which represents one particular vSphere deployment. Within Connect, when inspected using the API, this corresponds to a single tenant.

VMware Usage for Fabric Services System managed networks

In addition to the VMware managed networking model, Connect supports advanced Fabric Services System managed networking. In this model, Workload VPN and subnet resources are first created directly in the Fabric Services System and are then consumed in VMware.

To support this model, Connect uses custom attributes in vSphere.

The management flow is :

  • In the Fabric Services System:
    1. Create a Workload VPN and one or more bridged subnets within it using the Fabric Services System intent-based REST API or UI.
    2. Obtain the UUIDs of these resource.

    For this example, we will assume that the Workload VPN has the UUID 410559942890618880 and the subnet within it has the UUID 410560233203564544.

  • In VMware:
    1. Create a dvSwitch.
    2. Specify a custom attribute "FSSWorkloadEVPNID" on that dvSwitch, and set it to the UUID of the previously created Workload VPN in the Fabric Services System.

      In our example, that would be 410559942890618880.

    3. Create a dvPortGroup.
    4. Specify a custom attribute FSSSubnetID on that dvPortGroup and set it to the UUID of the operator-precreated subnet in the Fabric Services System.

      In this example, that would be 410560233203564544.

From here, all standard VMware operations continue.

You can undo the Fabric Services System managed characteristic of a dvSwitch or dvPortGroup by re-defining the custom attributes to the value None. The value is not case sensitive.

Note: During step 3, you will see a temporary, new, and identical subnet being created within the previously created Workload VPN. This is because during step 3, a VMware managed subnet is created under a Fabric Services System managed Workload VPN. If the scenario were to stop at step 3, this would be the intended state. When performing step 4 however, this temporary subnet is deleted, and only the operator created subnet remains.

Fabric Services System managed dvSwitches with VMware managed dvPortGroups

A particular case exists for a Fabric Services System managed networks in which the dvSwitch in VMware is managed by the Fabric Services System, but the dvPortGroups remain managed by VMware.

The opposite model does not exist; there is no support for a Fabric Services System managed dvPortGroups within VMware managed dvSwitches.