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

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

  • In VMware:
    1. Create a dvSwitch.
    2. Two options are available to specify a custom attribute on the dvSwitch:
      1. 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.

      2. Specify a custom attribute "FSSWorkloadEVPNName" on that dvSwitch, and set it to the name of the previously created Workload VPN in the Fabric Services System.

        In our example, that would be VMware Workload.

    3. Create a dvPortGroup.
    4. Two options are available to specify a custom attribute on the dvPortgroup:
      1. 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.

      2. Specify a custom attribute "FSSSubnetName" on that dvPortGroup and set it to the name of the operator-precreated subnet in the Fabric Services System.

        In this example, that would be VMware Subnet.

It is possible to define both the name and the UUID as custom attributes, but in this case the UUID will take precedence and the name will be ignored. Only when the UUID is not set (or set to 'none') will the name be used.

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.

Alarms

If a value is set on any of these attributes for which no corresponding Fabric Services System Subnet or Workload exists, an alarm will be raised. The alarm message will detail which custom attribute has the incorrect value and on which DVS or DVPG the incorrect value is defined. Correcting the value will resolve the issue, but will not automatically clear the alarm. The alarm is cleared when the plugin is audited.

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.