VMware ESXi and vSphere Cluster Management

Update a VMware vSphere Virtual Machine Template

Learn how to safely convert a VMware vSphere template to a VM, patch and modify the guest, validate it, and convert it back into a reusable template.

A VM template is a master virtual machine image used to deploy new virtual machines with a standardized operating system, software set, and configuration. Templates help administrators distribute consistent systems without rebuilding each VM manually.

Because a template is normally not powered on directly, maintenance follows a specific lifecycle: convert the template to a virtual machine, perform guest updates, validate the result, shut down the VM, and convert it back to a template.

Why Maintain a VM Template?

Templates become outdated as operating systems, applications, security requirements, and organizational standards change. Regular maintenance lets you incorporate:

• Operating system security patches and approved feature updates.
• Security fixes and endpoint protection updates.
• Required applications, utilities, agents, drivers, and libraries.
• Updated VMware Tools and guest integration components.
• Certificates, policies, baseline settings, and approved configuration changes.
• Cleanup procedures that remove temporary files and deployment-specific data.

Keeping templates current reduces the work required immediately after deployment. A newly deployed VM starts closer to its desired state, which reduces patch windows, improves consistency, and lowers the chance that different administrators build systems with different software versions.

A template is not normally a running guest. To change its operating system or installed software, use the vSphere Client to convert to virtual machine. This changes the inventory object into an editable VM that can be powered on. After maintenance, use convert to template to return the powered-off VM to reusable template form.

Template Update Workflow

Plan the Maintenance Before Changing the Template

Identify the image and update scope

Record the template's current name and version, operating system, intended workload, and owner. Define exactly what will change. For example, a Windows Server template may require the latest approved operating system patches, a new monitoring agent, updated VMware Tools, and a revised security baseline. A Linux template may require a package update, a service configuration change, and removal of old package caches.

Do not treat every template as interchangeable. A template intended for a database server may need different storage, monitoring, security, and application settings from one intended for a web server.

Confirm change and rollback requirements

Check the maintenance window and any change-control or approval requirements. Decide how the previous image will be recovered if validation fails. Possible safeguards include a backup, a clone, or a versioned copy of the original template. A snapshot can support short-term rollback during a controlled change, but it is not a substitute for a backup and should not be retained indefinitely.

Document which copy is the approved rollback source. Avoid making an irreversible change to the only usable version of a production deployment image.

Check access, capacity, and compatibility

The administrator needs vCenter inventory permissions for the relevant template and VM, template conversion, VM configuration, power operations, datastore access, and the guest update process. Exact privileges depend on the vCenter role design. If an action is unavailable, ask a vCenter administrator to review the assigned role and object permissions.

Before conversion, confirm:

• A suitable ESXi host or cluster has sufficient CPU and memory capacity.
• The destination has access to the VM's datastore and required virtual disks.
• The selected host supports the VM's virtual hardware and guest operating system.
• The intended network or isolated maintenance port group is available.
• Planned software, VMware Tools, drivers, and virtual hardware are compatible with the destination environment.
• Licensing and placement policies permit the temporary VM to run on the selected host or cluster.
• There is enough datastore space for the VM, update files, logs, and any approved temporary copy.

Convert the Template to a Virtual Machine

Use the vSphere Client, the web-based vSphere administration interface, to locate and convert the template.

1. Open the vSphere Client and browse the inventory to the existing template.
2. Confirm that the selected object is the intended template and review its current details.
3. Open the template's actions menu and choose the action to convert it to a virtual machine.
4. When prompted for placement, select a suitable cluster or ESXi host for temporary execution.
5. Review the destination, datastore, compatibility information, and any task warnings.
6. Submit the conversion task and monitor Recent Tasks until it completes.
7. Verify that the inventory object is now displayed as a VM rather than a template.

An ESXi host is a bare-metal VMware hypervisor that runs virtual machines. A cluster is a group of ESXi hosts managed together for resource management and availability features. Choose placement based on available resources, host compatibility, datastore access, network availability, and applicable licensing or placement policies.

