What are Virtual Machine Templates?

In vSphere, Virtual Machine Templates are:

  • Virtual Machines that cannot be powered on
  • Virtual Machines that cannot be modified

Templates are like gold images, you create a template and deploy multiple VMs from them. Templates configuration files use an extension VMTX (virtual machines configuration files have an extension VMX). There are two easy ways to create a template:

  1. Clone an existing virtual machine (VM) to a template.
    – Creates a copy of an existing VM and registers it as a template.
  2. Convert an existing VM to a template.
    – Unregisters existing VM and registers it as a template.

Workflow for modifying a template:

  1. First convert the template to VM
  2. Optionally, make changes to the VM hardware (increase RAM, disk size etc.)
  3. Power-on the VM and install any new applications or updates
  4. After installing the application and updates, shutdown the VM
  5. Now convert the VM back to a template

Deploying Virtual Machines from Templates and Guest Customization:

When virtual machines are deployed from the template, they will identical to the template, things such as Windows-SID and hostnames would same. If using static IPs, those would also be same. This can create software and network conflicts.

To avoid such network or software conflicts, its recommended to customize the VM Guest during the deployment process. For Guest OS customization of virtual machines deployed from templates, vCenter requires the following:

  • If the guest OS is Windows, you need VMware Tools and Sysprep utils to be installed within the templates:
    • You will need to copy Sysprep tools to vCenter for Windows 2000, XP & 2003. Starting with Windows Vista onward, Sysprep tools are part of the base OS install. Where to copy Sysprep utils, read the following KB#1005593 article
  • For Linux VMs/Templates, along with VMware toools, you will also need Perl to be installed within your templates.

Best Practice: Always create templates for powered off virtual machines. Do not clone templates from a powered on virtual machines.

vCenter Install Issues on Windows 2008

Last week, I was installing vCenter Server 5.5 on a Windows 2008 virtual machine and it used to fail. It seems that vCenter SSO would not install correctly on a machine which has multiple NICs. (Interestingly the vCenter 5.1b installed without any issues on the same setup.)

Here is the exact scenario. My (virtual) machine in question had 3 NICs.

NIC1 10.40.40.111 (NATed Network with internet access)
NIC2 10.40.41.111 (Internal Network)
NIC3 10.40.42.111 (Internal Network)

The issue was, I wanted the vCenter SSO (and vCenter and other components) to bind to NIC2 which connected to an internal network. My DNS server also resides on the same network, and the DNS forward lookups and reverse lookups were correctly configured.But still vCenter SSO installation would always fail. During the install of SSO, I used to select the “hostname” instead of IP Address, and the vCenter SSO would get bound to wrong IP/NIC combo. I changed the adapter priorities but with no success. Insetad of using the hostname, I also tried using the IP Address but with no luck.

Finally, I disabled both the adapters which I did not want to be selected by vCenter SSO, and then did the entire vCenter Server installation. After installation, I checked the access to the vCenter via the Webclient, added a couple of hosts and it all worked. After this, I then re-enabled the disabled NICs and the vCenter Server continued to play nicely.

Moral of the story, if you have a windows machine (physical/virtual) with multiple NICs to be used as a vCenter Server. During the vCenter installation disable the NICs that you do not want vCenter Server to bind to. Complete the install, reboot the machine, and re-enable the disabled NICs.

What really makes me think is during vCenter SSO install, why can’t the install wizard pop a dialog to the user to select the appropriate NIC card for network binding? The current installer behavior is not at all user friendly. This is a classic usability issue that you must avoid. Over engineering for auto-selection of a NIC during install, can be easily fixed by a simple dialog box. Less code to write and audit, gives you less bugs. Keep it simple.

This issue was observed on vCenter 5.5 build#1312299. I was using the vCenter installer ISO for setting up (VMware-VIMSetup-all-5.5.0-1312299.iso). I believe there were a few KB articles that talked about this. Unable to find those articles now.

And yes, I was not using a simple install, i was using a component based installed.

Well and I also want to thank my friend and colleague Atul Bothe, who actually identified a workaround to this issue. Thanks Atul! 🙂