Tech Deep Dives

Introducing Virtual Machine Desired State Configuration

If I had to pitch you Virtual Machine Desired State Configuration (or “Project VMDSC,” as we call it) in an elevator at the next VMworld, I would tell you that it would completely change the way you interact with your infrastructure.

Dramatic? Yes.

Over-dramatic? Also, yes `¯\_(ツ)_/¯`

But it’s not an exaggeration to say that it will truly help you use compute and memory more efficiently and help save the planet in the process.

Let me explain.

In 2020, a motley crew of CTO Ambassadors felt that they had had enough of unnecessary stranded resources that not only caused poor application performance but also resulted in higher infrastructure costs for our customers. And because these resources are not being used efficiently, it increases energy consumption, which then translates into higher carbon emissions.

Yikes — that is a tricky chain reaction. If only we could do something about those unnecessary stranded resources. Hmm …

Before we get to solutions, let’s break this problem down.

How do resources get stranded?

Turns out, stranded resources come in two flavors:

  • Oversized Virtual Machines (VMs): VMs running application workloads are often provisioned with a lot more CPUs, memory, and storage than is required. These extra resources — which can be used for additional workloads — instead result in higher infrastructure costs and more energy consumption
  • Zombie VMs: These are workloads that exist in an organization’s IT environment but provide no technical or business value. They exist and expand because workloads become obsolete over time (like the apps on our smartphones). Because these are not identified and deleted, they end up stranding resources. Zombie workloads can exist as VMs or even bare-metal servers.

Moreover, organizations struggle with right-sizing virtual workloads because the VMs typically need to be shut down to be reconfigured. This poses additional challenges because administrators then need to coordinate with the business and application owners to determine when to “right-size” these VMs.

So how does VMDSC help you solve these problems?

VMDSC lets you specify a configuration that includes the desired CPU and memory you would like to allocate to your VM. VMDSC promises that whenever the guest OS on the VM reboots, it will reconfigure the VM with the CPU and memory you specified in the config object. So, you do not need to worry about explicitly rebooting VMs just to reconfigure them — you can just piggyback the reconfiguration whenever the VM needs to be rebooted routinely (like when the OS updates or to deploy an updated version of your workloads).

So how do you use VMDSC?

Using VMDSC is simple. First, you download an appliance to deploy in your vCenter cluster. While deploying the appliance, you fill in a few details, including hostname and credentials of the vCenter you would like to interact with, some networking bits, and the initial password for the appliance.

Once you have the VMDSC appliance deployed, you can start using the VMDSC REST API. Using this API, you can write your own scripts, use the Postman collection we provide as a download, or, if you are using vRealize Orchestrator, you can use our collection of nine workflows, right out of the box!

Our API is simple and only requires you to 1) authenticate yourself with your vCenter credentials and 2) post a config. You can also GET, PUT, POST, DELETE on your config object.

The config object looks like this:

```
 { 
    "uuid": "{{vm-uuid}}", 
    "cpu": 2, 
    "memsize": 2048 
}
```
  • cpu: number of CPUs that you would like to assign to your VM
  • memsize: memory (in MBs) that you would like to assign to your VM
  • uuid: UUID of the VM you want to set the desired state for. Why did we go with the UUID instead of the VM’s name? UUIDs ensure uniqueness, which is important if you are using the same VM name across clusters for two distinct VMs. The next field will make you happier.
  • name (auto-generated): We auto-fetch the VM’s name for you to make it easy for you to identify the VMs for which you are setting the desired state
  • state (auto-generated): Don’t worry about this one — you won’t have to deal with it

Once a config is posted, VMDSC will make sure that it is applied to the VM upon its next guest OS reboot.

Neat, right?

VMDSC is all about right-sizing

You may wonder, “what if I want to increase the resources allocated to my VMs? What if I anticipate that the load is going to increase? In that case, I would like to reboot them and, in the process, reconfigure them to my notion of right-sizing.”

Well, worry not. Our VMDSC lets you do exactly that. It lets you resize (oops, right-size) without forming an opinion about your definition of resizing. All you need to do is script up your decision metrics, decide the right number of resources you would like your VMs to have, and hit the VMDSC API to post a configuration against your VM.

Remember the bit about oversized and zombie VMs at the beginning? Let us conclude that story. Imagine you have a VM running PostgreSQL with 64 GBs of memory and 16 CPUs attached to it. It is always good to overprovision these resources, no? But what if six months have passed and the database has hardly received any requests but still monopolized 64 GBs of precious memory? After noticing that the database is not as active as anticipated, the administrator can decide to POST a config to VMDSC specifying half the original resources. This ensures that on the next guest OS reboot, the VM resizes, freeing up 32 GBs of memory and 8 CPUs.

This provides two benefits:

  • It helps you free up stranded resources and allows you to run more workloads, fully utilizing a host’s capacity without requiring you to provision more physical hosts
  • It informs you about a particular VM that may not be doing anything or is stuck in a comatose state (zombie VMs)

Having more VMs on fewer hosts helps you reduce your power consumption, which, in turn, translates into fewer carbon emissions.

Future work

This is still an experimental project. We plan to add many more features, such as the ability to schedule reconfiguration and the option to run VMDSC without deploying a separate appliance. We will keep you posted!

You can find VMDSC available for download here. Leave a comment and let us know what you think!

Comments

Leave a Reply

Your email address will not be published.