VMware ESXi and vSphere Cluster Management

Clone a Virtual Machine in VMware vSphere

Learn how to clone a virtual machine in VMware vSphere using vCenter and the vSphere Web Client, including compute, storage, customization, and validation.

A virtual machine clone is a newly created VM based on an existing VM. The clone copies the source VM's virtual hardware configuration, guest operating system, virtual disks, installed applications, and software state. After the operation finishes, the clone is a separate inventory object that can be configured and managed independently.

This procedure uses vCenter Server and the vSphere Web Client. You should understand basic VM concepts, vCenter inventory navigation, ESXi hosts and clusters, datastores, virtual disk provisioning, guest networking, and guest OS customization specifications before beginning.

Why Clone a Virtual Machine?

Cloning is useful when you need a copy of an existing workload rather than an empty VM. Common uses include test environments, development systems, training labs, troubleshooting, and creating a production-like system for validating a change.

For example, an administrator can clone a production-like application server before testing a new application feature. The test can be performed on the clone while the source VM continues serving its normal workload. Changes made inside the clone do not change the source VM's files, guest operating system, or virtual hardware.

Cloning is not the same as deploying from a VM template. A clone copies a particular existing VM and its current configuration and software state. A VM template is a master image intended for repeatedly deploying standardized new VMs.

Characteristic	Clone an Existing VM	Deploy From a Template
Starting point	A specific existing VM, often containing a configured workload	A prepared master image intended for deployment
Typical purpose	Create a production-like test, development, or troubleshooting copy	Create standardized VMs with a repeatable baseline
Copied state	Copies the source VM's current disks, operating system, applications, and configuration	Uses the template's approved image and configuration
Identity preparation	May require changes to hostnames, IP settings, domain membership, and application identifiers	Usually uses deployment and customization settings designed for new instances

Clone Identity and Independence

The cloned VM is a separate vCenter inventory object, not a linked instance that shares ordinary changes with the source VM. It receives its own VM UUID and virtual network adapter MAC address.

Virtual hardware identity does not automatically solve every identity problem inside the guest. The copied operating system and applications may still contain the source's:

Computer name or hostname
IP address and other network settings
Domain membership or directory identity
Application-specific identifiers, licenses, registrations, or service names

When the clone will use the same network as the source, customize these values before exposing the clone to shared or production services. A unique VM UUID and MAC address do not by themselves prevent hostname, IP, domain, or application-level conflicts.

Supported Source VM Power States

You can initiate cloning from a source VM that is powered on, powered off, or suspended. The correct choice depends on the workload and the consistency required for the copy.

Powered on: Useful when minimizing interruption is important, but application and filesystem activity may continue while the copy is made.
Powered off: Often preferred when the clone must contain application-consistent data and no writes should occur during preparation.
Suspended: Can be cloned when preserving the suspended VM state is appropriate, although the resulting guest and application behavior should be validated.

Before You Start

Identify the correct source VM and confirm that cloning it is authorized.
Choose a unique name for the new VM.
Decide which vCenter inventory folder will contain the clone.
Choose a destination cluster, ESXi host, or resource location with adequate CPU and memory.
Confirm that the destination host can access the required datastore and network.
Check datastore capacity, including the space required by the selected virtual disk format.
Prepare or select a guest OS customization specification if the clone will share a network with the source.
Determine whether the clone should use thin or thick virtual disk provisioning.

Start the Clone Workflow

Open vCenter Server in the vSphere Web Client.
Navigate to the Virtual Machines inventory.
Select the intended source VM.
Open the VM context menu and choose Clone to Virtual Machine.

The cloning wizard then collects the destination name, inventory location, compute placement, storage placement, disk format, and optional guest customization settings.

Configure the Clone Wizard

1. Name and inventory location

Enter a unique name for the cloned VM. Use a naming convention that identifies its environment, role, or purpose, such as a development or test designation.

Select the vCenter inventory location, usually a VM folder, in which the clone will appear. Inventory placement is separate from compute placement and datastore selection. Choosing a folder does not choose the ESXi host, cluster, or storage location where the VM runs.

2. Compute placement

Select the destination cluster, ESXi host, or appropriate resource location. Consider:

Available CPU and memory capacity
VM hardware and host compatibility
Cluster admission and placement policies
Access to the required datastore
Availability of the intended port group or network

A cluster is a group of ESXi hosts that provides compute resources for VMs. An ESXi host is the hypervisor server on which a VM runs. Select a location that can satisfy the clone's resource and compatibility requirements.

3. Storage and virtual disk format

Select the datastore that will store the cloned VM's configuration files, virtual disks, and other VM files. A datastore is storage presented to ESXi for VM files and virtual disks.

When the interface offers disk provisioning choices, select the required virtual disk format:

Thin provisioning: The virtual disk initially consumes less physical datastore space and grows as data is written. Monitor free space because actual consumption can increase over time.
Thick provisioning: Space is allocated in advance. This provides more predictable datastore consumption, but requires sufficient capacity at the time of cloning.

