Terraform and vSphere – Part 4: More Compute Cluster Resources

Introduction

In my previous posts we talked about Terraform, Desired State (and used a Compute Resource as an example) and Importing resources in a follow-up post. However VM/Host Groups, VM/Host Rules and VM Overrides are also part of the Cluster configuration.

Unlike the resource vsphere_compute_cluster where the state of a large number of options is automatically monitored by Terraform, this is not the case for the options discussed in this post.
Here it’s what you see is what you get. If you use Terraform, then it is more than a good practice to let Terraform take care of everything.
By this I mean the following; if you have created an affinity rule with Terraform for 2 VMs called VM1 and VM2, then the state of this affinity rule is monitored by Terraform. But if you manually create a second affinity rule for 2 VMs called VM3 and VM4, then this second affinity rule is unknown to Terraform and its state is not monitored. Should this occur, it can of course be solved by importing the second rule into the Terraform configuration afterwards.

Having said this, time for an overview of these cluster resources.
In vSphere Compute Clusters, 4 types of VM/Host rules can be created:

Keep virtual Machines together: Terraform resource:
vsphere_compute_cluster_vm_affinity_rule

Separate Virtual machines: Terraform resource:
vsphere_compute_cluster_vm_anti_affinity_rule

Virtual Machines to Hosts: Terraform resources:
vsphere_compute_cluster_host_group
vsphere_compute_cluster_vm_group
vsphere_compute_cluster_vm_host_rule

Virtual machines to Virtual machines: Terraform resource:
vsphere_compute_cluster_vm_dependency_rule

vSphere Compute clusters also allow you to create Overrides for individual objects. Terraform has 3 separate resources; to add a DPM override to a cluster for an ESXi hosts and to add DRS and HA overrides for virtual machines.
vsphere_dpm_host_override
vsphere_drs_vm_override
vsphere_ha_vm_override

Before showing examples, a few words about the flow of work. If you are working in a greenfield (that is adding resources), the flow is:
– add new resource(s) to the Terraform configuration file,
– run terraform plan and
– run terraform apply.

If you need to import existing cluster rules, the flow is a bit more complicated:

• Add new resource(s) to the Terraform configuration file. In some cases you can start with a basic configuration and add additional code after importing the resource
• Import the new resource
• Run terraform plan to detect missing parts
• Update the configuration file in case of errors or missing parts
• Run terraform plan again to check the configuration. If everything went well, terraform plan end with “No changes”

BTW, if you want to import existing cluster rules, you can run a PowerShell script like this to gather info.