In this post, I’ll go over a few tips/tricks that you may use throughout your VCF lab deployment to get the most out of this fantastic tool.
Tip 1: Bring down lab resource utilization
Most of us, I believe, use VCF as a nested lab, and because VCF requires a lot of computing power, this is one area that we struggle with. Because of the limited resources available, a full-fledged deployment is not always practicable. NSX-T nodes, in my experience, are the most problematic component. VCF deploys several NSX-T nodes and each NSX-T requires a lot of resources.
You can limit the number of NSX-T nodes in both the management and workload domains by following the below instructions:
- Deploy VCF Management Domain with Single NSX-T Node
- Deploy Workload Domain with Single NSX-T Node in Small form factor
Step 1: SSH into SDDC Manager using the vcf user and switch to root user by running the command: su – root
Step 2: Modify application-prod.properties and add custom parameters
|
1 2 3 4 5 |
# vim /etc/vmware/vcf/domainmanager/application-prod.properties For single NSX-T node: nsxt.manager.cluster.size=1 To change the NSX-T form factor: nsxt.manager.formfactor=small |
Step3: Reduce VCSA Size for Workload Domain
|
1 |
vc.deployment.option=management-tiny |
Step 4: Restart Domain Manager Service
|
1 |
# systemctl restart domainmanager |
Tip 2: Reuse Cloud Builder VM for SDDC Bringup
Reset Cloud Builder for a Fresh VCF Bringup
Tip3: Disable vSAN Health Issue for Upgrade Precheck in Nested Lab
Disable vSAN Precheck During Domain Upgrade
Tip 4: Retry Failed Bringup with modified input spec in VCF
When an SDDC Bringup task fails because of an incorrect parameter in the json/Xls file used for bringup, the Cloud Builder UI doesn’t provide a mechanism to go back and change the input file with correct values and retry bringup with a modified file. In such a scenario, follow the below procedure:
Step 1: Generate json from XLS
|
1 |
/opt/vmware/sddc-support/sos --jsongenerator --jsongenerator-input <path-to-xlsx-file> --jsongenerator-design vcf-ems |
the resulting json is placed in directory /opt/vmware/sddc-support/cloud_admin_tools/Resources/vcf-ems/ by the name vcf-ems.json
Step 2: Obtain the UUID of failed bringup task
Open the vcf-bringup-debug.log file located in directory /var/log/vmware/vcf/bringup/
and look for the string “End of Orchestration with FAILURE for Execution ID <uuid>“
Make a note of this UUID.
Step 3: Update failed VCF bringup workflow with new values
|
1 |
curl -k -u admin:'password' -X PATCH https://localhost/v1/sddcs/<bringup-uuid> -H "Content-Type: application/json" -d "@/root/vcf-ems.json" |
https://vstellar.com/2020/06/retry-failed-bringup-with-modified-input-spec-in-vcf/
Tip 5: Increase the Wait Time for NSX-T Deployment
The deployment of NSX-T nodes can take a long time in some situations (because of slow underlying storage). In such a situation, it’s possible that the NSX-T deployment did not complete within predefined time limits and thus the bringup process is failing ultimately.
This situation can be tackled by reconfiguring VMware Cloud Builder to specify an extended timeout period for NSX-T nodes. Follow the procedure as shown below:
Step 1: SSH to Cloud Builder VM using the admin user and then switch to the root user.
Step 2: Modify the application.properties file.
|
1 2 3 4 5 |
# vim /opt/vmware/bringup/webapps/bringup-app/conf/application.properties Add the following property: nsxt.manager.wait.minutes=45 (or larger) |
Step 3: Restart Bringup Service
|
1 |
# systemctl restart vcf-bringup |
Step 4: Retry the failed bringup task