If you’ve checked out the Planning & Preparation (P&P) Workbook for VMware Cloud Foundation (VCF) or VMware Validated Design (VVD) in the past, then you are in for some change with this latest release. We introduced this workbook back in the VCF 4.0/VVD 6.0 days in an attempt to evolve the planning experience from a static webpage to something that was more interactive and dynamic. Since then, its become one of the most downloaded documents that my team produces. While that doesn’t indicate how well it has been received, it does indicate that its a subject that a lot of people are interested in, and therefore something that we should continue to invest effort and innovation in.

This latest release covers the VCF platform itself (both Management and VI Workload Domains) and also the recently announced VMware Validated Solutions that I posted briefly about a couple of days ago. In this post I am going to try and take you through the changes in this release as its a big shift forward (I hope) in:

The Deployment Options it presents.
The manner in which it present the Workflow Tabs (where required values are presented for consumption while you are deploying the VCF platform and/or the individual VVSs)
We don’t really refer to Regions any more but rather instances. Ultimately, you can deploy any of the solutions we offer across instances, and those instances could be the same or different geographic locations, so this just makes it feel a bit more inclusive.
The number of files. Now there is just one dynamic file, and the options you choose define the profile of what you are deploying (for those with a VVD background, you’ll see the file flip between the familiar SFO or LAX based values based on the options you choose). So instead of using a bespoke Region A or Region B file as before, you now just use different copies of the same file – one for each instance of VCF you want to deploy.

Deployment Options

So let’s start with the most obvious visual changes. The options. To see how much they have changed, lets take a quick look at how the Deployment Options tab looked in the VCF 4.2/VVD 6.2 release.

A total of 15 options on the Deployment Options tab (Management Domain deployment is assumed), each of which was a simple ‘Include/Exclude’ and the file then used that information to inform you what was possible/not possible to combine and where dependencies existed.

Now take a look at the same tab in the latest release:

There are now 25 options (again Management Domain deployment is assumed) but now many of these options are more complex than simply ‘Include’ or ‘Exclude’. Each drop down is more context dependent, giving you options where they exist rather than a simple ‘Include’ based on a VVD prescriptive design. In this part of the blog post I’m going to go through each drop down to help folks fully grasp how everything works.

Some small things to note before we get into the weeds:

‘Using this Document’ section on the left. Designed to give you a start point on the significant choices. Hopefully this blog and other material I create will extend that information.
‘Useful Links’ which are pretty much what they say on the tin.
Hyperlinks to each of the Validated Solutions.
No VVD Version listed any more. Now everything is tied to the VCF version.

In general the file flows from top to bottom, in both the logical order of deployment and also the dependencies. So start with enabling what you want and work down. If, however, you are interested in understanding the dependencies I suggest you have a go at working from the bottom up, starting with the VVSs, reading the resulting red messages where it tells you which required dependencies have not been met and working your way back up resolving as you go.

Management Domain Deployment Options

Multi-Instance Integration Model

This option indicates how this management domain will be deployed, and it has three options in the drop down:

First Domain: Use this when this is the very first VCF management domain or where no integration with other VCF instances is required. It maps to the original VVD Region A deployment, and the reference values throughout the file will be as they were in the SFO VVD model for Region A (now the first instance).
Join Domain: Use this to merge the management domain of the new VCF instance into the SSO domain of an existing VCF instance. Using this will flip the reference values throughout the file to align with how they were for the LAX VVD model for Region B (now the second or additional instance)
Additional Domain: Similar to the Join Domain, also shows LAX values, but allows for an independent SSO domain, but ultimately you still intend to integrate the new VCF instance with management components deployed in an another VCF instance.

Considerations:

If you are deploying completely independent VCF instances, where none of the management components will interact at any level at all, then you can keep using the First Domain option over and over again.
If you use Join Domain, remember that there is a 15 vCenter instance limit per SSO domain, so that limit becomes the sum total of vCenter instance you can have across the combined instances. You do get the single-pane of glass of ELM from this if you want it.
Additional Domain gives you the best scalability, but you lose the ELM view.

Snippet of some Reference Values with ‘First Domain’ chosen

Snippet of some Reference Values with ‘Join Domain’ or ‘Additional Domain’ chosen

Host Overlay Network IP Addressing Model

Two options here. DHCP and Static. This controls how the Host TEPs are configured. If you chose DHCP, then you need to have DHCP available on the VLAN you choose. If you choose Static, then bringup will create an IP pool in NSX-T Data Center to be used by the Host TEPs.

