vSphere VM Templates – A Complete Guide – Part 1

In this first installment from a 4-post series, I’ll be introducing vSphere VM templates. The series kicks off by exploring the basics and ends with an automation example showing how PowerCLI is used to mass deploy VMs quickly and efficiently using templates and guest OS customization. vSphere 6.5 is the platform referenced throughout this series.

What is a VM template?

As the name suggests, a VM template is a blue-print, baseline image or master copy of a generalized virtual machine. As you probably know, creating and configuring VMs, is a time-consuming process. In this respect, deploying a VM from a template can drastically lower provisioning times and help you maintain standards; templates can be readily configured to tally with the specifications demanded by your environment and organization.

There’s also the option of having a library of Windows and Linux templates perpetually updated to the latest for easy provisioning. Guest OS customization (GOSC), a symbiotic feature that allows you to automate template provisioning, is something I’ll cover later on in the series.

Note that a VM template differs from an OVF/OVA template. The latter is used to import or export VMs using the OVF format.

One question that regularly pops up is “How does a VM clone differ from a VM template?“. Simply put, a clone is an independent copy of a VM taken at a specific point in time. It is an exact replica of the parent VM which is what ultimately makes cloning a bad provisioning choice due to IP conflicts, duplicate computer names and so on. A template on the other hand, is generic and left mostly unconfigured to facilitate both manual and automated provisioning. There are a few other subtleties you should be aware of. For example, you cannot power up a template or change settings save for the VM name and description. You’ll encounter no such restrictions when using clones.

Creating a basic template

Creating a template is a straight-forward albeit laborious process. First, create the VM and install a guest OS as you would normally do. Depending on the intended use, install the required software packages and apply the latest product and OS patches. You should also delete all temporary and redundant files. Remove unused hardware from the VM’s settings and configure the VM for optimal performance. Once all this is taken care of, simply power off the VM and convert it to a template.

As per Fig. 1, the vSphere Web client provides two very similar options to this effect. Right-clicking on a VM, gives you the options to either Convert to Template or Clone to Template. The significant difference is that with Convert to Template, the VM being converted must be powered off. The option is otherwise ghosted out. With cloning to template, the VM can be either on or off.  In either case, a wizard will take you through a number of steps prior to converting or cloning a VM to a template.

If you are using Content Libraries, you also have the option to Clone to Template in Library.

Figure 1 – Converting a VM to a template

Alternatively, you can use New-Template PowerCLI cmdlet to convert a VM to a template. In the example shown in Fig.2,  I’ve created a template from an existing VM called Centos. Note that all the parameters supplied are mandatory.

Figure 2 – Using PowerCLI to create a template

In vSphere client, templates are only displayed under the VMs and Templates view. The Get-Template PowerCLI cmdlet replicates this.

Figure 3 – Templates displayed under vSphere Web Client

If you browse the datastore where a template resides, you will find a corresponding folder just like any other VM. The folder will contain all the files associated with any standard VM. The one exception is that the VM configuration file has a .vmtx file extension instead of .vmx as per Fig. 4.

Figure 4 – A template folder and its contents as listed in datastore browser

Just for the heck of it, I unregistered a template from inventory; right-click and Remove from Inventory, renamed the .vmtx extension to .vmx and re-registered it as a VM. Surely enough, the resulting VM powered up with no apparent issues. This method is probably unsupported since the proper way to do this is to right-click on a template and select Convert to Virtual Machine. However, you never know when this might come in handy.

Preparing and converting a VM to a template

The process of finalizing a template is highly dependent on the VM’s guest OS and the intended use. Most likely, the guest OS will be some flavor of Linux or Windows. To prepare a template, you’d follow something along these lines:

1) Create a bare VM with the required hardware resources.

2) Power on the VM and access the BIOS. Press F2 while consoled to the VM and change the following:

a) Main Menu

Set Legacy Diskette A: to Disabled. This is disabled automatically when you delete the floppy drive while creating the VM (Customize Hardware).

b) Advanced Menu -> I/O Device Configuration

Set Serial ports A and B and the Parallel port to Disabled.

Set Floppy disk controller to Disabled.

c) Boot Screen

Move the Hard Drive to the top of the list using the – and + keys assuming you want the VM to boot from the virtual hard drive.

d) Press F10 to save and exit.

Figure 5 – Changing a VM’s BIOS settings

3) After you’re done with the BIOS settings, using the vSphere Web client or otherwise, right-click on the VM just created and:

a) Delete the floppy drive, if still listed, along with other hardware you won’t be needing.

Figure 6 – Deleting redundant hardware from a VM’s settings

b) Optional: Configure the VM to automatically check and upgrade VMware Tools and synchronize the VM’s guest OS time with the ESXi host.

Figure 7 – Setting a VM to check for VMware Tools and configuring it to time sync with its host

