We are nearing the end of our journey with Getting Started with VMware Cloud Foundation (VCF). In this post, we will go through the deployment of Enterprise PKS v1.5 on a Workload Domain created in VCF v3.9. We’ve been through a number of steps to get to this point, all of which can be found here. Now we have some of the major prerequisites in place, notably NSX-T Edge networking and PKS Certificates, so we can proceed with the Enterprise PKS deployment. However, there are still a few additional prerequisites needed before we can start. Let’s review those first of…
If you been following my adventures of deploying Enterprise PKS 1.5 on VMware Cloud Foundation (VCF) 3.9, you will be aware that I spent a considerable amount of time establishing Border Gateway Protocol (BGP) peering between my NSX-T Edge T0 Logical Router and my physical Upstream Router as documented in this post. This allows them to exchange route information, so that when one of my internal overlay networks needs to communicate externally, it can do so. However, I am in the fortunate position where I can access my Upstream Router and make any necessary BGP configuration changes to allow it…
I decided to dedicate a post to taking care of the Enterprise PKS prerequisites when deploying on VMware Cloud Foundation, namely the creation of the various certificates needed for trusted communication between the Enterprise PKS components (Operations Manager, BOSH, PKS and Harbor) and the rest of the environment. Unfortunately, the official VCF 3.9 documentation is a little light on the subject, simply stating that you should ‘Generate CA-Signed Certificates for Operations Manager, BOSH Director, Enterprise PKS control plane, and Harbor Registry‘. Therefore I decided that since it took me a bit of time to get these certificates setup for PKS…
I think now is a good time to take a recap on what we have built so far with VMware Cloud Foundation (VCF). We’ve done a number of activities to date, notably the deployment of the management domain in part 1. Then we spend some time deploying the vRealize Suite of products in parts 2, 3 and 4. In part 5, we commissioned some additional ESXi hosts and then most recently we created our first workload domain in part 6, which included the deployment of NSX-T 2.5. Now we come to quite a long section, which is the deployment of…
The VMware Cloud Foundation 3.9 journey continues. In this post, we are going to build our very first workload domain (WLD). In part 5, we commissioned 3 x vSphere 6.7U3 ESXi hosts that will form the basis of our new WLD. A number of actions will take place during this deployment. Firstly, a new 6.7 vCenter Server will be deployed in the management domain. Then, the 3 commissioned ESXi hosts will be clustered together, allowing vSAN and vSphere HA to be enabled. We will also see NSX-T (version 2.5) deployed for the WLD as I am going to deploy NSX-T…
At this stage, we’ve done quite a number of tasks related to VMware Cloud Foundation (VCF). Our management domain is up and running, and we also have the vRealize Suite of products deployed (vRealize Suite Lifecycle Manager, vRealize Log Insight, vRealize Operations Manager, and of course vRealize Automation). Our next step is to commission some new ESXi hosts so we can create our very first VI Workload Domain (WLD) which we can start using for production purposes. This post will look at the steps involved in commissioning the hosts. Note that in this example, I am going to commission ESXi…
After taking care of all of the prerequisite steps highlighted in my VMware Cloud Foundation Part 3 post, we are now ready to deploy vRealize Automation (vRA) via vRealize Suite Lifecycle Manager (vRSLM) in the VCF SDDC Manager. This will be a relatively shorter “show and tell” post, which will take you through the deployment steps. It will also show you how you can monitor the progress of the vRA deployment. The complete deployment does take some time since there are quite a number of virtual appliances and virtual machines that need to be rolled out for vRA (11 in…