VMware ESXi and vSphere Cluster Management

Create and Manage Virtual Machine Templates in VMware vSphere

Learn how to create VMware vSphere VM templates by converting or cloning virtual machines, choose disk provisioning formats, verify results, and maintain templates safely.

A VMware virtual machine template is a reusable master image for creating consistent new virtual machines. It can contain a predefined guest operating system, virtual hardware definition, virtual disks, installed applications, VMware Tools, and baseline configuration.

Templates are normally kept as deployment sources rather than active workloads: they are not usually powered on for normal production use. By deploying from a validated template, administrators can provision systems faster, standardize builds, reduce configuration drift, and repeat deployments reliably.

Prerequisites and planning

Before creating a template, make sure the environment and source virtual machine are ready.

Centralized management: The source VM must be managed through vCenter Server in the vSphere Web Client. Review adding an ESXi host to vCenter Server inventory if the host is not yet connected.
Permissions: Your account needs privileges to clone or convert the VM, create or modify template inventory objects, place objects in the target folder or datacenter, select hosts or clusters, and write to the destination datastore. See assigning permissions for role-management guidance.
Golden image: A golden image is a prepared and validated source VM. Patch the operating system, install required software, remove unwanted files, validate the configuration, and confirm that the VM is suitable for repeated deployment.
Source retention: Decide whether the original VM must remain available. This determines whether you should clone it to a template or convert it directly.
Consistent shutdown: Shut down the source VM before conversion or cloning when filesystem consistency and application consistency matter. A powered-off source avoids capturing active writes or an application in an inconsistent state.
Guest customization: Plan how deployed VMs will receive unique hostnames, network identities, operating-system identities, and other per-VM settings. Windows images may require Sysprep preparation, while Linux customization depends on supported guest and vSphere settings. The guest OS customization process should be tested before broad deployment.
Storage: Check datastore capacity before starting. Thick-provisioned disks can consume their configured capacity immediately, and thin disks can grow substantially after deployment.

Clone to Template versus Convert to Template

vSphere provides two related but materially different methods.

Whether the original VM remains available
Clone to Template: Yes, the source VM remains a separate VM.
Convert to Template: No, the selected VM becomes a template.

Whether a separate template is created
Clone to Template: Yes, a new template object is created.
Convert to Template: No, the existing VM object changes into a template.

Whether a wizard is used
Clone to Template: Yes. The wizard collects identity, inventory, compute, datastore, and disk-format choices.
Convert to Template: The conversion action is confirmed without the clone placement and disk-format workflow.

Ability to choose target storage
Clone to Template: The destination datastore can be selected in the workflow.
Convert to Template: The existing disk files remain where they are.

Ability to choose disk provisioning format
Clone to Template: The wizard can offer Same format as source, thin, or thick options.
Convert to Template: No new disk-format choice is offered.

Best use case
Clone to Template: Use when the source VM must be retained for testing, rollback, or another purpose.
Convert to Template: Use when the source VM is no longer needed as an independent, runnable VM.

Effect on source VM disk files
Clone to Template: A template copy is created, and the source files remain associated with the original VM.
Convert to Template: The existing disks are retained in their current format and become part of the template.

Convert a virtual machine into a template

Open the vSphere Web Client and go to the VMs and Templates inventory view.
Select the intended source virtual machine.
Open the vCenter actions menu, commonly labeled All vCenter Actions.
Choose Convert to Template.
Confirm the operation when prompted.
Check the inventory and verify that the object is represented as a template rather than as a virtual machine.

Conversion changes the selected VM into a template. The original VM is not retained as a separate deployable VM object. Its existing virtual disk files stay in their current provisioning format; conversion does not provide a disk-format selection step.

For example, if a one-time Linux build VM is fully patched, generalized, and no longer needed as a runnable system, converting it can turn that existing build into the baseline template without creating another disk-format selection workflow.

Clone a virtual machine into a template

