Discussion Point: Practical usefulness of VM templates?

[jasonboche]

Something trivial has been on my mind off and on during the past few weeks. The value add for storing VMs as templates in VirtualCenter rather than simply leaving the VM gold image in VM mode and powered off at all times.

What is the advantage for converting a gold VM image into a template in VirtualCenter? As far as I can tell with everything else being equal (ie. shared SAN storage, network, etc.), both templates and non-templated VMs can be deployed into new VM copies with the option of running the guest customization afterwards.

The reason why I bring this up is that when using the Vizioncore esxRangerPro software in legacy mode to back up VMs, one cannot use the software to back up templates. You can back up VMs all day, but not templates. Granted, running in legacy mode should be an interim mode of operation with the long term goal being to get the VI upgrade to VI3 as quickly as possible so that VirtualCenter mode can be used. Nonetheless, the exposure still exists for as long as a company is running in legacy mode, templates cannot be backed up. The simple solution is of course to convert VirtualCenter templates into virtual machines that remain powered off. In that scenario, the templates that are in VM mode can be backed up in legacy mode and the templates that are in VM mode can still just as easily be used to deploy new VMs from.

So this raises the question, what is the significant advantage for creating templates? The procedure itself merely changes the file extensions of the VM and removes the VM from the Hosts and Clusters view in the VI client.

Jas

[JDLangdon]

Aren't templates stored in sparse format which makes the files size significantly smaller then a monolithic VM?

Also, since a template cannot be powered on, you can be 100% sure that the "Golden Master" doesn't get changed by mistake or no additional middleware gets added without proper approval.

Jason

[jasonboche]

I haven't noticed disk space savings. I've got 4 "golden" VMs. Each one has a .vmdk sum total size that is roughly 12GB whether it's a VM or a template. The amount of disk space consumed seems to remain the same but that is something I will double check. If templates are significantly smaller than their virtual machine counterparts, then I could see this as a distinct advantage for those who have higher numbers of templates on valuable SAN storage. The more templates a person has, the more savings there is to be had by running in template mode.

As Brian mentioned, some people need to power on their VMs for updates on a regular basis. On the other hand some don't.

On the issue of security, if we can't set the granular permissions in VirtualCenter required to keep things locked down, or if we have cowboy administrators not abiding by the rules, then we've got some problem areas to address. Frankly, I think the fact that a VM is in template mode is just a small roadblock for a rogue administrator. One mouse click gets the adminstrator around that roadblock.

[lusid]

I think you have to "Clone to template" to get the space reduction.

[JDLangdon]

Frankly, I think the fact that a VM is in template mode is just a

small roadblock for a rogue administrator. One mouse

click gets the adminstrator around that roadblock.

By throwing one extra step into the mix, the "cowboy" administrator not only has to convert the template into a VM, he/she also has to convert the VM back into a template. Over the years I've come to realize that the incompetent are also lazy. :smileywink:

Jason

[bowulf]

The amount of disk will be different only if you selected compact vs. normal storage. The normal allows you to immediately turn on the Virtual Machine, but the Compact requires time to convert back into the startable VM format. I prefer the Template only because it is easier to explain to other non-Vi3 admins than a golden VM. I know it isn't a perfect solution, but I have a suspicion my Golden VMs would eventually be renamed and used for production.

[admin]

As Jason said, one of the advantages is the option to compress the disks to save space.

I have more and more customers these days just keeping the Golden Master VM, as a matter of fact many keep it powered on so it will get update pushes.

$0.02

[gogogo5]

I find the following useful when using Templates:

1. It automates the sysprep procedure as part of a new server deployment, something that could get overlooked if a new VM deployed manually.

2. When we deploy from a Template we are prompted for the VM name which then can be used to create the vmdk files with the same name. Non-templated VMs will inherit the vmdk name of the original. Therefore again, using templates automates this rather have having to hack around with vmx files etc. We like to have vmdk names the same as the VM name, for obvious reasons.

