VMware Cloud Foundation 3.5 Nested Deployment – Part 2

VMware Cloud Foundation 3.5 Nested Deployment – Part 2

vCF deployment preparation

In the last article I described how I prepared my underlying infrastructure for the deployment of vCF. This one details the preparation steps required to deploy vCF.

Before starting the deployment process, following tasks are required:

  1. Download Deployment VM (I used version 3.5 – vcf-cloudbuild-3.5.0.0-11215871_OVF10.ova)
  2. Download Deployment Parameter Sheet (vcf-ems-deployment-parameter_3.5.xlsx)
  3. Complete Deployment Parameter Sheet

A couple of details on the parameter sheet:

  • I used VLAN 0 for all the networks of the nested environment. Although this is far from best practices, it does not create any issue with the deployment of the solution. Nevertheless, I only wanted to test the deployment of vCF and not keep it running for long.
VLAN # Portgroup Name CIDR Notation Gateway MTU
0 SDDC-DPortGroup-Mgmt 10.0.1.0/24 10.0.1.1 1500
0 SDDC-DPortGroup-vMotion 10.0.1.0/24 10.0.1.1 6000
0 SDDC-DPortGroup-VSAN 10.0.1.0/24 10.0.1.1 6000
0 VXLAN (VTEP) – DHCP Network n/a n/a 9000
  • I chose a different MTU size for vMotion and vSAN due to a known issue when the vDS and Portgroup were both set to 9000. First deployments failed initially. See Known Issues in the Release Notes for more details.
  • The password validation for the NSX Controller VM is not taking into account the minimal password length. Take care to use a longer password than for the rest (e.g. “VMware12345!”)
  • Ensure to add the license keys as they will be validated later in the bring-up process.

 

Deploy the Cloudbuilder VM

Deploying the Cloudbuilder VM is pretty straightforward, since it’s nothing else than a default OVA deployment.

  • Connect to the existing vCenter Server
  • Deploy the OVA file and connect it to the same Portgroup to be used later for the rest of the deployment.

    During the deployment of the OVA, set the password for the VM, IP address, Subnet, Gateway, NTP server etc.
    Use the same IP Subnet as for the management network of the nested environment.

This can take some time to complete, as the OVA file is around 9GB large.

vCF deployment (Bring-up process) 

The bring-up process needs the Deployment Parameter XLS Spreadsheet as input file, converts it to .json internally, validates the entered values, and then deploys and configures the SDDC stack.

Following process describes how I deployed vCF in my lab:

  • Once the Cloudbuilder VM is up and running, connect to it using a web browser on following URL: https://Cloudbuilder-IP:8008
  • Log in using the credentials provided during the OVA deployment process.
  • Validate the checklist by checking the tickbox at the bottom left side of the screen.

 

  • Agree to the EULA.

  • Upload the Deployment Parameter Sheet.

  • Validate the configuration file.

  • Wait for the validation to complete.

  • In case of an issue, correct the problematic setting and hit retry. My network settings did not validate due to a known issue around MTU, but the deployment worked. I had to acknowledge the issue before being able to click “Next”.

  • Start the bring-up process.

  • Wait for the bring-up to complete.

  • If there are issues during the deployment, the process will stop at the failed task. Once the issue is solved, it can be retried and the process will continue normally.

 

Learnings and issues

The first thing I learned was that the error checking in the Excel Spreadsheet was not 100% accurate. Sometimes the subnets I entered turned red, even though they were correctly defined. After adding a licence code, which unfortunately contained a space, I was unable to edit the cell again. These were minor issues, and overall the file works fine.

During the bring-up process, I experienced two main issues, which I had to solve before I could continue:

  • The migration the VMKernel interfaces for management of two hosts from the vSwitch to the vDS failed constantly. This was due to the nested environment. On one host I could solve the issue by simply rebooting it, and changing portgroup of the nested ESXi host and switching it back again.
    This procedure did not work on the second host. (Note that this happened in two distinct vCF deployments). To work around the issue, I created a new VMKernel interface on the vDS, then turned on Management on the new VMK. I then removed the original VMK0 interface and created a new VMK0 on the vDS. Then I could enable management on the new VMK0 interface again and delete the temporary VMKernel interface.
    To not loose connectivity between the host and vCenter, I temporarily changed the DNS entry on the DNS server, and flushed the DNS cache on the vCenter appliance with following command: systemctl restart dnsmasq
    After solving this issue, the task completed successfully and the bring-up process continued.
  • The deployment of the LogInsight VMs failed multiple times. The first VM deployed and booted up, then the second VM, but the third VM did not get created on the nested host. I do not go into the details of the troubleshooting, but in the end I had to reboot all 4 hosts before this task could finally complete. I am sure that this problem is also related to the nature of the nested environment.

 

Conclusion

This article described the process I used to deploy vCF 3.5 successfully in a nested environment.
I hope by sharing it, I can help some people to get it done, too.
The next article will take it from here and describe the first post-installation tasks in SDDC Manager.

 

Other articles in this series:

VMware Cloud Foundation 3.5 Nested Deployment – Part 1
VMware Cloud Foundation 3.5 Nested Deployment – Part 2

 

Leave a Comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.