Finding a way with Terraform instead...

MDT & Terraform

Disclaimer: This content is in no way endorsed, reviewed, or otherwise known to my employer or any of the vendors mentioned. The following are the thoughts of Benjamin Crill and nobody else.

This blog will be a follow on to my previous blog regarding Packer and Nutanix infrastructure (https://www.icrill.com/single-post/a-hacker-at-packer). There is currently still no Packer plugin for Nutanix to allow for native usage of the tool. As such I came up with a solution to build the VM locally with VirtualBox and upload it to the Nutanix cluster. While this worked, it isn’t ideal. Because of the differences in virtual hardware, you can end up with ghosted devices in the image. If you have been doing virtualization, specifically virtual desktops, for any amount of time you are aware that ghosted devices can cause very unexpected behavior. So how else might tackle this problem?

I’ve long been a fan of the XenApp Automation Framework (https://xenappblog.com/) for automating image builds as well as other Citrix infrastructure installations. The framework is built from the Microsoft Deployment Toolkit and Windows Deployment Services. I already have the Automation Framework VM setup and working task sequences, so the base functionality is there. In my environment I have the network setup for my environment so that a VM can PXE boot into the MDT environment so really, I just need to automate creating a VM on my Nutanix cluster.

One option could be to use the Nutanix PowerShell modules. However, I wanted to stick with tools that could be used for other purposes not just for Nutanix. Despite not having a Packer plugin, there is a Nutanix plugin for Terraform. The amount of effort to create a VM with Terraform on Nutanix is easy. It’s even easier because Nutanix already has a template for you to use (https://github.com/nutanixdev/terraform_blog/tree/main/intro).

The first thing is to declare the variables we will need. For my setup it looks like this:

The variables are self-explanatory. However, the endpoint is the IP can be either the Prism Central OR Prism Element address despite the documentation only referencing Prism Central.

With your variables setup then all that needs to be done is to define the VM configuration in your Terraform code.

The above code will create a single VM on the cluster with the name of TF-datecreated. The reason I did this is so that it was easy to determine the creation date of the image to correspond with Windows updates roll outs. Also keep in mind that the name of the VM in Prism has no relation to what the name of the VM from a Windows perspective. Once the VM is created on the cluster, it is automatically powered on. From there MDT takes over.

On the Automation Frame/MDT side I put everything in the Default rules for how it should provision the machine. In the rule set I have it set the computer name and the task sequence it is going to run and not to prompt to select them. This allows the provisioning to happen fully hands off. At first you might think that setting the name the same could cause some problems. It may at some point in the future, but so far it hasn’t, and I’ll explain why.

The first thing you might think is ‘what about next month when you have to create the new VM.’ Keep in mind that Terraform tracks state so if I run terraform apply again it’ll just update the name of the VM in Prism. For me to re-provision my gold image I must do a terraform destroy first and then another terraform apply to delete and recreate the VM. The risk out there is if more machines are needed, and then something happens in the provisioning of the new golden image, then a situation might arise where one couldn’t add additional machines. This is something that is an area for improvement, but so far hasn’t been a major issue.

The second thing you might think is ‘what about the domain computer account?’ I never join the gold image to the domain as part of the provisioning process. The reason for this is that for MCS provisioned machines it is not required (https://docs.citrix.com/en-us/citrix-daas/install-configure/machine-catalogs-create.html). I’ve been doing Citrix for a while and only recently realized that joining the domain is not required for MCS created machines. So, with not joining the domain, and destroying the gold image each month, the same computer name can be reused without issue.

As you can see the setup is not earth shattering. It is just a matter of taking separate tools and having them work together to solve a problem. Too many times we in IT get fixated on how the best way is to solve a problem rather than just finding a solution. A friend of mine always says ‘don’t let perfect get in the way of the good’ whereas I like to say, ‘the best solution is one that works.’ Hopefully this will work for you or help you get to the next step. If you want to use the files you can find them on my GitHub (https://github.com/benjamin-crill/MDT_Terraform).

Next up in my automation journey I’m going to work on building out a gold image build leveraging Nutanix Calm (I work for Nutanix, I’m a little biased). I’ll keep you posted and welcome your feedback on this.

All the best!