VMware ESXi and vSphere Cluster Management

How to Clone a Virtual Machine in VMware vSphere and ESXi

Learn how to clone a VMware vSphere virtual machine, choose compute and storage resources, customize the guest OS, and validate the new VM safely.

A virtual machine (VM) clone is a new, independent virtual machine created by copying an existing VM. The copy normally includes the source VM's virtual hardware configuration, guest operating system, installed applications, and virtual disks.

This guide explains how to clone a VM in the vSphere Web Client managed by vCenter Server, including destination selection, datastore and disk-format choices, guest OS customization, validation, and safety precautions.

What a Virtual Machine Clone Is

A source VM is the existing virtual machine used as the basis for a copy. The resulting clone VM is a separate VM whose files and virtual hardware are created from that source.

Depending on the options selected, cloning copies items such as:

Virtual CPUs, memory, virtual controllers, and other virtual hardware.
The guest operating system and its installed applications.
Virtual disks and the data stored on them.
Some guest-level settings that may require customization before the clone is connected to a live network.

Cloning an existing VM is different from deploying a VM from a template. A template is a master VM image intended for repeatable deployment. Cloning is usually based on the current state of a particular existing VM, including its current software, data, and configuration.

Clone versus Deploy from Template

Characteristic — Clone Existing VM — Deploy from Template

Starting point — A current source VM — A prepared master image

Typical purpose — Copy a workload, lab system, or production-like environment — Create standardized new VMs repeatedly

Source contents — Current operating system, applications, disks, and configuration — Contents deliberately prepared for reuse

Best fit — Testing a specific existing system or creating a near-identical copy — Consistent provisioning of many new systems

When to Use a Clone

Cloning is useful when you need a close copy of a working system for testing, development, troubleshooting, demonstrations, or lab exercises.

A common pattern is to clone a production-like web server into an isolated non-production environment, apply an operating system or application change to the clone, and test the result without modifying the source VM.

The copy is independent after creation: changes to the clone do not change the source VM, and changes to the source do not update the clone. Independence does not mean that every identity is safe to duplicate, however. You must review the guest operating system and applications before powering on the copy.

Clone Identity and Independence

vSphere assigns VM-level identity attributes to the new VM, including a new VM UUID, which is the VM's unique identifier, and a unique MAC address for each virtual network adapter. These identifiers help vSphere and the virtual network distinguish the clone from its source.

The guest OS can still contain copied identities. Examples include:

Computer or hostname settings.
Static IP addresses and other network configuration.
Domain membership and machine-account information.
Application-specific identifiers, database identities, or replication settings.
Monitoring, backup, inventory, and management-agent registrations.
Certificates, credentials, scheduled jobs, and service endpoints.

Duplicate guest identities can cause hostname collisions, IP conflicts, duplicate monitoring alerts, unintended email delivery, replication errors, or accidental interaction with production services. Use guest OS customization where appropriate, and isolate the clone until its identity and integrations have been reviewed.

Supported Source VM Power States

A source VM can be cloned while it is powered on, powered off, or suspended. The choice affects the consistency of the copied guest and applications.

Source VM Power State Considerations

Source State — Can Be Cloned — Operational Considerations — Recommended Precautions

Powered on — Yes — The clone reflects the state available while the cloning operation reads the VM; active applications may have changing or incomplete data — Use application-aware preparation when possible, disconnect the clone from production networking, and validate the copied application data

Powered off — Yes — The guest has been shut down, making the disk state easier to make consistent — Shut down applications cleanly and verify that important services completed their writes

Suspended — Yes — The VM includes a saved execution state that may not be suitable for every workload or test — Confirm that the suspended state is intentional and test the clone before allowing normal network access

For a consistent clone, shut down the guest or otherwise prepare the applications so that their data is in a known state. Cloning a running workload may capture only the state available at the time of cloning and may require guest- or application-aware procedures.

Pre-Clone Planning and Permissions

Before opening the clone wizard, make the destination and safety decisions explicitly.

Access: Verify access to vCenter Server and the vSphere Web Client. vCenter Server is the centralized platform used to manage inventory, hosts, clusters, datastores, and VM operations.
Source: Identify the intended source VM by name, folder, operating system, and workload. Do not rely on a similar name alone.
Inventory: Select a destination VM folder or other inventory location that matches the test, development, or production organization.
Compute: Confirm that the destination cluster or ESXi host has sufficient CPU and memory, and that its hardware and configuration are compatible with the VM.
Storage: Check free datastore capacity for the cloned virtual disks and VM files. Also consider performance, availability, accessibility from the destination compute resource, and compatibility.
Network: Decide whether the clone should start disconnected, use an isolated port group, or use a non-production network. Plan this before the first boot.
Permissions: Confirm that your account can clone the source VM, assign the destination inventory location, select compute resources, and allocate storage. If necessary, review the vCenter permissions assigned to your role using the vCenter permissions guide.

