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:
- Create a Workload VPN and one or more bridged subnets within it using the Fabric Services System intent-based REST API or UI.
- Obtain the UUIDs of these resources.
For this example, the Workload VPN has the name
VMware Workload
and UUID410559942890618880
and the subnet within it has the nameVMware Subnet
and UUID410560233203564544
. - In VMware:
- Create a dvSwitch.
- Two options are available to specify a custom attribute on the dvSwitch:
- 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.
- 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.
- 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.
- Create a dvPortGroup.
- Two options are available to specify a custom attribute on the
dvPortgroup:
- 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
. - 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
.
- Specify a custom attribute "FSSSubnetID" on that dvPortGroup and set
it to the UUID of the operator-precreated subnet in the Fabric
Services System.
You can define both the name and the UUID as custom attributes, but in this case the UUID takes precedence, and the name is ignored. The name is used only when the UUID is not set (or is set to 'none').
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.
Configuring the FSSWorkloadEVPNID or FSSWorkloadEVPNName custom attribute at the dvPortGroup level
You can define the FSSWorkloadEVPNID or FSSWorkloadEVPNName as a custom attribute at the PortGroup level instead of the dvSwitch level. In this case, the value at the dvPortGroup level is prioritized over what is configured on the dvSwitch.
This configuration allows for different PortGroups to be associated with subnets on different Workload Intents.
Alarms
If a value is set on any of these attributes for which no corresponding Fabric Services System subnet or Workload exists, an alarm is be raised. The alarm message details which custom attribute has the incorrect value and on which DVS or DVPG the incorrect value is defined. Correcting the value resolves the issue, but does 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.