Terminology and exact thick options can vary by storage type and vSphere version. Follow the environment's storage policy and verify that the destination datastore has adequate free space for the selected format and any future growth.

4. Guest operating system customization

Enable Customize the operating system when the clone needs a distinct guest identity. Select an existing guest OS customization specification, which is a reusable vCenter configuration for applying operating system identity and network settings.

A customization specification may set values such as:

Computer name or hostname
IP address, subnet, gateway, and DNS settings
Operating system identity settings
Domain membership or workgroup configuration
Other supported first-boot guest settings

Customization is especially important when the clone will connect to the same network as the source. It helps prevent duplicate hostnames and IP addresses, although application-specific identity and registration may still require manual configuration after boot.

Wizard Stage	Required Selection	Why It Matters
Name and inventory	Unique VM name and vCenter folder	Identifies the clone and places it correctly in the inventory; this does not select compute or storage.
Compute	Cluster, ESXi host, or resource location	Determines where the clone can run and which CPU, memory, compatibility, and placement policies apply.
Storage	Destination datastore	Determines where VM files and virtual disks are stored and whether the host can access them.
Disk format	Thin or thick provisioning when available	Controls how datastore capacity is consumed and how storage growth is managed.
Guest customization	Optional customization specification	Provides unique guest identity and network settings for safer operation beside the source.

Review, Finish, and Monitor the Task

Review the clone name, inventory location, compute destination, datastore, disk format, and customization selection.
Confirm that the destination has adequate CPU, memory, storage, networking, and compatibility.
Finish the wizard to start the clone operation.
Monitor the task in vCenter until it completes successfully.
Confirm that the new VM appears in the selected inventory location.

Do not assume that the VM is ready for a shared network merely because the clone task completed. Complete post-clone checks before powering it on in an environment where it could contact the source or other services.

Post-Clone Validation

Verify the cloned VM's name and inventory folder.
Confirm the destination cluster or ESXi host.
Check the datastore and virtual disk placement.
Review virtual network adapter and port group settings before booting.
Confirm that the clone has its own VM UUID and MAC address.
If customization was selected, validate the hostname, IP configuration, DNS settings, domain membership, and other guest identity values after first boot.
Check application-specific identifiers, service registrations, licenses, scheduled jobs, and monitoring agents.
Ensure that the clone does not connect to production services or networks unintentionally.

Practical Example: Safely Testing an Application Feature

Choose a production-like application server as the source VM.
Start Clone to Virtual Machine from the source VM in the Virtual Machines inventory.
Give the clone a unique test name and place it in a dedicated test folder.
Select a test cluster or ESXi host and a datastore reserved or approved for test workloads.
Enable guest OS customization and select a specification with a distinct hostname and test network settings.
Review the selections, finish the wizard, and monitor the vCenter task.
Validate the clone's identity and network connections before powering it on.
Test the feature on the clone without changing the original VM.

Practical Example: Creating a Development Application Server

Clone the existing application server VM.
Place the clone in the development inventory folder and compute environment.
Choose thin or thick provisioning according to datastore capacity, performance requirements, and storage policy.
Apply unique guest hostname and network settings.
Review application configuration so production endpoints, registrations, credentials, and service identifiers are not reused accidentally.
Power on and validate the development copy only after network and application identity checks are complete.

Troubleshooting Clone Operations

The clone cannot be created on the selected datastore

Likely causes: Insufficient datastore capacity, a disk format that requires more space than available, or a datastore that is inaccessible to the destination host.
Resolution: Check free space, verify storage visibility from the selected host, review the disk provisioning format, and choose suitable destination storage.

The clone causes a hostname or IP conflict

Likely causes: Guest customization was skipped, the clone inherited settings already in use, or the clone was connected to the shared network before its identity was changed.
Resolution: Disconnect or isolate the clone, apply a guest OS customization specification, or update the guest hostname and network settings before reconnecting it to the production network.

The clone cannot run on the selected host or cluster

Likely causes: Insufficient CPU or memory, host compatibility limitations, unavailable destination storage, or missing network access.
Resolution: Review host and cluster capacity, VM compatibility, datastore access, port groups, and placement policies. Select a destination that satisfies all requirements.

The guest has unexpected application or service identity conflicts

Likely causes: Application-specific identifiers, registrations, licenses, scheduled jobs, or service settings were copied from the source.
Resolution: Keep the clone isolated while performing application-specific post-clone configuration. Assign unique identifiers and disable or redirect services that must not operate as production instances.

Key Points

Cloning creates a separate VM from an existing source VM, including its virtual hardware, operating system, disks, and applications.
The source may be powered on, powered off, or suspended, but a powered-off source is often preferred for application-consistent data.
Inventory folder, compute placement, datastore, disk format, and guest customization are separate decisions in the wizard.
A clone receives its own VM UUID and virtual NIC MAC address, but guest and application identities may still need customization.
Always validate network settings, host and datastore placement, guest identity, and application behavior before using the clone in a shared environment.

For related deployment concepts, see VM cloning in vSphere.