An ESXi host is the hypervisor server that runs VMs. A cluster is a group of ESXi hosts managed together as a compute resource. A datastore is storage made available to ESXi for VM files and virtual disks.

Clone a VM in the vSphere Web Client

1. Open the source VM

Sign in to the vSphere Web Client through vCenter Server.
Open the vCenter inventory and the Virtual Machines view.
Locate and select the source VM.
Confirm its name, folder, power state, operating system, and workload before continuing.

2. Start the clone workflow

Open the source VM's actions or context menu.
Select Clone and then Clone to Virtual Machine, or the equivalent action shown by your vSphere version.
Enter a distinct name for the new VM. Include an environment or purpose identifier such as -test or -dev when that matches your naming standard.

3. Choose the inventory location

Select the destination datacenter, folder, or other inventory location. Put the clone where administrators and automation will expect to find it. A test clone should normally be placed in a clearly labeled non-production folder.

4. Select a compute resource

Choose a destination cluster or a specific ESXi host.

Cluster: Selecting a cluster allows vSphere cluster services and placement mechanisms to determine an appropriate host, subject to the cluster's policies and available resources.
Specific ESXi host: Selecting a host gives direct placement control. Use this when the VM requires a particular host, datastore connectivity, hardware compatibility, or maintenance arrangement.

Check CPU, memory, host compatibility, cluster capacity, and access to the selected datastore. If the destination host or cluster is not suitable, the task may fail or the VM may perform poorly after deployment.

5. Select storage and virtual disk format

Choose a target datastore that has adequate free space, acceptable performance, the required availability, and connectivity from the destination compute resource.

The wizard may present a virtual disk format choice. A virtual disk format defines how storage is provisioned. Common choices include:

Thin provisioning: The virtual disk starts with a smaller amount of physically consumed storage and grows as data is written, up to its configured size. Monitor free datastore space because growth can eventually exhaust capacity.
Thick provisioning: Storage is allocated more fully in advance. This provides predictable capacity consumption but requires sufficient free space at clone time. Depending on the environment, thick options may have different allocation or zeroing behavior.

The selected format affects initial and future datastore consumption, provisioning behavior, capacity planning, and sometimes performance characteristics. Choose according to the workload and storage policy rather than simply selecting the smallest apparent footprint.

6. Review clone options

Review the summary presented by the wizard. Confirm the VM name, inventory location, destination cluster or host, datastore, disk format, network mappings, and any other available options before deployment.

7. Configure guest OS customization

Optionally enable guest operating system customization. This is automated configuration of the cloned guest OS during deployment using a customization specification, a reusable vSphere configuration that defines guest identity and network settings.

When customization is enabled, select a specification appropriate for the guest OS. Common settings include:

Computer name or hostname.
IP address, subnet, gateway, DNS, and other network settings.
Domain or workgroup membership.
Licensing-related settings where applicable.
Operating-system-specific preparation and identity changes.

Customization helps prevent guest identity collisions, but it depends on a valid specification, guest OS support, and suitable guest prerequisites such as VMware Tools where required. A specification does not automatically disable every application integration, scheduled job, credential, certificate, or monitoring registration copied from the source.

8. Finish and monitor the task

Review the final configuration carefully.
Finish the wizard to start the cloning task.
Monitor the task in the vSphere Web Client until it completes successfully.
Verify that the new VM appears in the selected inventory location.

Clone Wizard Decision Points

Wizard Stage — Administrator Selection — Why It Matters

Name — Distinct clone name — Prevents inventory ambiguity and helps identify the environment

Inventory location — Datacenter or VM folder — Determines organization, visibility, and inherited permissions

Compute resource — Cluster or ESXi host — Determines CPU, memory, hardware compatibility, and placement

Storage — Destination datastore — Determines capacity, performance, availability, and accessibility

Disk format — Thin or thick option when presented — Determines storage allocation and provisioning behavior

Customization — Disabled or a guest customization specification — Determines whether guest identity and network settings are changed during deployment

Practical Example: Isolated Test Copy of a Web Server

Select the production-like web server as the source VM and confirm that it is the intended system.
Start Clone to Virtual Machine and name the copy with a clear test suffix.
Place it in a test VM folder and select test compute and storage resources.
Keep its virtual network adapter disconnected, or connect it only to an isolated test network.
Apply a guest customization specification with a unique hostname and test IP configuration.
Power on the clone in the controlled network.
Test the planned application or operating system change while leaving the source VM untouched.

Practical Example: Clone to Another Datastore

When cloning to a different datastore, select a destination with enough free capacity and appropriate performance. Choose the required disk format in the storage step. Thin provisioning can reduce immediate physical consumption but requires monitoring as the disks grow. Thick provisioning consumes more capacity up front but gives more predictable allocation.

After completion, inspect the clone's summary and virtual hardware to verify that its disks are on the intended datastore and use the expected provisioning format.

Practical Example: Clone a Running VM Safely