c) Optional: Configure the VM for CPU and RAM Hot Add which allows you to add CPU and memory resources to the VM while powered on. The Hot Add feature is supported on operating systems such as Windows Server 2008 R2 or later. Note that the location of some settings may differ from what’s shown depending on the vSphere client or version used.

Figure 8 – Adding hardware Hot Add capabilities to a VM

4) When you’re done configuring hardware, power on the VM and mount the guest OS ISO file. Install the Guest OS as you’d normally do. Some common steps are listed below. These mostly apply to Windows templates but some equally apply to Linux.

• Set the correct time zone, date and time.
• Install VMware Tools (Important!).
• Install any software you want included in the VMs deployed from this template.
• Install any missing OS updates, software and Security patches. Use Windows Update for Windows OSes. For Linux, you can use something like yum update.
• Choose a strong administrator password and set it to never expire. Doing this ensures you won’t get locked out of your VM. Yes, there are tools to unlock accounts and change passwords offline, but prevention is better than cure!
• Using services.msc, disable redundant services such as the ones for Audio and Wifi. For domain joined computers this can be handled via GPOs.
• Configure the network card to use DHCP and set the hostname to something generic such as Win7-template or Centos6-template.
• Run msconfig to enable/disable startup items, change UAC settings, etc. When setting up a Windows 10 VM or template, use Task Manager instead to manage start-up items.
• Clean up the OS use something like CCleaner or the Windows inbuilt Disk Cleanup. The following command is run from an administrative cmd prompt to reduce the size of WinSXS.

Dism.exe /online /Cleanup-Image /StartComponentCleanup

Figure 9 – Windows in-built Disk Clean-up tool

• If you have Windows based VMs that are not members of an Active Directory domain, run sysprep to avoid issues resulting from duplicate SIDs. This step is optional when applying a GOSC as it provides the same functionality; this is discussed further down.

Figure 10 – Finalizing a Windows VM with sysprep.

As per Figure 10, sysprep is configured to power off the VM once it’s done doing its thing. It is important that you do not power on the VM at this stage. Instead, right-click on the VM name and select Template -> Convert to Template. The same applies to Linux VMs. Use halt, poweroff or shutdown to power down the VM.

This is basically all there is to creating and configuring a VM prior to converting it as a template. I may have omitted a few steps since I cannot possibly cater for all the possible case scenarios. There are a ton of articles out there describing how to create templates for specific operating systems. Two such examples, for Windows Server 2008 and 2012 respectively, are available here and here.

In the case of Linux, make sure to check out this post since it highlights important stuff such as removing persistent udev rules and SSH keys, tackling MACs and UUIDs and how to zero logs.

Automating …

Now that your first template is ready, you can start provisioning VMs off of it. The only problem is that you will still need to manually set details such as the hostname and networking settings. This can become especially tedious when deploying multiple VMs. Is there a solution? Yes there is and it’s called guest OS customization where VM and OS settings are applied automatically during the provisioning process.

Jumping straight in, here’s how you would create GOSCs for Linux, and Windows using the vSphere Web client.

1) Click on the Home icon at the top of the screen, select Home and then click on the Customization Specification Manager icon.

Figure 11 – Accessing the Customization Specification Manager tool

2) Click on the Create a new specification icon and select either Windows or Linux.

Figure 12 – Targeting an OS type for customization

Creating a Linux GOSC

3) From the Specify Properties screen, assign a name and optionally, a description, so you can easily locate the GOSC when needed.

Figure 13 – GOSC – Properties screen

4) On the Set Computer Name screen, specify the hostname by which the Linux instance will be identified on a network. The hostname can be user-defined and/or suffixed automatically, set to match the VM name, entered manually during VM deployment or generated automatically using an application or script. The Domain name is obligatory.

Figure 14 – GOSC – Computer Name screen

5) On the Time Zone screen, select the time zone area and location and set the Hardware Clock to use UTC or Local time.

Figure 15 – GOSC – Time Zone screen

6) From the Configure Network screen, you can set the VM to use the default DHCP settings on all network cards. Alternatively, apply custom settings for both IPv4 and IPv6. The latter can be disabled altogether if it is not used.

Figure 16 – GOSC Network Configuration screen

7) Next, type in the IP address, or hostname, of a valid DNS server including a DNS search path. Both settings are optional when creating a Linux GOSC.

Figure 17 – GOSC DNS Settings screen

8) You can review the settings one last time and change any as required. Press Finish when done.

Figure 18 – Saving the GOCS

Once created, a GOSC can be edited at any time. You may also duplicate, export or delete it. A GOSC can also be imported from an XML file.

Figure 19 – Using the Customization Specification Manager in vSphere Web Client to manage GOSCs

Conclusion

Today, we’ve covered the basics on templates and closed off with a taste of automation. In the next part, I’ll cover the process of creating a Linux template and a corresponding GOSC which we’ll use to deploy and auto-configure Centos 7 based VMs. I will also demonstrate how to achieve the same result using PowerCLI.

[the_ad id=”4738″][the_ad id=”4796″]