[FredPeterson]

Er...the way I do it is to create my master Base image with whatever base apps, windows updates etc, that are needed...sysprep it and instead of telling it to reboot on the final steps, just tell it to shutdown.

Clone that base, the cloning process asks for a new name, when it fires up sysprep asks for the Windows host machine name....and we're off the races.

Templates seem like an extra step in the process...

[gogogo5]

Using a template in conjunction with the customisation wizard you do all the "filling in" up front then click deploy and walk away. Sysprep, server renaming, Volume License Key entering (which we use anyway) etc is all automatic so when you get back from your next meeting the VM is up and ready to go.

Using a clone, why wait for sysprep to kick-in and wait for you to complete the mini-setup wizard?

[jasonboche]

I'm not following you.

Deploying via template or clone, the guest customization wizard is available for both deployment options. All of the benefits in the guest customization wizard such as running sysprep, naming the VM, network settings, etc. are all there.

Jas

[gogogo5]

I was referring specifically to the process that FredPeterson used whereby when cloning an install of Windows you would run sysprep then shutdown the server, image it and deploy on another server. When you start that server up sysprep's mini-setup wizard kicks in and prompts you for some information.

Maybe it was the way I interpreted FredP's post in that he didn't use the customisation wizard but just manually did the sysprep things when the server first boots.

Either way, you are correct in that you can use the customisation wizard with both clones and templates.

[Jwiedow]

Using a template in conjunction with the

customisation wizard you do all the "filling in" up

front then click deploy and walk away. Sysprep,

server renaming, Volume License Key entering (which

we use anyway) etc is all automatic so when you get

back from your next meeting the VM is up and ready to

go.

Using a clone, why wait for sysprep to kick-in and

wait for you to complete the mini-setup wizard?

Not so with 64-Bit Windows 2K3 but that may be nit-picking at this point.

All in all a great thread -- I love it when the usefulness of things get the devils advocate treatment!

[Monoman]

Well here is one advantage of templates over "golden images".

Today I deployed a VM from my Win2K3 R2 template and installed SP2, critical updates, etc. I then converted the new VM to a new template. Now I have a new template for Win2K3 SP2 as well as the old template.

It just seems easier to me. As well it avoids having someone accidentally turning on a "golden image" VM.

[jasonboche]

Touche'

One of our newer administrators destroyed a template this week by accidentally converting it to a VM and then building it out.

Beyond the scenario above, from a feature standpoint, I don't see much of a difference between the two. I also haven't seen the disk savings that templates offer. We don't have many templates so LUN/disk space conservation isn't a priority for me.

[jhicks]

A couple things I can think of why templates might be beneficial:

\- For HA / Host Restarts, there is no way a Template will get "turned on"

\- In large organizations (or maybe even small), you may have administrative roles delegated as granular as those responsible for only "golden images." Template managers can be given permissions to maintain these images, but not deploy new VM's... they can only promote Templates back and forth. Then another admin role for VM deployments can be granted permissions to deploy from template only (not Clone, or Create VM), etc. While I think this can also be acomplished with clones, IMHO the permissions are much cleaner delegating Template rights.

\- For golden images that do have vast amounts of disk space allocated (but not used), the ability to compact a template clone is invaluable. For instance, your developers may have the permission to create a new VM (from a template), but you do not wish them to have the ability to change any system parameters (memory, disk, etc). Their template image can have everything they need, yet be relatively small, freeing disk resources for other needs.

\- Inventory reporting. Templates should be excluded automatically from inventory reports, versus having to filter them out if they were normal VM's. Reporting on templates alone is also easier, just looking for the template flag, not some arbitrary naming standard.

\- Scheduled deployments. Since Templates can't be turned on, if you have a scheduled task to deploy a new VM, this should have a low failure rate. Scheduled clones cannot be accomplished with always-on "golden image" VM's. Scheduled clones could still be made to work, with multiple tasks (power off task, clone task, power on task), but this is certainly not as clean.

Regards,

J