Concrete Foundation, Not VMware Cloud Foundation

VMware Cloud Foundation Basics – Why You Need VCF In Your Data Center

My past 18 months at VMware have been a whirlwind of training, customer relationships, and new product announcements. I’m starting to see a pattern of questions, especially about where new VMware products fit into the portfolio. This is the first of series of posts about the VMware portfolio in 2017, all my humble view of things, of course. First up, VMware Cloud Foundation (VCF). In the future, I’ll take a look at VMware Cloud on AWS and vRealize Automation. Please let me know if you have a burning desire for my perspective on something else. *grin*

Problem Statement – What is VMware Cloud Foundation? What’s the problem that VMware Cloud Foundation is trying to solve?

In a word, complexity. Early virtualization was a way to simplify our technology, add amazing new capabilities, and return value back to the institution in the form of administrative time, agility, and availability. The move from basic virtualization to Private Cloud brings increasing complexity and management time for the data center operator. This has begun slowly eating away at the simplification and administrative gains of core virtualization. VMware Cloud Foundation is a product that seeks to automate away some of the complexity of the lifecycle costs (commissioning, upgrading, and decommissioning) of the hardware and software underlying Private Cloud infrastructure.

What is it?

  • Prescriptive infrastructure blueprint for compute, network, and rack layout
  • Prescriptive Hardware Compatibility List for compute and network components
  • Lifecycle management tool suite to automate the deployment, upgrade, and decommissioning of the hardware and software components (SDDC Manager, Hardware Management Service, VIA)
  • A soft bundle of VMware’s compute, storage, and network software (vSphere Enterprise Plus, vCenter, vSAN Advanced, NSX Advanced)


This is a solution which is already architected and designed. Your decision is, “Does this design meet my business requirements?”

List of benefits from the documentation with my commentary:

Natively Integrated Software-Defined Stack

Fully integrated vSphere, vSAN, and NSX with fully automated installation and upgrades

In addition, more and more VMware independently licensed software is able to be deployed automatically by the SDDC Manager (vRealize Operations, Log Insight, Horizon View, App Volumes)

Automates Hardware and Software Bring-Up

The “VIA” appliance handles initial imaging of a brand new Cloud Foundation rack from bare metal. That includes setting up the Top of Rack and Spine switches (if you have a multi-rack setup) and vSphere/vSAN/NSX installation on the initial hosts. This automation can shorten a multi-month bring-up to something which can be done in days. Single-digit days.

Simplifies Resource Provisioning by Creating Workload Domains

The SDDC Manager creates Workload Domains, self-contained compute/storage/network groups with their own vCenters. This new abstraction is a VMware Cloud Foundation management construct for containing those infrastructure resources as well as enforcing availability and performance requirements. Obvious uses would be separate Dev, Test, and Production environments, each with different infrastructure, availability, and performance profiles. Another would be the data center operator who acts as an IT service provider. This is especially useful when customers need their own vCenter-level access. Keep in mind, you still have the vCenter abstractions to leverage inside the Workload Domain.

Automates Lifecycle Management

I already mentioned the automated deployment features of VIA. VIA also does day 2 imaging of new hosts when expanding VCF. Further lifecycle functions such as upgrades to the vSphere/vCenter/vSAN/NSX stack are handled by SDDC. This is also backed by VMware validating upgrade packages integrating versions of the stack which work together as a step function. There’s also an automated decommissioning process to remove hosts from Workload Domains. This is how you’d move host resources from one Workload Domain to another, decommision a host then add it to a different Workload Domain.

Integrates Management of Physical and Virtual Infrastructure

Remember that VCF has hooks into both the virtual infrastructure (via vSphere and vCenter APIs) and physical infrastructure (Hardware Management Service). That’s true for both network and compute layers. When there are problems, data center administrators can see and correlate issues at both the physical and virtual layer in a way that typically involves multiple teams in typical environments. Imaine the benefit of cutting down on troubleshooting sessions attended by representatives of compute infrastructure, virtual infrastructure, networking, and storage.

Scalability and Performance

Entry level is four hosts with Management and Workload domains converged. VMware Cloud Foundation can be scaled up by a single server at a time. Separate, dedicated Workload Domains can be created when you have three hosts to add. You can scale up to 32 hosts per rack (based on network port count on qualified hardware) and 8 racks (again, based on inter-rack switch port counts). vSAN Ready Nodes on the qualified list on the high end of storage density are Dell’s 40TB in 2U for 840TB per rack and HPE’s 100TB in 2U for 2,100TB per rack.


Do you remember the number of times I wrote prescriptive? If you have one or more constraints which aren’t compatible with the VMware Cloud Foundation design, you’re probably out of luck. For example, if you want to re-use existing storage appliances in your design, you’re out of luck with the VMware Cloud Foundation design. Do you have a constraint requiring you to use a ToR switch other than the three on the HCL? Uh oh. Are you unable to procure from the two models of management switch? At the moment, you’re out of luck.

In my mind, these are small trade-offs. We have other architecture frameworks for those who want to go outside of the VMware Cloud Foundation framework. I’m specifically thinking of VMware Validated Designs, but there’s always the option of hiring one’s own infrastructure architect and getting a custom design. When VCF fits, it really fits.

In its current incarnation, VMware Cloud Foundation reserves four hosts in every rack for management. Of course customers are allowed to deploy non-management workloads there, but there’s some overhead for management workloads. The host count for a dedicated Workload Domain in any rack is seven, four for the Management Domain, three for the Workload Domains.

Why is this magical?

Deployments at any kind of scale require a significant investment in design/validation which means calendar time, internal resource time, and cost spent on design expertise. Then the deployment and integration of the full stack takes calendar time, internal resource time, and cost on external resources. This is all completely side-stepped by going with a prescriptive design and an automated deployment. Again, the whole process can move from months to less than two weeks.

I have customers who grew their data centers tremendously over the past 5-6 years, resulting in a mix of host, storage, network hardware, making for a nightmare of complexity. Solution: VMware Cloud Foundation.

Additional Resources:

VMware Cloud Foundation Documentation [html] [pdf]

Hands-on-Lab: HOL-1706-SDC-5 – VMware Cloud Foundation Fundamentals

VMware Cloud Foundation Blog

VMware Cloud Foundation: A closer look (YouTube)

Up Next:

There seems to be some confusion between this offering and VMware Cloud on AWS, so I’ll try to give the background on that product.



image sources

Published by


John White is walking the path to virtualization mastery.

Leave a Reply