A running VM can be cloned, but an active workload increases the risk of inconsistent application data and network conflicts.

Initiate the clone from the powered-on source only when the application and storage procedures allow it.
Keep the clone's network adapter disconnected or place it on an isolated network before first boot.
Use guest customization or manually assign a unique hostname and network configuration.
Disable or redirect copied integrations such as email, replication, monitoring, backups, and scheduled jobs.
Start the clone and validate the guest and applications before allowing any broader network access.

Post-Clone Validation

Do not treat a completed vSphere task as proof that the clone is ready for use. Perform these checks:

Confirm that the cloning task completed successfully and review any warnings or events.
Review the clone's VM summary, virtual hardware, datastore placement, and host or cluster placement.
Confirm that the clone has its own VM UUID and that its virtual network adapters have unique MAC addresses.
Before connecting it to a production network, verify the guest hostname, IP address, DNS settings, and domain or workgroup state.
Power on the VM in a controlled network, or keep its adapters disconnected when appropriate.
Validate guest OS startup, VMware Tools status, application services, and expected network connectivity.
Review application identifiers, credentials, certificates, backups, monitoring registrations, replication, and scheduled tasks.
Confirm that the source VM remains unchanged and continues to operate as expected.

Post-Clone Identity Checks

Identity or Setting — VM-Level or Guest-Level — Expected Handling After Clone — Risk If Not Reviewed

VM UUID — VM-level — Should identify the clone separately from the source — Inventory or management confusion

Virtual NIC MAC address — VM-level — Should be unique for the clone's adapters — Network or address-resolution conflicts

Hostname — Guest-level — Change it or confirm that duplication is intentional — Name collision and incorrect service targeting

IP configuration — Guest-level — Assign non-conflicting test or destination-network settings — Duplicate IP address or unreachable systems

Domain membership — Guest-level — Follow the organization's cloning and machine-account process — Authentication or directory conflicts

Application identity — Guest-level — Regenerate, disable, or redirect it as required — Duplicate replication, monitoring, backup, or service registrations

Safety and Operational Cautions

Do not power on an uncustomized clone on the same network as its source when duplicate hostnames, IP addresses, or services could conflict.
Protect production credentials, application data, certificates, and private keys when cloning into a lower-trust lab or development environment.
Disable or redirect production email delivery, replication, backup jobs, monitoring agents, automation, and scheduled tasks before test use.
Use network isolation until the guest identity and application behavior have been reviewed.
Plan for clone duration. Large virtual disks, slow or busy datastores, storage or network bottlenecks, and disk-provisioning choices can make cloning take considerably longer.

Troubleshooting Clone Problems

The clone task cannot start or fails immediately

Likely causes: Insufficient cloning or destination-resource permissions, an invalid or inaccessible folder, host, cluster, or datastore, or insufficient datastore capacity.
Checks: Review task details and vCenter events, confirm the account's privileges, verify destination accessibility and capacity, and choose another datastore or disk format if necessary.

The cloned VM conflicts with an existing system

Likely causes: Duplicate hostname, static IP address, network connection to the production segment, or copied application, directory, monitoring, or backup identity.
Resolution: Disconnect the clone from the affected network, assign unique guest settings, correct or apply the customization specification, and review application-specific identities and scheduled tasks.

Guest OS customization does not run or apply expected settings

Likely causes: Customization was not enabled, no specification was selected, the specification does not match the guest OS, VMware Tools or another prerequisite is unavailable, or the specification contains invalid settings.
Resolution: Confirm the wizard selection, review the specification and guest compatibility, verify guest prerequisites, and inspect vCenter events and guest-side logs where available.

The clone takes longer than expected

Likely causes: Large source disks, congested storage or network infrastructure, a slow destination datastore, or storage-placement and disk-format choices.
Resolution: Monitor the task and storage metrics, check datastore health and free space, schedule large jobs outside peak periods, and select storage appropriate for the workload.

The clone starts but is not safe for testing

Likely cause: Production integrations, credentials, replication, email delivery, scheduled jobs, or external service connections were copied unchanged.
Resolution: Isolate the network before boot, disable or redirect integrations, protect or rotate sensitive credentials as required, and follow the application's cloning procedure.

Exam-Relevant Notes

A clone is a new, independent VM created from an existing source VM.
A source VM may be cloned while powered on, powered off, or suspended, but a clean shutdown is preferred when application consistency matters.
Clusters and individual ESXi hosts are alternative compute-resource destinations; a cluster provides group-level placement while a host provides direct placement.
Datastore selection must account for free capacity, performance, availability, accessibility, and compatibility.
Thin and thick provisioning change storage allocation and capacity behavior.
VM-level identifiers such as UUID and MAC address are distinct from guest-level identities such as hostname, IP address, domain membership, and application registrations.
Guest customization requires a suitable customization specification and supported guest prerequisites.
Always prevent an uncustomized clone from interacting with the source system's network and services.