Open the VMs and Templates inventory view.
Select the source virtual machine.
Open All vCenter Actions.
Choose Clone to Template.
Enter a meaningful template name.
Select the destination datacenter, folder, or other inventory location.
Select the destination host or cluster when the placement workflow requests compute resources.
Select the destination datastore.
Choose the virtual-disk provisioning format.
Review the summary carefully and submit the task.
Verify that the new template appears in inventory and that the original VM still exists.

A useful naming pattern includes the operating system, release, intended role, and revision. For example: tmpl-win2022-app-v2026-08 or tmpl-ubuntu24-web-r02. Use the actual organizational naming standard consistently.

For a tested Windows application-server baseline that must remain available, cloning is the safer choice. The source VM remains intact, while the resulting template can be placed in a controlled templates folder and stored on a datastore selected for capacity and accessibility.

Virtual disk provisioning formats

During Clone to Template, the wizard may ask how the destination virtual disks should be provisioned. Provisioning affects storage consumption, creation time, write behavior, and the risk of datastore exhaustion.

Same format as source
Initial datastore consumption: follows the source disk format.
Zeroing behavior: follows the source format.
Creation-time impact: generally avoids changing the provisioning type.
Capacity planning: evaluate the source format and its growth behavior.
Typical use: preserve an already approved storage design.

Thick Provision Lazy Zeroed
Initial datastore consumption: the full configured capacity is reserved at creation.
Zeroing behavior: blocks are zeroed when they are first written.
Creation-time impact: usually faster than eager-zeroed creation.
Capacity planning: the full configured size must be available immediately.
Typical use: workloads needing reserved capacity without the creation-time cost of pre-zeroing every block.

Thick Provision Eager Zeroed
Initial datastore consumption: the full configured capacity is reserved at creation.
Zeroing behavior: all blocks are zeroed while the disk is created.
Creation-time impact: longer creation time and greater initial I/O activity.
Capacity planning: the complete disk size must be available before creation begins.
Typical use: workloads or storage designs that specifically require eager-zeroed disks.

Thin Provision
Initial datastore consumption: starts near the amount of storage needed for existing disk content and metadata.
Zeroing behavior: storage is consumed as blocks are written.
Creation-time impact: commonly faster and less storage-intensive initially.
Capacity planning: the configured maximum size can eventually be consumed, so overcommit risk must be monitored.
Typical use: efficient storage utilization when growth and free capacity are actively monitored.

Thin provisioning does not remove the disk's configured maximum size. If a thin disk is configured for 500 GB, guest writes can eventually cause it to consume close to that amount. Thick provisioning reserves capacity earlier, reducing uncertainty but requiring sufficient free space up front.

Verify the completed template

Locate the template in the VMs and Templates inventory.
Review the task or recent-task status for completion or failure.
Confirm the template name and inventory folder.
Verify datastore and compute placement.
Where applicable, verify the selected disk provisioning type.
Confirm that the source VM remains or no longer remains according to the selected method.
Optionally deploy a test VM from the template and validate bootability, expected software, networking, and guest customization.

A test deployment is especially valuable after changing the operating system, applications, disk format, customization specification, or template placement.

Updating an existing template

Templates are not permanently finished images. They require maintenance for operating-system patches, security fixes, VMware Tools updates, application updates, and approved configuration changes.

Method 1: Convert the template back to a VM

Convert the template back to a virtual machine using the available vSphere action.
Power on the VM and apply the required patches, tools, applications, and configuration changes.
Test the updated image.
Shut down the VM cleanly.
Convert the validated VM back to a template.

This method directly updates the existing template identity, but it temporarily removes the template from its normal usable state and may affect deployments that expect the old version.

Method 2: Preserve the original while performing maintenance

Clone the existing template to a VM, or deploy a maintenance VM from it.
Apply updates and configuration changes to the maintenance VM.
Validate boot, applications, networking, and guest customization.
Create a replacement or updated template from the validated VM.
Deploy a validation VM from the new template.
Retire the old template only after the new version is approved and dependencies are understood.