Prepare the Temporary Update VM Safely

Before powering on the converted VM, review its configuration. Check the CPU, memory, virtual disks, network adapters, boot order, firmware mode, virtual hardware version, and datastore placement. Preserve settings needed by future deployments, but change temporary settings that could expose or duplicate the source system.

Control the network

An isolated network is a restricted network segment that prevents a maintenance VM from affecting or being accessed by production users and systems. Use an isolated or restricted port group when the guest needs network connectivity for updates. If network access is unnecessary, disconnect the virtual network adapter and use an approved offline update method.

Be particularly careful when the image contains a static IP address, production-like hostname, domain membership, certificates, scheduled tasks, or services that automatically start. A temporary VM could conflict with the original system or register itself with monitoring, backup, directory, or application services.

• Attach the VM to a restricted maintenance port group.
• Disconnect the network adapter before booting if offline maintenance is practical.
• Use temporary firewall rules and access controls that allow only required administration and update traffic.
• Do not connect a duplicate identity directly to a normal production network.
• Preserve the settings that should exist in the final image, but ensure deployment-time customization will assign unique identity values.

Guest customization is deployment-time configuration for a cloned VM, such as its hostname, network settings, identity details, or domain membership. Confirm that future deployments will receive unique values rather than inheriting the maintenance VM's identity.

Power On and Update the Guest

1. Start the converted VM from the vSphere Client after confirming its network and hardware settings.
2. Open the VM console or an approved remote management session.
3. Allow the guest operating system to boot normally and authenticate with an approved maintenance account.
4. Install operating system security updates and approved patches using the operating system's normal patch process.
5. Install or update required applications, utilities, endpoint protection, monitoring software, drivers, and organizational configuration.
6. Update VMware Tools when appropriate for the guest and destination environment.
7. Apply required certificates, policies, baseline settings, and cleanup procedures.
8. Restart the guest when updates require it. Continue checking until all required reboots and update operations are complete.

VMware Tools is guest integration software that supplies drivers and management capabilities such as improved device support, time synchronization, and guest information used by vSphere. Use a version approved for the guest operating system and your vSphere environment. After updating it, verify that expected guest integration functions work.

Windows Server template example

1. Convert the Windows Server template to a VM and place it on a suitable maintenance host.
2. Connect it to a restricted network or disconnect the adapter if approved offline patching is available.
3. Install the organization's approved Windows updates and reboot as required.
4. Update VMware Tools if required, then verify the VMware Tools service and guest integration.
5. Update endpoint protection, monitoring software, and approved server utilities.
6. Remove temporary update files and test data, then verify the patch status.
7. Shut down cleanly and convert the VM back to a template.

Linux application template example

1. Convert the Linux template to a VM and boot it on a compatible host.
2. Use the approved package management process to install the required application and supporting packages.
3. Apply the required service configuration and verify the installed package version.
4. Start or test the service only in a restricted environment, ensuring it cannot reach unintended production systems.
5. Remove environment-specific artifacts, temporary credentials, package caches, and test data as required.
6. Shut down the VM and return it to template form after validation.

Validate the Updated Template Candidate

Do not convert the VM back to a template immediately after the last reboot. First verify that the candidate image is healthy and safe to clone.

Remove temporary credentials, installation media, test files, update caches, temporary logs, and environment-specific settings when they should not be inherited. Review certificates, private keys, API tokens, SSH host keys, stored credentials, and application registrations according to your security policy.

Confirm that the image will not introduce duplicate network or system identity after deployment. If the template contains static network settings or domain configuration, verify that the deployment workflow replaces them appropriately.

When practical, deploy a test VM from the candidate template in a non-production environment. Check boot behavior, guest customization, network identity, application startup, monitoring registration, and security controls. Keep the previous template available until the test deployment is accepted.

Shut Down and Convert the VM Back to a Template

