Sinisa Botas - Fotolia
VMware templates have been saving administrators precious time during the deployment of new applications and virtual machines for several years now.
Essentially, a template is a master copy of a virtual machine (VM) -- preferably, one that is completely up to date in terms of security patches, has all of a company's standard software installed and configured, and has been set up to provide optimal performance in a virtualized environment. Since the point of a template is to provide a base for provisioning many VMs, it's best to keep them performing at an optimal level.
By ensuring that the VMware templates are all up to snuff, administrators can save themselves tons of time and headaches down the road. Over the years, I've built plenty of templates. The following are a few best practices and techniques I've come across to get the maximum performance out of them, as well as the VMs that are provisioned afterwards.
Use snapshots and remove unnecessary devices
In order to get the most out of templates, you should constantly update and take care of them. In any case, you don't want to be that person who accidentally misconfigures or corrupts your company's "golden image" to a point where it can't be recovered. Using a snapshot is one way to help you keep things up and running. Snapshots are a great way to ensure that you will be able to roll back any unintentional changes you make while maintaining your templates. Just be sure to commit or delete your snapshots before converting VMs back to a template, as it greatly increases provisioning times when they exist.
Removing devices that aren't present or needed is a no brainer. When you first create a VM, the default is to create a floppy drive and a serial port, which are two items that are rarely used. If you never plan on using them, remove them from the templates' configuration. You can always re-add these devices on a per-VM basis, if need be. Also, use the 'set devmgr_show_nonpresent_devices=1' command before opening device manager to show nonpresent devices. These are devices that are installed, but not present. Some of these are not needed, so you can get rid of them.
Use the latest virtual compatibility mode
This tip is a little more tricky than the others. On one hand, it's nice to keep our compatibility mode up to date with our environment to gain access to all the new maximums and features within the latest version of ESXi. On the other hand, consider where else you may use this template. Don't upgrade to 5.5 if the possibility of deploying this template to an ESXi 5.0 host exists. It's important to pick and choose when you want to use the latest compatibility mode.
Consider valid VM configuration options
Be sure to consider all the configuration and advanced configuration items inside a VM. For instance, CPU Hot-Add and Memory Hot-Plug are disabled by default. This is something that you might want to turn on within your template, as having to do it later on a VM will not be possible unless the VM is powered off. Just because it is disabled by default doesn't mean it needs to stay that way.
Pay attention to storage
If capacity is an issue within your environment, you can definitely take advantage of vSphere's thin provisioning, as it pertains to template storage. By creating your templates thinly provisioned, they will only consume as much data store space as they have data within the VMDK. A great way to save more space is by using a lot of templates. Also, consider storing all of your templates on their own data store. This way, during deployment, you will have all read I/O isolated to your template data store, with the production or target data store handling the write I/O. It's important to note that if you are using Windows Server 2003 or below, make sure to align your storage when formatting those Windows drives. A misaligned template will lead to a misaligned deployed VM, which can result in a sizeable performance hit.
Keep the OS and applications patched
There is nothing more monotonous than deploying a VM from a template within minutes, and then having to spend hours performing Windows updates. Take that time that you would normally use updating the OS on the VM and apply it to your template. Better yet, set up a recurring event within your calendar to block off time to keep your templates up to date. Don't forget about other applications, such as Adobe, Java, VMware tools and others, as those will also need to be updated. Also, you might want to consider isolating or limiting network access to the template during this process in order to minimize the chances of being infected by something.
Base load of applications
Aside from installing, configuring and patching an OS inside a template, you can also use this functionality to provide a base server load of applications. If you have software that you install on every single server -- applications such as 7-Zip, PowerShell and Antivirus -- you might want to think about adding these to your templates. This will ensure that every VM deployed from that template will have these applications installed and configured in a consistent fashion.
There are many options when it comes to tweaks and settings within Windows and Linux that can be enabled or disabled in order to better the performance of your VMs. Aside from using Sysprep, there are a handful choices that I always ensure are set within my templates .
- Enabling and configuring remote desktop protocol (RDP).Depending on your security initiatives, you may want to go ahead and enable remote desktop, and specify a subset of users who have the ability to RDP into your servers.
- Deploying and setting up WinRM, which can be helpful when you want to manage your hardware and OS remotely, and/or initiate localized PowerShell sessions. Again, this will all depend on any security guidelines you have implemented. Use the command line 'winrm quickconfig' for default options or 'winrm help' for further options.
- I've been changing the startup options in Windows for years on my physical servers. Lowering the time to display list of operating systems and disabling the auto-restart on failure are a couple of options that I always apply to templates.
- The last thing we need is for a Windows machine to sleep or hibernate. I always select the 'High performance' option in Power Options, and even go as far as editing that plan to ensure the display will never be turned off.
- There is really no point in having a number of old events deployed to every single VM we deploy from this template. Go ahead and clear them as a last step before converting to a template.
- Clearing out the YUM/Apt cache of all those installed patches is always a good idea.
- Many times, if you just package up your Linux VM as a template without clearing the existing udev device rules, you will find that your new NIC will show up as eth1. You can stop this by removing any udev persistent device rules with the command line 'rm –f /etc/udev/70*'.
- Obviously, security is always a big issue. SSH keys can be used to perform 'login-less' authentication, so having multiple VMs with the same keys available can be a bad thing. Remove them before packaging as a template. Use the command line 'rm –f /etc/ssh/*key*'.
- Just as we dumped Event Viewer in Windows, we can do the same thing inside of Linux by rotating and clearing logs. First, run 'logrotate' to start a fresh log, and then go ahead and use 'logrotate –f /etc/logrotate.conf' to deal with any old logs you don't think you will need.
The importance of having clean, efficient and up to date VMware templates should go without saying. Often, IT organizations will deploy hundreds, if not thousands of VMs based off one image. And ensuring that image meets security compliance, contains the standard tools and performs at its fullest is essential to the success of those deploying it. We certainly haven't covered everything that can be tweaked within a Linux or Windows template, so if you have any other ideas, I'd encourage you to leave a comment below.