If you are running a VMware environment with multiple vCenters in Enhanced Linked Mode, then chances are, you have inevitably taken snapshots of vCenters and caused a replication issue due to the vmdir DBs being out of sync. In previous posts, I have talked about how this replication works, and how to not break this replication.

In this post, I will explain the quickest way to repair and recover from a broken replication state and bring all the vCenters back in sync.

VMware GSS has multiple internal scripts and KBs to repair the vmdir DB replication in place. However, there is a publicly accessible utility that also lets us repair the replication. Its called cross-domain repoint.

https://blogs.vmware.com/vsphere/2019/10/repointing-vcenter-server-to-another-sso-domain.html

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:

A recent post from VMware talked about a new malware for ESXi, based on information published by Mandiant - which is a cyber-security firm (a subsidiary of Google). You can read the VMware KB here.

The full posts from Mandiant can be found here:
https://www.mandiant.com/resources/blog/esxi-hypervisors-malware-persistence
https://www.mandiant.com/resources/blog/esxi-hypervisors-detection-hardening

In this post, I am going to discuss the key aspects of this issue.

What are Mandiant's findings?

Mandiant found malware on ESXi hosts that was basically installed using unsigned VIBs. The unsigned VIBs contain backdoors which then compromise the ESXi host. At that point, anything on the host can be considered as compromised - commands can be sent for execution on Guest VMs, files can be transferred between ESXi and the Guest VMs etc.

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.