VMware Validated Design 6.0 / VMware Cloud Foundation 4.0 Planning & Preparation

It’s been an interesting few months working on the just released VMware Validated Design 6.0. It’s a BIG release. Every component in the management stack has had a major version change and to add to that we completely changed the operating model from the 5.x days.

Starting with VMware Validated Design 6.0, we are now building on top of and extending VMware Cloud Foundation 4.0. Gone are the days where you had to use VMware Cloud Builder to do the whole stack deployment at Day 0. Now you use Cloud Builder to bring up the management domain (including SDDC Manager) and from there on you use SDDC Manager and vRealize Suite Lifecycle Manager to do the rest of the stack in your own time.

The VMware Cloud Foundation (VCF) and VMware Validated Design (VVD) documentation have come together too. VCF product documents tell you how to deploy components using the toolset and the VVD docs provide a prescriptive architecture, design and deployment implementation using that toolset in the usual VVD fashion. 

However the VVD docs have a brand new and more modular structure. There are now individual Architecture & Design and Deployment Guidance docs for:

• Management Domain
• Virtual Infrastructure (VI) Workload Domain
• vSphere with Kubernetes Workload Domain
• Cloud Operations and Automation Solution

Check out the official release notes here for full detail on What’s New. 

One of those What’s New items is a brand new approach to how we do the Planning and Preparation for a VCF/VVD deployment. As I played a large part in how that panned out, I’d like to take the time to introduce you all to why we’ve changed it up, what we’ve done and how it all operates. 

So here goes…..

Why did we think a change was needed?

As we sat in our planning meetings discussing what the new release was going to look like, we all agreed that a new documentation model was required to deliver VVD 6.0. Outcome: The modular approach to the docs referenced above instead of the monolithic Architecture and Design and Deployment docs.

But we spent an equal amount of time debating the merits of the previous Planning & Prep model, and how we could make it easier for customers to:

1. Gather all of the required inputs
2. Get all of the required pre-reqs completed
3. Navigate the prescriptive deployment guidance a little easier

I don’t mind admitting that I was one of the folks that felt that the previous Planning & Prep model was too static, in that it was just a list of example values. The customer or VMware field folks still had to take it from that static form (web or PDF) and create their own version with their own values, knowing when to exclude certain bits and when not to based on the components they were planning to deploy.

With the convergence of VCF and VVD (which had their own similar but different Planning & Prep documentation sets) we felt that we should also look to consolidate these and have a single effort that had a little more intelligence built in.

We also felt that the required inputs were a little scattered in terms of task ownership. How we presented the information that needed to be gathered or decided could do with some work.

What did we do and how does it work now?

Starting with VVD 6.0 and VCF 4.0 there is now a single Excel based Planning & Preparation document that you can find here.

Deployment Options

The document leads with a Deployment Options tab. Like this:

Toggling the highlighted Include / Exclude options alters the subsequent tabs by obscuring the inputs that are not required. One of those options is VVD itself. If you exclude this option, the document guides you through gathering requirements for a native VCF deployment. Enabling VVD adds the pieces you will need to extend the VCF deployment inline with the VVD guidance. As you can see there are many options, and therefore permutations, so knowing the effect of toggling the options is useful. When you do so , the ‘Process‘ column changes to indicate the effect of that change on the process for or applicability of other items. Like this for example:

Pre-requisite Checklist

The next tab, as the name suggests, shows you the list of things that need to pre-exist within your infrastructure for the deployment. The key difference to before is that they are tailored based on the options you selected above. This pages includes detail on Hardware and Software requirements, Network, Active Directory, DNS, NTP, Certificate Authority etc

Remember….its always DNS or NTP when things go wrong, and the screenshot is not the entire list – so don’t gloss over this tab. Make sure you have the right things setup and in the right way.

Input Tabs

The next four tabs (coral? colour) are the input tabs, and the key change here is two fold:

1. We show you the example ‘Rainpole’ value that you will see in the VVD Documentation, alongside a blank field that allows you to insert the actual value to be used for the deployment.
2. The tabs are structured to be aligned with datacenter personas such as
   1. Network Admin (Network Inputs)
      • Details on VLANs, Subnets and BGP information (as required)
   2. DNS Admin (Name & IP Address Inputs Tab)
      • Details on hostnames and IP address allocations, DNS suffixes etc
   3. VI/SDDC Admin (SDDC Inputs Tab)
      • Everything to do with naming and settings within the virtual infrastructure
   4. Active Directory Admin (Active Directory Inputs Tab)
      • You guessed it detail on AD, Users, Groups etc

