VCF

VMware just announced VMSA-2023-0023 with a maximum CVSSv3 base score of 9.8 - which basically implies DANGER! Here is everything you need to know about this for your VCF Environments.

VMSA-2023-0023 includes two CVEs: CVE-2023-34048, CVE-2023-34056 - The severity of these issues has been evaluated to be in the Critical severity range with a maximum CVSSv3 base score of 9.8.

This VMSA affects all versions of vCenter Server, and is only limited to vCenter, not ESXi.

Given the close integration of the SDDC Manager with all the components comprising a VCF Environment, making changes to components can be a bit of a challenge. In this article, lets talk about one of the more simpler changes - Renaming components.

As a rule, making changes to any object or component that is a part of a VCF Environment should only be done through the SDDC Manager. Making changes directly on the component itself is UNSUPPORTED - as SDDC Manager will not have visibility over this change, thereby causing a discrepancy in the inventory information.

While the changes should only be made through the SDDC Manager, there is no mechanism or workflow in place that restricts one from making the changes directly via the component itself. However, as mentioned above, the change still is unsupported. If any changes are made which cause a deviation from the inventory information that the SDDC Manager holds, this can (and will) cause issues with any number of Day-2 operations and workflows (such as adding hosts and WLDs, updates/upgrades, expanding clusters)

In terms of actually renaming components in a VCF Environment, as of VCF 4.5, here are the following components that support renaming:

Since the release of VCF 4.4.0.0, there has been a lot of chatter about how we can decouple or disassociate the vRealize suite from VCF and SDDC Manager, or how it is completely externally managed.
This is quite incorrect and stems from a misunderstanding of how the vRealize Suite is linked to VCF.

In this post, I will talk about how the vRealize Suite is linked to VCF and SDDC manager, and what has changed in VCF 4.4 and above.

During upgrades of VCF components from the SDDC Manager, we often run into situations where a component upgrade bundle does not show up for a particular VCF version upgrade. This can also present itself as skipping a component through the upgrade process. In this article, I will explain what compatibility sets are, how they work, and how they affect the VCF component upgrade process.

What are Compatibility Sets?

Compatibility sets are set of version entries for the 3 primary core VCF products - namely vCenter, ESXi and NSX(T/V), which are marked as compatible with one another. Lets break it down further.

Each entry in the compatibility sets contains one version each for the vCenter, ESXi and NSX component.

For example, from the screenshot above, the final entry indicates that vCenter version 7.0.3.00300, ESXi version 7.0.3, and NSX-T version 3.1.3.7.4 are basically marked as compatible to work with each other in a VCF environment.

The VerionAlias.yml file on a SDDC Manager is referenced quite a bit across several VMware KBs, mostly in the context of "change this value here" or "add this value there" while troubleshooting VCF upgrades. There really aren't any articles online describing what this file really means or how it works. In this post, I will describe the various elements that are in a VersionAlias.yml file, and how to interpret the information available here.

Lets start with the different versions of each VCF component that we are dealing with: