In Part 2 of this series, we will be taking a look at deploying our Nested Lab in an Azure VMware Solution environment. Simliar to VMConAWS, we will need to deploy our NFS Photon OS OVA because administrative access to the physical ESXi hosts is not available. This is required to enable an advanced ESXi setting to be able to run Nested vSAN on top of the physical vSAN. From a networking standpoint, customers do 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 Azure VMware Solution or by VMware.
- 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 the Azure Virtual Machine 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 the VNet connected to your SDDC
- PowerCLI 12.x installed on the Bastion/Jumphost
- Download the desired version of OVAs (vCenter Server Appliance (VCSA), Nested ESXi Appliance and NFS PhotonOS OVA)
Step 1 - Retrieve the NSX-T Manager URL and credentials by navigating to your SDDC and select Identity on left hand navigation. We will need this information so that we can enable MAC Learning for the NSX-T Segment.
Note: Trevor Davis from Microsoft has also published a Microsoft Tech Community post which outlines the steps for enabling MAC Learning in greater detail for those interested.
Step 2 - On the Jumphost, open a browser and login to the NSX-T Manager. Under Networking, select Segment Profiles and create a new Segment Profile called NestedMacProfile with the MAC Learning feature enabled.
Step 3 - 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 NestedMacProfile for MAC Discovery section while leaving the defaults for the other profiles.
Step 4 - Download the nested-sddc-lab-deployment.ps1 script and transfer that and the OVAs to the Bastion/Jumphost.
Step 5 - 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 6 - 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 3 and 4 of this blog series which I will be covering the remainder VMware Cloud SDDC solutions.
- 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