Here’s part of the Network Inputs Tab. 

As you fill out the details, the coral fields turn green. If something is still coral, you’ve missed a required input.

If you had disabled an option on the Deployment Options tab (lets say Virtual Network Segments for the Management Domain), then it would have an effect like this. The inputs you no longer need to worry about are now obscured.

Any input is requested only once. The value you put in, may appear in several other places, such as:

1. The workflow tabs, which we will cover next
2. Other inputs that are related. For instance, when I enter values for Parent and Child domains:

And then enter values for these two groups

The membership column is auto populated with the group memberships that ‘my-gg-vc-admins‘ AD group requires, so that your AD admin can fill out the sheet, then go make it all happen in the infrastructure.

The rest of the tabs work in a similar fashion. Hopefully this will make it easier to assign and track the up-front preparation work that needs to be done before starting a deployment.

Fun Fact: We have changed the example customer shown in the VVD docs from ‘rainpole.local’ to ‘rainpole.io’ which is a publicly available TLD, and should you pop it in your browser will take you directly to the the VVD documentation. 😀

Workflow Tabs

Once all the inputs are complete, the next set of tabs (yellow) map to the distinct workflow processes you follow during the deployment of an SDDC. These tabs are read only, and populated automatically as the input tabs are filled out.

If you have VVD turned on, then you follow the VVD prescriptive guidance, using the provided inputs. If you have VVD turned off, you follow the VCF guidance using the provided inputs.

1. CertGen File
   • If you have VVD turned on and are deploying components of the vRealize Suite you need to generate some self-signed certs using the CertGenVVD-6.0 tool. This tab will auto-populate with values from the input tabs and can be saved off for direct use with CertGen.
2. Management Domain
   • Will populate with values required to perform VMware Cloud Builder bringup of vCenter/SDDC Manager and optionally to deploy Virtual Segments or post configuration if VVD is turned on.
3. Virtual Infrastructure (VI) WLD
   • Will populate with values required to create a VI workload domain via SDDC manager, plus optionally the creation of NSX-T edge clusters or post configuration if VVD is turned on
4. vSphere with Kubernetes WLD
   • Will populate with values required to create a workload domain via SDDC manager, the creation of NSX-T edge clusters, the enablement of vSphere with Kubernetes on top of that workload domain plus post configuration if VVD is turned on
5. Cloud Operations and Automation
   • Requires both VVD and Virtual Network Segments for Management Domain to be enabled, and will provide all the inputs required to follow the deployment process.

In this example of the Management Domain tab, the Network Admin has provided all their detail, but the SDDC admin has yet to provide detail for the naming of portgroups etc, so a bunch of the fields indicate in bright red that there is a ‘Value Missing’. 

Once the SDDC Admin details are entered on the SDDC Inputs tab, we are ready to proceed

Note how these tabs show you the value you will see in the prescriptive VVD deployment documentation, along with your own value, so when you see value ‘X’ in the doc, you have an easy reference mechanism to replace it with value ‘Y’ as you deploy.

Obviously there are far more inputs on the tab than I am showing in these screenshots (we are building an SDDC after all!) but you get the idea, and the same process applies to all the tabs. If you see a red cell with ‘Value Missing’ in it, then something vital has been missed on the input tabs, and you should check those out looking for coral coloured cells indicating that a value is required but has not yet been provided. If you see ‘Value Missing.Value Missing‘ in a cell it means you have missed two inputs, which get concatenated together in this cell for use during the deployment.

One more detail

You may have spotted the fact that deployment of the Management Domain is ‘Assumed’ and does not have the option to disable it completely. So you might be asking yourself ‘What if I am deploying a second or third workload domain and I don’t need to deploy the management domain again?‘ It’s a fair question. The answer is that even if you are deploying an additional workload domain, you still need a certain number of management domain inputs in order to complete the integration of that workload domain into the management environment. 

If you are in such a situation and you are populating a second copy of the file for the purposes of a new workload domain then when you get to the workflow tab for that domain you will see some tips indicating that you need to go back and populate a few of the management domain inputs in order to have all the necessary values when walking through the deployment

The Future….

Obviously I can’t talk about the future in specifics, but we do have several ideas on how we can extend this concept further to make life for customers and their deployment teams even easier in terms of minimising the inputs and effort required to get the SDDC up and running. If you like the above concept (or if you don’t!) feel free to tell us at VMware (or me here) your thoughts. Its quite likely that what you think we should do next and what we think we should do next are closely aligned – but its always good to know that we are on the same page!