Deploying a Fully Functional Lab for VCF on Your Home System: A Multi-Part Series (Part 1)
As a VMware enthusiast, I have always been fascinated by the world of virtualization and its endless possibilities. In this multi-part series, I will be exploring how to deploy a fully functional lab for vCenter Cloud Foundation (VCF) on your home system. This lab will provide you with the opportunity to play around with API and automation, and get hands-on experience with VCF bringup.
In this first part of the series, we will cover the pre-requisites for deploying VCF and the infrastructure required to support it. We will also delve into the details of how to prepare your base infrastructure and deploy VCF using Cloud Builder. So, without further ado, let’s dive in!
Pre-Requisites for Deploying VCF
————————————
Before we begin, there are a few pre-requisites that you need to fulfill before deploying VCF:
### Hardware Requirements
To deploy VCF, you will need a desktop with the following hardware specifications:
* AMD Ryzen processor
* 128 GB Memory
* 1 TB SSD
* Running Windows 11 Pro
### Software Requirements
You will also need to have the following software installed on your system:
* VMware Workstation (hypervisor)
* Windows Server (host OS)
* Cloud Builder (VCF deployment tool)
In addition, you will also need to have a base network infrastructure set up, which we will cover in the next section.
Preparing Your Base Infrastructure
————————————-
To deploy VCF, you will need to create a new custom network in VMware Workstation and attach it to all the virtual machines (VMs) as shown in the diagram below:
As you can see, we have created a new custom network called “VCF-Net” and attached it to all the VMs. We have also created a team interface in Windows Server and multiple Team Interfaces which carry different VLANs. This approach helps us logically separate traffic and provide different VLAN IDs required for VCF bringup.
Why Do We Need VLAN 0?
—————————
When deploying Cloud Builder, it doesn’t provide an option to provide VLAN ID. So, using VLAN 0 can help connect to devices running on untagged networks. Additionally, we have connected a second interface with an interface to our base OS to provide routing capability between the base OS and nested VM.
DHCP has been enabled on the same server to provide IP addresses to HOST TEP interface. DNS has been enabled and integrated with AD to host A/PTR records.
Converting Excel Parameter File to JSON Spec File
————————————————-
To customize the deployment for our lab, we can use the Cloud Builder SOS utility to convert an Excel parameter file to a JSON spec file. This helps us force 1 NSX-T Manager instead of standard 3 NSX-T managers, which saves a lot of resources.
Here’s a sample JSON spec file that you can use as a starting point:
“`json
{
“nsx-t-managers”: {
“number”: 1,
“names”: [“NSX-T Manager”]
},
“host-tep-interfaces”: [
{
“interface”: “vEthernet (TEP)”,
“vlan-id”: 0
}
],
“team-interfaces”: [
{
“interface”: “vEthernet (Team)”,
“vlan-id”: 100
},
{
“interface”: “vEthernet (Team)”,
“vlan-id”: 200
}
]
}
“`
This sample JSON spec file defines one NSX-T Manager, one HOST TEP interface with VLAN ID 0, and two Team Interfaces with VLAN IDs 100 and 200. You can customize this spec file to fit your specific requirements.
That’s it for this part of the series! In the next part, we will cover the deployment of VCF using Cloud Builder on our prepared infrastructure. If you have any queries or questions, feel free to post them in the comments section below. Thank you for reading, and I hope you found this article informative and helpful!