Update: The manually created TNP issue has been resolved in VCF v. 3.10 and users are recommended to update to that version. Patch however is still available through GSS for v 3.9 users.
If you’re anything like me, you like to rename most objects whether its default user names, port groups, datastores, etc., in order to easily decipher what the object is and what it is its doing. For me, it keeps the environment clean and readable. On the plus side, if something were to happen to me, anyone should be able to log into the environment behind me and retrace my steps. This is great, unless we’re talking about VCF. Specifically version 3.9 and above. Reason being is that while it encompasses products you can procure a la carte and deploy them the way you want, VCF expects them to be deployed in its own specific way.
This can be seen by taking a look at an example of a VI WLDs Transport Node Profiles (TNP):
The first section we’ll take a look at are the names of the profiles above. It’s obvious based on the name, how these TNP were applied. Although depending on the Workload Domain and Cluster name this may not be the case. The TNP is created automatically when a VI WLD is created and renaming or creating new ones after the fact will break LifeCycle Management and resource scaling. Which means patching the environment, adding/removing a host, and/or adding a new cluster will result in the process failing. Resolving this issue if the TNP does end up being renamed is a simple process once the naming convention is understood.
As mentioned, the expected naming format is:
<VI WLD Name>-<Cluster Name>-<Random 32 character UUID string>
The UUID string must follow a specific format which consists of the following:
<xxxxxxxx>-<xxxx>-<xxxx>-<xxxx>-<xxxxxxxxxxxx>
A tool I used to create the UUID string can be found here: uuidgenerator.net
With this naming convention, the name of the vCenter (not shown in the screenshot) must also be in the description of each TNP. The reason for the specific naming method is due to the way SDDC Manager manages the entire VCF environment which could include up to 15 Workload Domains & 64 host clusters within a Workload Domain. In order for SDDC Manager to keep track of these environments and make sure to not have any duplicates in the environment.
The resolution is pretty simple and constitutes renaming the modified Transport Node Profiles so that they match the expected format and description. The UUID string is random and does not have to match the previous string. It just can’t match another TNP’s UUID. Restarting SDDC Manager is required but recommended.
Second item I wanted to cover is regarding manually created Transport Zones. This only affects VCF 3.9.x and has been documented within VMware kb 77195. The reason I wanted to mention it is because this issue isn’t documented very well and something that could trip users up very easily. If a Transport Zone (TZ) is manually created, the validation checks that SDDC Manager does with the Workload Domains will fail which will break any Domain operations. This can only be resolved by a patch provided and deployed by VMware support. I have not tested 4.x or 3.10 versions and this issue has not been confirmed (with these versions) by VMware either.