The new vSphere+/vSAN+ cloud service is now generally available for all customers! For those interested, I recently wrote about my first experience using the new vSphere+vSAN+ service with my vSphere Homelab environment, which I will also be updating based on the generally available service.
In addition to the resources above and in the VMC Cloud Console, here is a link to the official vSphere+/vSAN+ documentation including pre-req.
During my initial deployment of the vCenter Cloud Gateway (VCGW) used by the vSphere+/vSAN+ service, I did not run into any issues but upon deploying my second VCGW for a different environment, I ran into some networking issues. After a bit of debugging, I came to learn that the VCGW application and services are composed of various Docker containers and there was a network conflict with the default Docker Bridge Network that the VCGW has been configured by default with.
The VCGW uses 172.17.0.1/16 for its Docker Bridge Network and this actually overlaps with my existing network where my on-premises vSphere environment. One symptom of this issue is that when attempting to register and connect VCGW with the VMC Cloud Console, you will notice the progress bar is stuck at exactly 50% during the "Retrieving Packages".
Step 1 - If you have deployed the VCGW and attempted the registration, you will need to delete the deployment and redeploy. I have found that even updating the settings after the registration process has begun still runs into some other issue.
Step 2 - Before attempting to access the VAMI interface (https://FQDN:5480), SSH to VCGW using the root credentials that you had used during the deployment. Once you are logged in, go ahead and type "shell" to change into the Bash Shell
Step 3 - Edit the Docker configuration file /etc/docker/daemon.json and change the BIP address to another network which does not conflict (e.g. 184.108.40.206/16) and then save the changes
Step 4 - Lastly, reboot the VCGW for the changes to go into effect and once it is available, you can now proceed with the setup.
I have already shared this issue and feedback with our Engineering team and this experience should hopefully be improved in the future and better accommodate Docker Bridge Network changes to avoid network conflicts.