VMware ESXi and vSphere Cluster Management

Update a Virtual Machine Template in VMware vSphere

Learn how to safely convert a VMware vSphere VM template to a virtual machine, apply guest updates, validate it, and convert it back into a reusable template.

A VM template is a master virtual machine image used to deploy consistent virtual machines. It is often called a golden image because it contains the approved operating system, patches, software, and configuration for a particular workload.

Templates cannot be powered on and edited directly. To maintain one, use vCenter Server to convert the template into a virtual machine, perform maintenance inside the guest operating system, shut the VM down cleanly, and convert it back into a template.

Why Maintain a VM Template?

A template provides a repeatable starting point for new deployments. Without regular maintenance, every newly deployed VM may require the same manual patching and configuration work after creation.

Common reasons to update a template include:

• Installing operating system patches and security fixes.
• Updating applications, runtimes, drivers, or base utilities.
• Updating VMware Tools when the guest and vSphere versions support the change.
• Refreshing monitoring, backup, endpoint protection, or management agents.
• Changing approved system settings or baseline configuration.
• Removing obsolete software, temporary installers, cached data, and test artifacts.

A current template reduces post-deployment configuration, shortens the time required to bring new VMs into service, and improves consistency across an environment. It also helps ensure that newly deployed systems begin with the organization’s current security baseline.

Template Update Workflow

The complete lifecycle is:

1. Identify the correct template and document the intended changes.
2. Convert the template to a virtual machine.
3. Select a compatible ESXi host or cluster and verify storage.
4. Optionally isolate or disconnect the VM network.
5. Power on the VM and sign in to the guest operating system.
6. Apply patches, software, tools, and configuration updates.
7. Clean the image and validate its health.
8. Shut down the guest operating system cleanly.
9. Convert the powered-off VM back to a template.
10. Record the new version and communicate its availability.

Conversion changes the vSphere inventory object type while retaining the virtual machine’s disks and image contents. The template is not directly runnable until it is converted to a VM or used as the source for a deployment.

Plan the Maintenance Before Conversion

Do not begin by converting an object whose purpose or ownership is unclear. Record the template’s operating system, intended role, current patch level, installed applications, and current version. Define the changes for this maintenance cycle and choose a naming convention such as web-windows-2026.08 or an equivalent organizational standard.

Check that the administrator has permission to convert templates, power on and off VMs, change virtual network connections, and log in to the guest operating system. Review the relevant vSphere permissions and confirm communication between vCenter Server and ESXi is healthy.

Convert the Template to a Virtual Machine

1. Open the vSphere Client and locate the template in the inventory.
2. Confirm that it is the intended template and note its current version.
3. Open the template’s actions menu and choose Convert to Virtual Machine.
4. Select an appropriate cluster or ESXi host for the temporary editable VM.
5. Complete the wizard and wait for the task to finish.
6. Confirm that the inventory object is now shown as a virtual machine rather than a template.

Select a host or cluster with access to the VM’s datastore, compatible virtual hardware, and enough CPU and memory capacity. A cluster can provide shared compute resources and scheduling capabilities, while an ESXi host is the hypervisor that runs the VM.

Isolate the Network During Maintenance

Network isolation is optional, but it is often a valuable safeguard. Connect the maintenance VM to an isolated or restricted port group, or disconnect its virtual network adapter when no network access is needed.

An isolated network helps prevent users, monitoring systems, domain services, automation, and production workloads from interacting with a temporary VM that may have a duplicate identity, test settings, or incomplete security configuration.

Some updates require access to an internal repository, proxy, domain service, or approved internet endpoint. In that case, use a controlled maintenance port group and allow only the required destinations. Verify DNS, routing, proxy, and firewall rules. Do not attach the VM to a production application network merely to simplify patching. Review virtual machine settings and your organization’s guidance for VLAN configuration where applicable.

Perform Guest Operating System Maintenance

After conversion, power on the VM and log in using an approved administrative method. Use the organization’s patching and software deployment process inside the guest. There is no universal update command: Windows, Linux distributions, package managers, patching platforms, repositories, and security policies all differ.

Windows Server Example

1. Connect the VM to a controlled maintenance network or approved update services.
2. Install the required monthly operating system and security updates.
3. Update approved applications, security tools, management agents, and VMware Tools.
4. Reboot as required and confirm that the expected update level is installed.
5. Check required services, event logs, disk capacity, and startup behavior.
6. Remove temporary installers, update caches, test files, and other unnecessary artifacts.

Linux Base Image Example

1. Connect to the approved package repositories through the maintenance network.
2. Apply distribution updates and update required base utilities or monitoring agents.
3. Confirm package state, service startup, available disk space, and recent system errors.
4. Remove temporary repository files, downloaded installers, and environment-specific artifacts.
5. Verify that the image does not contain test credentials, user data, or host-specific settings.