Consolidated Management Domain

Simple Include/Exclude option here. Including it will disable VI Workload Domain Deployment. Like this:

All of the VMware Validated Solutions are designed and optimised for the Standard Architecture (i.e. a dedicated Management Domain, plus one or more VI Workload Domains). Therefore each of the documents are written prescriptively in that context. This doesn’t mean that you can’t do them in Consolidated Management domains, it just means YMMV a bit as we don’t expressly test VVS solutions in that model. If you choose to include Consolidated Management Domain, the Planning & Preparation Workbook will advise you of this:

However, in the Workflow tabs it will conveniently (and dynamically) switch from showing you VI Workload Domain values to showing you Management Domain values in all the right places 😀

Deploy Management Domain using ESXi Hosts with External Certificates

Another simple Include/Exclude option. Use this if you want to do management domain bringup with hosts that already have signed-certificates installed on them.

Management Domain Post-Deployment Options

Apply Signed Certificates

Three options here:

Exclude: If you don’t want to use certificates from an external CA, and instead continue with the VMCA signed certificates. Choosing this will have some implications for creating VI Workload Domains in cases where multiple management domains have been joined using the ‘Join Domain’ model. In that case when you create a VI Workload Domain with SDDC Manager B, SDDC Manager A will not be aware of it, and not be able to work with it when attempting to create further VI Workload Domains itself (and vice versa for when B goes to do the same after A has created a new domain). The workaround is to import the VMCA-signed certs for the new VI Workload Domain created by A into the trusted store on B immediately after creating it (and into any other SDDC managers in the same SSO domain if you have more than two)
Microsoft CA: Used when you want to configure SDDC Manager with a Microsoft certificate authority to deploy signed certs to the workload domain components.
OpenSSL CA: Used when you want to configure SDDC Manager with an OpenSSL certificate authority to deploy signed certs to the workload domain components.

NSX-T Data Center Routing for Management Domain

Three options here too:

Exclude: Where you don’t intend to deploy an NSX-T Edge Cluster for any reason.
Overlay-Backed: Use this option if you want to deploy an NSX-T Edge Cluster, with BGP routing and overlay backed NSX-T Segments to support the Application Virtual Networks (AVNs) that are used by several of the VMWare Validated Solutions.
VLAN-Backed: Use this option if you would rather use an NSX-T Edge Cluster, with Static routing and VLAN backed NSX-T Segments to support the AVNs.

Considerations:

Overlay-backed segments are required for items such as Management Domain Federation or Developer Ready Infrastructure in Consolidated mode.

Management Domain Federation

Four options this time:

Exclude: No inter-instance NSX-T Federation is required.
Active Global Manager: Where you want this management domain to host an Active Global Manager cluster to support NSX-T Federation across instances. This is the minimum requirement for configuring said federation, though it is highly advisable to deploy a standby Global Manager in one of your other instances to ensure Global Manager availability. Typically chosen in the ‘First Domain’ context.
Standby Global Manager: when you want to deploy the aforementioned standby Global Manager cluster to this management domain. Typically used in the ‘Join Domain’ or ‘Additional Domain’ contexts.
Connect Instance: when you already have your Active and Standby Global Managers deployed, but you are deploying another instance of VCF and want to federate its NSX-T Local Managers into the existing Global Manager deployments. Typically used in the ‘Join Domain’ or ‘Additional Domain’ contexts.

Here you can see the ‘dependencies not met’ in action in the workbook when attempting to enable Management Domain Federation:

Changing the ‘NSX-T Data Center Routing for Management Domain’ to ‘Overlay-backed’ as requested and everything goes green:

Stretched Cluster

If you were a fan of VVD Multi-AZ, this is the option you want. Simple Include/Exclude here based on whether you want to deploy a stretched cluster for the Management Domain

vRealize Suite Lifecycle Management and Clustered Workspace ONE Access

vRealize Suite Lifecycle Manager

Simple Include/Exclude option here. But vRealize Suite Lifecycle Manager (vRSLCM) is required for the deployment of many of the VVS solutions, and also for Clustered Workspace ONE Access

Clustered Workspace ONE Access

Simple Include/Exclude option. Required by the Private Cloud Automation VVS as vRealize Automation has a hard requirement on it for User Authentication. Its also used by the Intelligent Operations Management VVS for user authentication by way of the prescriptive nature of the VVS documentation.

Virtual Infrastructure (VI) Workload Domain: Deployment