In Part 3 of this series, we will be taking a look at deploying our Nested Lab in a Google Cloud VMware Engine environment. One thing you may notice that is different between VMConAWS and AVS is that we are actually running a Nested vSAN on top of the physical vSAN within GCVE. In the current version of GCVE, customers have the ability to "escalate" their privileges from the default and this would allow us to configure the necessary ESXi advanced setting so that we do not have to rely on an NFS setup. For networking, customers also have full access to the NSX-T Manager instance and this means that MAC Learning can be enabled which will allow inner-guest workloads will be able to communicate properly within and outside of the Nested Lab deployment.
Disclaimer: Nested ESXi is not officially supported on Google Cloud VMware Engine or by VMware.
Pre-Requirements:
- 3-Node SDDC already deployed
- Bastion / Jumphost which has network connectivity to the SDDC Management network. In my setup, a Windows Server VM was deployed using Google Compute service which also provided a local DNS server for my nested environment. You will need to ensure you have configured access from the Windows VM to your SDDC
- PowerCLI 12.x installed on the Bastion/Jumphost
- Download the desired version of OVAs (vCenter Server Appliance (VCSA) and Nested ESXi Appliance)
Step 1 - In the GCVE service, locate your SDDC and click on Resources on the left hand navigation and at the very bottom of the Summary tab, click on Elevate.
Step 2 - You can accept all the defaults for changing the vSphere privileges and check the box and confirm.
You should see a message like the following which has confirmed the privilege escalation for 1hr, which is more than enough for our change.
Step 3 - Login to your SDDC vCenter Server. If you were logged in before, you will need to log back out for the permission update to take effect. Navigate to Menu->Administration->Roles and select the CloudAdmin role. We need to add one additional vSphere Privilege under Host->Configuration->Advanced settings which will allow us to update the required ESXi Advanced Setting to allow for Nested vSAN to run on top of our physical vSAN datastore.
Step 4 - To change the ESXi Advanced Setting across all ESXi hosts, the easiest method is to use PowerCLI and by running the following command:
Get-Cluster -Name "Cluster" | Get-VMHost | Get-AdvancedSetting -Name "VSAN.FakeSCSIReservations" | Set-AdvancedSetting -Value 1 -Confirm:$false
Step 5 - Next, login to NSX-T Manager with admin and the credentials that was configured when creating the SDDC. Under Networking, select Segment Profiles and create a new Segment Profile called Nested with the MAC Learning feature enabled.
Step 6 - Under Segments, either select an existing or create a new NSX-T Segment with the desired network configurations and make sure to select our custom Nested for MAC Discovery section while leaving the defaults for the other profiles.
After saving the NSX-T Segment changes, you are now ready to begin the deployment.
Step 7 - Download the nested-sddc-lab-deployment.ps1 script and transfer that and the OVAs to the Bastion/Jumphost.
Step 8 - Update the script (details can be found on the Github repo) that reflects your environment. For those who have used my previous Automated Nested Lab Deployment scripts, this should feel very simliar. The only key difference is specifying the SDDC Provider ID which the script will properly handle the uniqueness for each respective VMware Cloud SDDC environment.
Step 9 - Once you have saved your changes, you can execute the script and a summary output as shown in the screenshot below will be provided prior to actually starting the deployment.
If everything was setup correctly, the script will take ~22minutes to deploy a fully configured VCSA with 3 x ESXi VM (default) and attached to our NFS VM to provide shared storage across the ESXi hosts.
If you have DNS configured and enabled in the script, you can then connect to your VCSA instance using the various CLI/API or the vSphere UI of the FQDN that you had specified for the VCSA. If not, then you would connect using the IP Address. You will notice that all VMs deployed as part of the script will be placed inside of a vApp construct.
Stay tuned for the final part of this blog series which I will be covering Oracle Cloud VMware Solution.
- Automated Nested Lab Deployment on SDDC Part 1: VMware Cloud on AWS
- Automated Nested Lab Deployment on SDDC Part 2: Azure VMware Solution
- Automated Nested Lab Deployment on SDDC Part 3: Google Cloud VMware Engine
- Automated Nested Lab Deployment on SDDC Part 4: Oracle Cloud VMware Solution
Thank you for taking your time to prepare such an extensive article. Many things cannot be put into three sentences. Professional approach counts. Regards