Today, VMware Cloud Foundation (VCF) 4.0 was released. One of the new features mentioned in the release notes is how the SDDC Manager now can automate the deployment of NSX Edge Clusters. Today, I’m going to show you how to automate that automation.

VMware Cloud Foundation (VCF) 3.9.1 requires the configuration of BGP in order to deploy a new instance of VCF. If BGP is not configured properly, the deployment of VCF will fail as it will not be able to validate the communication to the Edge Service Gateways has been configured properly. In this post, I’m just going to quickly run through some methods you can use to attempt to troubleshoot a deployment that is failing due to a BGP issue.

If you have ever had to manually change the certificates in a vSphere environment, you’ll appreciate the automation VMware Cloud Foundation (VCF) provides. After connecting the VCF SDDC Manager to a Microsoft CA server, you are a few clicks away from being able to rotate the certificates for various VMware products.

Establishing the connection to the Microsoft CA server, however, requires that the Microsoft CA server is configured properly. Today, I’ll walk through the steps required to configure a Microsoft CA for use with VCF.

I was recently asked if there is a way to remove a bundle that has been already downloaded by the SDDC Manager. Most of the time, there is little need to do this. However, there are times when it can be helpful – like if you are using a VCF environment to teach others how to perform tasks like downloading VCF bundles manually. Let’s take a look at how you would do this.

VMware Cloud Foundation (VCF) communicates periodically through the internet with a hosted web service in order to check for and retrieve software updates and bundles. What if you don’t have internet access? Today, I’m going to demonstrate how you can build out your own software repository for VCF.

Before we begin, it’s important to note that this process is not supported for production environments. To understand why, I need to give you a short overview of what I will be showing you today.

I’ve talked about how to use hosts that have multiple physical NICs to create NSX-V and NSX-T backed workload domains and even how to expand a cluster in one of these workload domains. But what if you want to do an initial installation of VMware Cloud Foundation (VCF) using hosts with multiple physical NICs?

As I’ve mentioned before, the support for multiple physical NICs with VCF is new with VCF 3.9.1. All of the operations we performed previously relied on the VCF API. This worked well for our intended use, but bringup is a different animal.

Last week, I shared an example of how to create a new workload domain with VMware Cloud Foundation (VCF) using hosts with more than two physical NICs. In that example, I used NSX-V in the creation of the workload domain. Today, I’d like to provide an example of how you would do this for a NSX-T backed workload domain.

As support for multiple physical NICs (>2) is a newly supported feature with the VCF 3.9.1 release, doing this requires the use of the VCF APIs.

With the VCF 3.9.1 release, support for hosts with multiple physical NICs has been added. This allows you to dedicate specific traffic across specific physical NICs to conform to your best practices. Let’s take a quick look at how this is configured…

By default, VCF will use the first two physical NICs (vmnic0 and vmnic1) on a host for all traffic. When working with a host with multiple physical NICs, you will need to define what the physical NICs are connected to (VDS or N-VDS). The VDS or N-VDS will need to exist, of course.