Most customers I talk to still use vSphere VM Templates to create VMs, which has been the same way people have done it for, let’s say, 20 years. If you still do it this way, I implore you to read on and understand how to do VM provisioning in the year 2025 (and beyond!).

The Challenge with Using Traditional VM Provisioning with vSphere Templates

How is VM creation done in the traditional sense on vSphere? Well, you create a VM, you (manually) set up the OS, configure it, install software and bring the VM and Guest OS to an “initial state”. Then you convert it to a template and ensure you have a Customization Spec. When someone needs a VM, you right click the template, choose “New VM from This Template”, and off you go.

I’ve done it a million times myself.

But there are some glaring issues here. I will refer to this method from here on out as the “template method”:

1. Templates have a tendency of proliferating. One template becomes 3 and 4 and 5 templates based on various use cases IT infrastructure must account for, and now the administrative overhead (and not to mention the security risk), is astronomically higher. These templates need to be maintained, updated, changed, and tested.
2. Templates are a manual process. A human being has to create the VM, work through a checklist, install software, and all of these have to be kept up to date over time.
3. There is no life-cycle management included with the template method. The VM is rolled out, and (hopefully) monitored, but there is no process for people to alter, update, or delete their own VMs.
4. Templates typically do not include a “zero touch” pipeline, which is more of an antiquated methodology problem than it is a technology problem, but what I have found is the VMware engineer will roll out a “Standard OS” (which isn’t ready for production) and then they hand it off to “the network team” or “the security team” or “the database team” adding unneeded time and complexity to the process:
   
   User: “Where’s my VM?”
   Engineer: “We’re waiting on SecOps to put their approval on it.”

This is why it takes days or weeks to get a VM to someone who needs it.

In order to deliver VMs quickly, the template method is too slow and cumbersome. It’s about 20 years old. Isn’t it time for an update? Users expect VM provisioning to be a thing they can do on their own, and they expect it to be done in seconds or minutes.

Let me show you a better way.

How to Provide Modern VM Cloud Native Provisioning on VMware Cloud Foundation 9.0

How are VMs provisioned in the modern era? More importantly, how do users (we call them “consumers” here at Broadcom) expect VMs to be provisioned?

The answer is very simple: consumers expect VMs to be (1) self-service, and (2) they expect them to take seconds or minutes, not days or weeks. Platform engineers, SRE’s, developers, DBA’s have come to expect this and I don’t see a lot of VMware shops adapting to this reality.

So how do we provide cloud native VMs on VCF 9.0? There are three major components:

1. Image-based automation using infrastructure as code: Rather than creating VM Templates, you will create a single, standardized image (in ova format) for each OS that has been collaborated upon and pre-approved by all parties. This OS would include your security and configuration standards, logging, observability, day 2 configuration management agents, and even some apps. This requires some up-front work, but once it’s complete, iterating on it is low-maintenance, and in the long run, a lot less work.
2. VCF Automation: This will provide the self-service UI/API to your consumers so that they can rapidly provision their own VMs.
3. cloud-init (or Sysprep for Windows): This will complete the configuration and application installation to the consumer’s specific use case and needs. For example, if this needs to have a database installed with specific configurations, this will be completed by the consumer. 

Focusing on Linux distributions alone, I have had several conversations with platform engineers and developers who had no idea we officially support cloud-init, and once they realize this, they say things like, “OK, you had me at cloud-init, I can take it from here!”

The flow for image creation and maintenance looks like this:

Note that there is only one image and that the application configuration and installation is up to the consumer (this is the cloud native approach!).

If the idea of infrastructure as code scares you, remember that most of this is json/yaml, which is the same as filling out a form in a UI.

Also, you don’t have to use Packer, it has just become the de facto tool for this process. We have our own tools for this. You can use VMware Workstation, or the ovftool.

Self Service in VCF Automation 9.0:

Finally, what does this mean for you as the Provider? What does this process look like for the Consumer?

As the Provider, you will create the image and make it available through permissions you set up in VCF Automation. You’ll define your Organization, t-shirt sizes, and who has access to them by groups. 

From there, there is no need to create complicated VCF Automation blueprints, or use complicated code. This process is now built-in with VCF Automation 9.0. It looks like this to the Consumer:

And the aforementioned cloud-init is built into the process:

Keep in mind that this can be used through a GitOps pipeline as well.

For a deeper dive on VCF Automation as a Provider, watch our YouTube 3-part series starting here. 

If you are used to providing self service through a cloud, or if you are a consumer of a cloud, this should all look familiar to you. Why?

Because this is how things should be done.