When updating VMware Tools, confirm that the version is appropriate for the guest operating system and vSphere environment. VMware Tools supplies guest utilities and drivers that improve integration, performance, and management capabilities.

Clean the Image Before Capture

A reusable template should contain the approved baseline, not the identity of the maintenance VM. Remove or reset, as appropriate:

• Administrative credentials, private keys, tokens, and stored passwords.
• User documents, application data, test accounts, and local logs that should not be copied.
• Temporary files, installers, package caches, and update artifacts.
• Test IP addresses, temporary DNS settings, proxy settings, and maintenance-only network configuration.
• Machine-specific identifiers or other values that must be generated during deployment.

Guest customization should be planned separately and tested during deployment. See customize a guest OS for related deployment considerations.

Validate the Updated Image

Before recapturing the template, verify both the changes and the clean baseline. At minimum:

• Confirm that all planned updates installed successfully.
• Check that the guest operating system reports a healthy state.
• Start required services, applications, monitoring agents, and management tools.
• Reboot the guest and confirm that services return to the expected state.
• Review relevant system and application error logs.
• Check free disk space and confirm that update activity did not consume excessive capacity.
• Verify that no temporary credentials, test network settings, or environment-specific data remain.

For higher assurance, deploy or clone a temporary VM from the updated image and test its first boot, guest customization, network behavior, required services, and application startup. Do not assume that a successful update session proves that newly deployed VMs will behave correctly.

Power Off and Convert Back to a Template

1. Finish all guest maintenance and save required work.
2. Shut down the guest operating system cleanly. Do not use a forced power-off unless recovery procedures require it.
3. Wait until vSphere shows the VM as powered off and active tasks have completed.
4. Select the VM in the vSphere inventory.
5. Open the actions menu and choose Convert to Template.
6. Confirm the operation and wait for the conversion task to complete.
7. Verify that the resulting inventory object is marked as a template and cannot be powered on directly.

Restore the intended template network configuration before or during the final review. If the VM used a maintenance-only port group, ensure that the template does not retain an unintended test connection or address configuration.

Update the template description, annotations, version label, patch date, installed software list, owner, and change record. Clear or document any maintenance-only details that should not be inherited by deployed VMs.

Template Maintenance Considerations

Post-Update Lifecycle Management

Tell provisioning teams and users when the updated template is available, including its version, intended workload, patch level, and any deployment requirements. Retire or archive superseded versions according to the organization’s retention policy. Keep older versions only as long as they are useful for rollback, compliance, or application compatibility.

Schedule recurring maintenance based on operating system patch cycles, security requirements, application release schedules, and organizational change controls. Tracking update dates and versions makes deployments more predictable and provides an audit trail.

Troubleshooting

Conversion Is Unavailable or Fails

Verify that the selected inventory object is actually a template and is not already involved in another task. Confirm that the user role includes template conversion privileges. Review vCenter task details and events for the specific failure, and check vCenter connectivity and task processing.

The Converted VM Cannot Be Powered On

Check for available CPU and memory resources, host compatibility, datastore visibility, and access to the VM files. Select a compatible ESXi host or cluster and review the power-on task error. Virtual hardware compatibility may also need to be checked before moving the VM to a different host or cluster.

The VM Cannot Reach Update Repositories

Confirm that the virtual adapter is connected and that the selected port group is the intended maintenance network. Check DNS, routing, proxy, and firewall access. Provide controlled access to only the required update services rather than exposing the VM to an unrestricted production network.

The VM Cannot Be Converted Back to a Template

Confirm that the guest operating system has shut down and that vSphere reports the VM as powered off. Wait for active tasks to complete and inspect task errors for locks or other failures. Also verify that the administrator has permission to convert a VM to a template.

New VMs Have Unintended Configuration

Review the updated image for test network settings, credentials, user data, host-specific configuration, and incomplete cleanup. Deploy a temporary test VM and validate customization behavior before releasing the template. A documented baseline checklist helps prevent the same omissions during future maintenance cycles.

Exam-Relevant Notes

• A template is a deployment source, not a directly runnable VM.
• Convert to Virtual Machine makes the template editable and runnable.
• Convert to Template requires the VM to be powered off.
• An ESXi host runs the VM; a cluster groups ESXi hosts and supplies shared compute management.
• A datastore stores VM files, virtual disks, and templates.
• A port group defines the virtual network connection used by a VM network adapter.
• Network isolation reduces the chance that a temporary maintenance VM interacts with production systems.
• Always validate cleanup and guest customization before publishing an updated template.