1. Finish all guest updates, cleanup, tests, and required reboots.
2. Perform a clean shutdown from inside the guest operating system. Do not rely on an abrupt power-off unless the guest is unresponsive and the recovery process requires it.
3. In the vSphere Client, verify that the VM is fully powered off.
4. Check Recent Tasks and confirm that no update, reboot, snapshot, datastore, or configuration operation is still active.
5. Select the powered-off VM in the inventory and open its actions menu.
6. Choose the vCenter action to convert the VM to a template.
7. Monitor the task until it completes.
8. Verify that the inventory object is displayed as a template and can be selected as a deployment source.

A snapshot is a point-in-time record of VM disk and configuration state. If one was created for short-term rollback, follow policy for its removal after validation. Do not leave unnecessary snapshots attached to a template candidate because they consume storage and complicate lifecycle management.

Post-Update Management

Document the completed change so administrators can identify and support the image. Record at least:

• Template name and version.
• Update date and maintenance window.
• Guest operating system and patch level.
• Installed software, agents, drivers, and VMware Tools version.
• Important baseline, certificate, policy, and cleanup changes.
• Validation results and test-deployment details.
• Approver, change record, and rollback source.

Use a naming and versioning convention that clearly distinguishes current, previous, and deprecated templates. For example, a name can identify the workload, operating system, and release version, while documentation records the patch date. Avoid ambiguous names such as latest when multiple administrators need to determine exactly which image was deployed.

Retain or remove the old template according to the rollback and retention policy. A previous version may be valuable during a transition, but obsolete templates also create security, storage, and operational risk. Schedule regular reviews for operating system patching, application lifecycle changes, VMware Tools updates, and baseline revisions.

Troubleshooting

The conversion action is unavailable or fails

• Likely causes: insufficient vCenter privileges, an active task or lock, or an object state that does not meet the conversion requirement.
• Resolution: review permissions and the assigned role, inspect Recent Tasks, confirm the object is selected from the correct inventory location, and verify that it is in a valid stable state before retrying.

The converted VM cannot be powered on

• Likely causes: insufficient host or cluster resources, an incompatible ESXi host, missing datastore access, or invalid VM configuration.
• Resolution: choose a compatible host or cluster, verify datastore visibility and VM file access, check capacity, and review the detailed configuration error shown by vSphere.

The maintenance VM causes network conflicts

• Likely causes: duplicate IP address or hostname, an existing domain or service identity, or production agents starting automatically.
• Resolution: disconnect the adapter or use an isolated network before booting, control services that should not run during maintenance, and verify that deployment-time customization will assign unique identity settings.

The VM cannot be converted back into a template

• Likely causes: the VM is still powered on, guest shutdown has not completed, or a task, snapshot operation, or configuration change is active.
• Resolution: perform and verify a clean shutdown, wait for active operations to finish, confirm the VM is fully powered off, and retry the conversion.

New VMs have unexpected settings

• Likely causes: temporary maintenance changes remained in the image, guest customization is missing or incomplete, or old network, credential, certificate, or application data was not removed.
• Resolution: review image cleanup steps, test deployment in a non-production environment, and update guest customization specifications and template documentation.

Exam-Relevant Notes

• A template must be converted to a VM before guest operating system or application changes can be performed.
• The VM should be powered off before it is converted back into a template.
• Choose temporary placement on a compatible ESXi host or cluster with adequate compute, datastore, and network resources.
• An isolated network or disconnected adapter helps prevent duplicate identity and production-service conflicts.
• A clean guest shutdown and completion of all active tasks are important prerequisites for conversion back to a template.
• A snapshot may provide short-term rollback assistance, but it is not a replacement for a backup and should have a defined lifecycle.
• Validation must include guest boot, updates, services, logs, disk space, application behavior, cleanup, and deployment identity.

Summary

Updating a vSphere template is a controlled lifecycle operation rather than a direct edit. Plan the scope and rollback method, convert the template to a VM, place it on compatible infrastructure, restrict its network exposure, perform approved guest maintenance, validate the candidate, shut it down cleanly, and convert it back to a template. Versioned documentation and a test deployment make the updated image safer to use and easier to support.

For the complete procedure, return to Update a VMware vSphere Virtual Machine Template.