Use versioned names such as tmpl-ubuntu24-web-r02, document what changed, record patch status and ownership, and mark superseded templates as retired rather than leaving ambiguous copies in inventory.

Template operational practices

Use names containing operating system, version, role, and revision date or version.
Keep templates minimal: install only the software and settings that should be common to every deployment.
Do not embed machine-specific hostnames, IP addresses, certificates, credentials, API keys, or other secrets.
Use guest customization specifications for per-VM identity and network settings after deployment.
Track the owner, patch level, lifecycle status, approved use case, and change history.
Limit template modification permissions because one template can influence many future systems.
Retire superseded templates and clearly identify the currently approved revision.

Creation and maintenance checklist

Before creation
Required check: Validate the golden image, shut it down when consistency matters, plan customization, confirm permissions, and check datastore capacity.
Why it matters: Prevents inconsistent deployments and failed placement or storage tasks.

Method selection
Required check: Decide whether the source VM must remain available.
Why it matters: Clone preserves the source; convert changes the source into a template.

Storage selection
Required check: Select a datastore and provisioning format appropriate for capacity, performance, and workload requirements.
Why it matters: Thick disks reserve capacity, while thin disks can grow and cause unexpected exhaustion.

Post-creation validation
Required check: Inspect inventory, recent tasks, placement, disk format, source retention, and a test deployment.
Why it matters: Confirms that the intended template was actually created and can produce a usable VM.

Template update
Required check: Patch and test a VM, publish a versioned replacement or reconverted template, and validate it before broad use.
Why it matters: Keeps future deployments secure and predictable.

Retirement
Required check: Document and retire superseded templates after confirming that no approved deployment process still depends on them.
Why it matters: Prevents administrators from deploying obsolete or unsupported images.

Troubleshooting common problems

The template actions are unavailable

Likely causes include connecting directly to an ESXi host instead of using vCenter Server, missing inventory, VM, datastore, or provisioning privileges, or selecting an object that is not an eligible virtual machine. Confirm that the VM is visible in vCenter-managed inventory, review permissions at the VM, folder, datastore, and destination levels, and select the correct VM in the VMs and Templates view.

Creation fails during datastore or format selection

Check free datastore capacity and remember that a thick disk requires its full configured capacity immediately. Also verify that the selected storage is accessible to the destination host or cluster. Choose a suitable provisioning format or a datastore with enough capacity.

The original VM is missing

This normally means Convert to Template was selected. Conversion changes the VM into a template rather than retaining a separate VM. Use Clone to Template when the source must remain available.

A new disk format cannot be selected

Conversion preserves the existing disk files and format. Use Clone to Template when the resulting template needs a different disk provisioning type.

Deployed VMs have duplicate identities or network settings

The image may contain machine-specific configuration, or guest customization may not have been configured or applied. Generalize the source appropriately, remove fixed identities and secrets, and use supported guest customization settings during deployment.

Thin-provisioned storage unexpectedly fills

Thin disks consume more datastore space as guests write data. Monitor usage and growth trends, plan for the configured maximum size, and use thick provisioning when reserved capacity is required and available.

Exam-relevant distinctions

Clone to Template creates a separate template and preserves the source VM.
Convert to Template changes the selected VM into a template; the source is not retained as a separate VM.
Clone to Template provides placement and disk-provisioning choices; Convert to Template retains the existing disk format.
Thin provisioning starts with lower storage consumption but can grow to the configured maximum and creates datastore overcommit risk.
Thick Provision Lazy Zeroed reserves capacity immediately and zeros blocks on first write.
Thick Provision Eager Zeroed reserves and zeros all capacity during creation, so creation takes longer.
Guest customization is needed to give deployed systems unique identities and per-VM settings.

For broader context, review the VMware ESXi online course, creating a VMFS datastore, and the vSphere access control system.