This is a multi-part blog series on some of the frequently asked questions and scenarios for the vSphere+, vSAN+ and VCF+ Cloud Services. What started out as a single blog post that attempted to summarize some of the learnings and notes that I have made while answering various questions from our field and customers for vSphere+, vSAN+ and VCF+ quickly turned into a 3K+ word blog post and counting! 😅
While I thought it would be easier from a search perspective to have everything in a single blog post, I decided to take the advice from the community and actually break it up into small blogs which would be part of a large multi-part blog series, in no particular order but I recommend reading it in the following logical order as shown below:
- Frequently asked scenarios about vCenter Cloud Gateway (VCGW) for vSphere+, vSAN+ and VCF+ (THIS BLOG POST)
- Frequently asked scenarios about vCenter Lifecycle Management for vSphere+, vSAN+ and VCF+
- Frequently asked scenarios about vCenter Desired State Configuration for vSphere+, vSAN+ and VCF+
- Frequently asked scenarios about VM Provisioning & Management for vSphere+, vSAN+ and VCF+
- Frequently asked scenarios about Cloud Consumption Interface (CCI) for vSphere+, vSAN+ and VCF+
- Frequently asked scenarios about Global Inventory for vSphere+, vSAN+ and VCF+
- Frequently asked scenarios about Subscription & Entitlement for vSphere+, vSAN+ and VCF+
vCenter Cloud Gateway
After connecting your vCenter Cloud Gateway (VCGW) to your VMware Cloud (VMC) Organization, the next step is to register your on-premises vCenter Server(s) and/or SDDC Manager(s) to the VCGW. To help illustrate the various deployment scenarios, I have created the following diagram below to help explain the different supported configurations and behaviors.
vCenter Registration
The first important concept to understand is that a single VCGW can support up to a maximum of 8 registered vCenter Server(s). Once the maximum vCenter Server registration has been reached, the VCGW will prevent you from registering additional vCenter Server(s) and a new VCGW will need be deployed. There are no maximums on the number of VCGW that can be deployed and registred to VMC Organization.
vCenter Server(s) that are configured in an Enhanced Linked Mode (ELM) is fully supported with the vSphere+/vSAN+ Cloud Service. From a registration maximum standpoint, the VCGW treats an ELM configured vCenter Server exactly like a standalone vCenter Server and supports up to a maximum of 8 registered vCenter Server(s). Today, there is no special handling of vCenter Server(s) configured in an ELM and each vCenter Server within the ELM must be manually registered to the VCGW.
VCF Registration
For VCF, the behavior is slightly different as you are registering a VCF Instance (SDDC Manager) to the VCGW instead of the individual vCenter Server(s) from your VCF Management and Workload Domain. With that said, the VCGW still only supports up to a maximum of 8 registered vCenter Server(s), however that is completely transparent to the end user. Once an SDDC Manager has been registred with the VCGW, the option to register a standalone or ELM-configured vCenter Server will no longer be available. If you need to register a non-VCF vCenter Server, you will need to deploy a separate VCGW. Furthermore, the registered SDDC Manager will also be updated to prevent users from deploying more than 7 Workload Domains in total as that would exceed the maximum number of registered vCenter Server for that VCGW.
A really nice benefit to the VCF workflow is that as you additional Workload Domains are added, the VCGW will automatically add the Workload Domains to the VMware Cloud Console and convert them to subscription without requiring additional user interactions. For non-VCF workflow, as new vCenter Server(s) are deployed, you will need to manually register them to the VCGW and then convert each one of them to subscription using the VMware Cloud Console.
VCGW Lifecycle
Once a VCGW is deployed, it is managed 100% by VMware including patching and upgrading. The VCGW is a stateless system, so it can go away or get redeployed at any time and all registered endpoints will automatically get reconcile when they are re-connected with the new VCGW(s). From an operational standpoint, there are no additional tasks that is required of the user once the VCGW has been setup.
If your VCGW loses connectivity to the VMC Console, your vCenter Server(s) and SDDC Manager(s) and more importantly your workloads continue to run without any issues. In earlier releases, if the VCGW lost connectivity, when you go to login to the vSphere UI or SDDC Manager UI, you might see the following error message and you would need to use the emergency URL, which you can learn more about by clicking on the "Still having connection problems?" link which points to VMware KB 83798.
Initially, the duration when VMware would declare an issue with the VCGW is 24hrs before you would see this message when logging into the vSphere or SDDC Manager UI. This has been now changed to 7 days and if connectivity has been restored before the 7th day, the time will reset. Hopefully with this new change in behavior, it provides users sufficient time to restore connectivity back to the VCGW. Just to be clear, you ALWAYS will be able to login to your local vCenter Server and SDDC Manager, the message you see above is purely to let users know that there is a connectivity issue between the VCGW and the VMware Cloud Service, which users should resolve as quickly as possible.
Here are some additional resources related to vCenter Cloud Gateway that might be of interests:
- vCenter Cloud Gateway Requirements
- How to audit vCenter Cloud Gateway & vCenter Server Registrations for vSphere+
- Finding vCenter Cloud Gateway Deployments in your environment
Thanks for the comment!