How to Clone VMs if VMware vCenter Is Unavailable

Cloning a virtual machine (VM) is a convenient way to duplicate an environment for testing or deployment. Normally, VMware vCenter Server provides a one-click clone feature, but what if you have a host without vCenter? Fortunately, you can still clone VMs using alternative methods. In this article, we’ll explore three ways to clone a VM on an unmanaged ESXi host: using the VMware Host Client (Web UI), using the ESXi shell via SSH, and using a PowerCLI automation script. Each method ultimately performs the same fundamental actions: powering off the source VM, copying its disk and configuration files, and registering a new VM from those copies. Before we dive in, keep in mind a few best practices and prerequisites:

Power off the source VM: Ensure the VM you want to clone is shut down cleanly. Cloning a running VM can lead to data inconsistencies.
Remove or commit snapshots: VMware strongly recommends not cloning a VM that has snapshots; consolidate or delete any snapshots first. (Cloning with snapshots is possible but can lead to outdated disks if not done carefully.)
Check storage space: Verify that your datastore has enough free space to accommodate the full size of the VM’s disks.
Understand VMware’s stance: Copying VM files manually is an advanced procedure. VMware prefers using tools like vmkfstools for disk copying instead of generic cp/mv commands to avoid potential issues. We’ll note where this is applicable.
“I Copied It” prompt: When you power on a cloned VM, ESXi will usually ask whether the VM was moved or copied. Always answer “I copied it”. This prompts ESXi to generate new identifiers (UUID/MAC) for the clone to avoid conflicts.

With that in mind, let’s walk through each cloning method in detail.

Method 1: Cloning via VMware Host Client (Web UI)

Using the ESXi Host Client – the web-based interface built into ESXi – is the most straightforward way to clone a VM without vCenter. Essentially, you will manually copy the VM’s files through the browser interface. This method is ideal for one-off clones or for those who prefer a GUI approach.

Steps:

Log in to the ESXi Host Client: Open a web browser and navigate to https://<esxi-host-ip>/ui. Log in with the root account or an administrative user. You’ll see the ESXi host management interface.
Power Off the Source VM: In the left “Navigator” pane, click Virtual Machines, then select the VM you want to clone from the list. Ensure this VM is powered off (the UI will show a gray “powered off” icon if it is). If it’s running, shut it down gracefully from its guest OS or use Actions > Power > Shut Down. Also verify the VM has no active snapshots. You can check the Snapshot Manager; if snapshots exist, consider consolidating them first, as cloning with snapshots is not recommended.
Identify the VM’s Datastore: Still on the source VM’s page, switch to the Summary tab or Monitor > Storage in newer UIs and note the datastore where the VM’s files reside. For example, you might see something like “Storage: Datastore1” indicating the VM’s home datastore. You’ll need to browse this datastore to copy files.
Open the Datastore Browser: In the left Navigator, click Storage, then click on the datastore that contains the source VM. In ESXi, after selecting the datastore, go to the Files tab. Navigate through the folders to find the directory named after your source VM (for example, a folder called VM-Main). This folder contains the VM’s configuration (.vmx), virtual disk (.vmdk), and other files.
Create a New Folder for the Clone: In the datastore browser, create a directory for the new cloned VM’s files. Use the Create Directory button or right-click in the file list and choose New Folder. Name the folder appropriately (e.g., “VM-Clone”). This will be the target location where we place the copied files.
Copy the VM’s Files to the New Folder: Now, copy the necessary files from the source VM’s folder into the new folder. At minimum, copy the virtual disk file(s) and the VMX configuration file. If the source VM has multiple virtual disks, copy each .vmdk (and its accompanying -flat.vmdk if applicable – the UI will handle both together). You do not need to copy snapshot files (-00000x.vmdk), if any, or log files; the main disk and config are sufficient for a full clone. To copy, you can right-click the source VM’s folder and choose Copy, then navigate into the new folder and right-click Paste. Alternatively, use the checkboxes or drag-and-drop if supported. The Host Client will queue up a file copy task.
- Thin vs Thick Provisioning: The copy operation will duplicate the disk in its current format. If your source disk is thick-provisioned, the copy will also be thick by default. If you prefer to convert to thin provisioning during clone, consider using the CLI method with vmkfstools as discussed later.
Wait for the Copy to Complete: Monitor the Recent Tasks pane at the bottom of the Host Client. You’ll see file copy tasks running. Cloning large virtual disks can take some time, even when copying within the same datastore, so be patient. Do not proceed until all copy tasks show Completed.
Register the Cloned VM: Once the files are copied into the new folder, the Host Client needs to “know” about the new VM. Still in the datastore Files view, find and right-click the cloned .vmx file, then select Register VM or Add to Inventory, depending on the UI wording. This will open a wizard to add the VM to the host’s inventory. Provide a name for the new VM when prompted. You can use the same name as the folder, or another friendly name as needed. Assign it to a compute resource and finish the wizard. After a moment, the new VM should appear in the Virtual Machines list on the left. If the .vmx file was not renamed, the wizard might auto-suggest the old VM’s name – be sure to give it a unique name to avoid confusion.
Verify and Adjust VM Settings: Click on the newly added VM and go to Edit Settings (in the Actions menu or on the VM’s Configure tab). Check the Virtual Hardware section, especially the hard disk settings. Confirm that the virtual disk is pointing to the cloned VMDK in the new folder (e.g., it should show a path like “[Datastore1] VM-Clone/VM-Clone.vmdk”). This ensures the clone VM is using its own disk copy and not accidentally referencing the original VM’s disk. Usually, because we copied and registered the VMX directly, it should already reference the new disk file, but double-check to be safe. You can also adjust any other settings such as increasing CPU or memory for the clone at this stage if desired.
Rename the Clone VM (Optional): If you didn’t set a new name during registration or if the clone inherited the source’s name, rename it now to avoid management confusion. In the Host Client, you can rename a VM by right-clicking it in the inventory and selecting Rename. This is a cosmetic change for inventory display; it doesn’t change the underlying files or guest OS hostname.
Power On the Cloned VM: You’re now ready to boot the new VM. Select the clone and click Power on. The first time the clone powers on, ESXi will detect that the VM was copied. A dialog will appear asking: “Did you copy or move this virtual machine?” Answer that you copied the VM. In the web UI, this is typically a pop-up where you must click I Copied It. This ensures ESXi generates a new unique identifier for the VM to avoid conflicts with the source. After confirming this, the VM will continue booting.
Post-Clone Cleanup: Once the clone is running, verify that it booted correctly and that the guest OS is intact (it should be a replica of the source VM’s state at the time of clone). If the source and clone VMs will run simultaneously on the same network, consider changing the clone’s hostname or IP address in the guest OS to prevent conflicts. Since the clone is an exact copy, it may have the same network configuration as the source. Also, if the original VM had any tied licenses or unique IDs, treat the clone accordingly.

The Host Client method provides a convenient graphical workflow. It’s essentially a manual copy operation, but using the web UI to do the heavy lifting. One advantage is that it requires no additional tools or scripting – just a browser. However, it lacks advanced options like choosing disk format and can be slower for large disks. Keep this method in your toolbox for quick clones on standalone hosts, especially if you’re not comfortable with command-line operations.

Method 2: Cloning via SSH (ESXi Shell Commands)

For those familiar with Linux-like command line, ESXi’s shell offers full control to clone a VM by copying files directly. Under the hood, this achieves the same result as the GUI method, but it can be faster and more flexible. In this method, we’ll enable SSH access to the host and run shell commands to duplicate the VM.

Steps:

1. Enable SSH on the ESXi Host: By default, ESXi’s SSH service is usually disabled for security. To enable it, open the Host Client UI, go to Host > Actions > Services, and click Enable Secure Shell (SSH). In ESXi, you can also enable it via Host > Manage > Services, then start the service named TSM-SSH (Technical Support Mode – SSH). The SSH service status can also be seen on the main Host > Summary page under “Services”. Remember to disable SSH again when you’re done cloning, to minimize exposure.

2. SSH into the ESXi Host: Use an SSH client such as PuTTY on Windows, or the ssh command in a Linux/Mac terminal to connect to the ESXi host’s IP or hostname. Log in as root or another admin-level user. You should see an ESXi shell prompt usually a ~ # if at the home directory. This is a limited BusyBox-based shell environment on the host.

3. List the Registered VMs (Optional): It’s helpful to get a quick overview of VMs and their inventory IDs. Run:
vim-cmd vmsvc/getallvms
This command lists all VMs registered on the host, with columns for VMID, Name, File path, OS, etc. For example, you might see an output line like:
Vmid Name File
1 VM-Main [Datastore1] VM-Main/VM-Main.vmx
Find your source VM (VM-Main in this example) in the list and note the path in square brackets, which indicates the datastore and folder. You can also note the VM’s VMID for later use, though we will mostly work with paths.

4. Identify Datastore Paths: ESXi presents datastores under the /vmfs/volumes/ directory. There are typically two ways to reference a datastore: by its human-friendly name or by a UUID identifier. To see this, run:
ls -lh /vmfs/volumes/
This will list the datastores; you might see something like:
drwx—… Datastore1
drwx—… 5a251c85-badd3a98-c863-xxxxxxxxxxxx
The long UUID is the same location as Datastore1 (one is a symlink to the other). You can use either path. For simplicity, we’ll use the datastore name. Make sure you identify the correct datastore that contains your source VM’s folder.

5. Create a Directory for the New VM: Now, make a new directory for the clone on the datastore. For example, if your datastore is named Datastore1 and you want to name the clone VM “VM-Clone”, run:
mkdir /vmfs/volumes/Datastore1/VM-Clone
This creates an empty folder where we will copy the files. Verify it was created:
ls /vmfs/volumes/Datastore1
You should see VM-Clone listed alongside the other VM folders.

6. Copy the VM’s Disk and Config Files: Next, copy the source VM’s key files into the new folder. You will need the path to the source VM’s files (from step 3). Using our example, the source files are in /vmfs/volumes/Datastore1/VM-Main/. We need to copy the .vmx and .vmdk files to the VM-Clone directory. There are two ways to do this:

Option A: Use cp: You can use the cp command to copy files at the datastore level. For example:
cp /vmfs/volumes/Datastore1/VM-Main/VM-Main.vmx /vmfs/volumes/Datastore1/VM-Clone/
cp /vmfs/volumes/Datastore1/VM-Main/VM-Main.vmdk /vmfs/volumes/Datastore1/VM-Clone/
If the VM has additional disks, copy those as well. You could also use a wildcard to copy all disks, but be cautious not to include -00000x.vmdk snapshot files or others you don’t need. The cp command will start copying the disk data; for large disks, the command may take a while with no output. Wait until the shell prompt returns, indicating the copy is done.
Option B: Use vmkfstools -i: VMware provides the vmkfstools utility which can clone virtual disks and even convert their format. This is often recommended by VMware for copying VMDKs rather than a raw cp. The syntax is:
vmkfstools -i “/vmfs/volumes/Datastore1/VM-Main/VM-Main.vmdk” “/vmfs/volumes/Datastore1/VM-Clone/VM-Clone.vmdk” -d thin
Here, the -i option means “clone disk,” and -d thin would make the destination disk thin-provisioned (omit -d thin if you want to keep the same format as source). Make sure the target path is the new .vmdk name in the clone folder. Using vmkfstools has the advantage of ensuring consistency and allowing format change during the copy. However, it accomplishes essentially the same end result as a cp for cloning purposes.

Copy the .vmx file using cp. After these operations, the new VM-Clone folder should contain a copy of the source VM’s .vmx and .vmdk files.

7. Rename the Cloned Files: Now that we have a literal copy of the source files, we should rename them to reflect the new VM’s name. This step isn’t strictly required (the VM will run with any file names), but it avoids confusion and ensures the new VMX references the correct disk name.

First, change into the new VM’s directory:
cd /vmfs/volumes/Datastore1/VM-Clone
Use vmkfstools -E to rename the disk file and update its internal descriptor:
vmkfstools -E “VM-Main.vmdk” “VM-Clone.vmdk”
The -E switch ensures if the VMDK consists of a descriptor and a flat file, both are handled. This will rename VM-Main.vmdk to VM-Clone.vmdk.
Next, rename the VMX config file:
mv “VM-Main.vmx” “VM-Clone.vmx”
After these commands, run ls to confirm the files now use the new VM name. For example, you should see VM-Clone.vmx and VM-Clone.vmdk listed in the directory.

8. Edit the .vmx Configuration File: The VMX file is a text file that contains the VM’s configuration. We need to update a couple of lines inside it that still reference the old VM name. Open the file with a text editor vi. Run:
vi VM-Clone.vmx
Using vi: If you’re not familiar, press i to enter edit mode, use arrow keys to navigate, and press Esc then :wq to save and quit (or :q! to quit without saving). Inside the VMX, look for the following parameters to change:

displayName – this is the name that will show up in the GUI. Change the value in quotes from VM-Main to VM-Clone.
Disk file references – find any line that contains the old VM name, such as those ending in .vmdk. For example, you might see a line like scsi0:0.fileName = “VM-Main.vmdk”. Update it to “VM-Clone.vmdk”. If the VM had multiple disks, update all such lines accordingly. Also check for any .nvram file reference; if present (e.g., nvram = “VM-Main.nvram”), you may rename that file or simply remove that line to let ESXi create a new NVRAM file for the clone.
After editing the necessary lines, save the file and exit vi.

9. Register the New VM: Now that the clone’s files are ready, we must register the VM so ESXi knows about it. Use the vim-cmd command for this. Run:
vim-cmd solo/registervm /vmfs/volumes/Datastore1/VM-Clone/VM-Clone.vmx
If successful, this command will return an output (often a new VMID number). For example, it might return 2 or another ID, indicating the clone VM’s inventory IDterenceluk.blogspot.com. You can verify by running vim-cmd vmsvc/getallvms again. The new VM should be listed now alongside the others, with the name you set and the path to VM-Clone.vmx.

10. Power On the Cloned VM: The VM clone is now registered on the host. You can start it either via CLI or the GUI:

Using CLI: execute vim-cmd vmsvc/power.on <VMID>. Replace <VMID> with the ID returned by the register command or as seen in getallvms. If the power on is successful, this command will return a message or the VM’s new state.
Using GUI: Go back to the Host Client web interface and find the new VM in the inventory. Power it on from there.

In either case, on first boot the VM may pause and ask the “copied or moved” question. If powered on via CLI, the VM will not fully boot until you answer this in the UI. Open the Host Client, click on the new VM, and you should see a notification or prompt to answer a question. Acknowledge that you copied the VM (not moved) to ensure it gets new MAC/UUID values. After answering, the VM will power on fully.

11. Confirm the Clone: Check that the new VM appears in the Host Client with the expected name and that it starts up correctly. It should have the same hardware specs and contents as the source VM at the time of cloning. As with the GUI method, adjust any network settings inside the guest OS if both VMs will be running together to avoid IP/MAC conflicts.

Using the SSH method requires comfort with ESXi’s command-line, but it offers more control. You can, for instance, incorporate these steps into a shell script for automation or use scp/vmkfstools to clone VMs across datastores or hosts.

Method 3: Cloning via VMware PowerCLI (PowerShell Automation)

VMware PowerCLI is a PowerShell module that allows automation of vSphere and ESXi tasks. Even without vCenter, PowerCLI can connect directly to an ESXi host and perform operations using the host’s APIs. This method is ideal if you plan to clone VMs regularly or want to script the process end-to-end. We will use a PowerCLI script to clone a VM on a standalone host.

Prerequisites: You’ll need a machine (Windows, or Linux/Mac with PowerShell Core) that has VMware.PowerCLI installed. You can install it from the PowerShell Gallery by running: Install-Module -Name VMware.PowerCLI. Ensure you have network access to the ESXi host and that the host’s SSH or API is reachable. If the ESXi host uses a self-signed certificate (default), you might need to configure PowerCLI to ignore certificate warnings to avoid connection issues.

Let’s assume we have the following PowerCLI script, Clone-VM.ps1. You can save this text to a .ps1 file on your system. We will go through it section by section to understand how it works:

param(

[Parameter(Mandatory=$true)] [string]$EsxiHostName,

[Parameter(Mandatory=$true)] [string]$EsxiUser,

[Parameter(Mandatory=$true)] [string]$EsxiPassword,

[Parameter(Mandatory=$true)] [string]$VMName, # Source VM name

[Parameter(Mandatory=$true)] [string]$VMNewName # Clone VM name

)

# 1. Connect to the ESXi host

Connect-VIServer -Server $EsxiHostName -User $EsxiUser -Password $EsxiPassword -Force

# 2. Validate source VM existence on host

if (-not (Get-VM -Name $VMName -ErrorAction SilentlyContinue)) {

Write-Host "VM '$VMName' is not found on host $EsxiHostName. Exiting."; exit

}

# 3. Ensure the VM is powered off

if ((Get-VM -Name $VMName).PowerState -ne 'PoweredOff') {

Write-Host "VM '$VMName' is not powered off. Please shut it down before cloning."; exit

}

# 4. Ensure the VM has no snapshots

if (Get-Snapshot -VM $VMName -ErrorAction SilentlyContinue) {

Write-Host "VM '$VMName' has snapshots. Please remove all snapshots before cloning."; exit

}

Write-Host "Source VM checks passed. Proceeding with clone..."

Explanation: The script begins with a parameter block so it can be run like a cmdlet, requiring the ESXi host address, credentials, the source VM’s name, and the new VM’s name.

It connects to the ESXi host using Connect-VIServer. We use -Force to skip any interactive prompts. If successful, your PowerCLI session is now authenticated to the host.
It checks that the source VM exists by attempting Get-VM -Name $VMName. If the VM is not found, the script outputs a message and exits to avoid proceeding further.
It checks that the VM is powered off. Cloning a running VM isn’t allowed here. If the VM is powered on, the script will exit with a message.
It checks for snapshots on the source VM using Get-Snapshot. If any snapshot exists, it aborts. This automates the best practice we discussed.

If all checks pass, it prints a confirmation message and moves on.

# 5. Determine datastore info for the source VM

$vmObject = Get-VM -Name $VMName

$vmDatastore = (Get-Datastore -Id ($vmObject.DatastoreIdList[0]))

$VMDatastoreName = $vmDatastore.Name

$VMDatastorePath = $vmDatastore.DatastoreBrowserPath

# Define source and destination paths in the datastore

$VMSourceFolder = "$VMDatastorePath\$VMName\"

$VMDestinationFolder = "$VMDatastorePath\$VMNewName\"

# 6. Create a temporary folder on local machine for config files

$TempLocalPath = Join-Path -Path (Split-Path $MyInvocation.MyCommand.Path) -ChildPath $VMNewName

New-Item -Path $TempLocalPath -ItemType Directory -Force | Out-Null

Here, the script gathers information about where the VM’s files are stored:

It gets the VM object and then retrieves the datastore that VM is on. $vmObject.DatastoreIdList provides one or more datastore IDs. Here we take the first ID for simplicity, assuming the primary storage of the VM. We fetch that datastore as $vmDatastore and grab its Name and DatastoreBrowserPath. The DatastoreBrowserPath is a PowerCLI representation of the datastore path. It’s used by certain file copy cmdlets.

Using these, it builds a string for the source folder and a target folder path on the datastore. For example, $VMSourceFolder might end up as something like "vmstore:\MyHost\Datacenter\Datastore1\VM-Main\" and $VMDestinationFolder as "vmstore:\MyHost\Datacenter\Datastore1\VM-Clone\".

Next, it creates a temporary directory on the local machine running the script (not on ESXi) to store copies of the VMX and related small files. It uses the script’s own folder and creates a subfolder named after the new VM. We’ll see why in the next steps.

# 7. Copy VM configuration files (VMX, etc.) from datastore to local temp folder

$configFiles = Get-ChildItem -Path $VMSourceFolder -Filter "*.vmx" -Recurse

foreach ($file in $configFiles) {

$dest = "$TempLocalPath\$($file.Name.Replace($VMName, $VMNewName))"

Copy-DatastoreItem -Item $file -Destination $dest -Force -Confirm:$false -Verbose

}

# 8. Modify the configuration files for the new VM

Get-ChildItem -Path $TempLocalPath -Filter "*.vmx" | ForEach-Object {

(Get-Content $_ -Raw) -replace $VMName, $VMNewName | Set-Content $_ -Force

}

In this part, the script handles the VM’s configuration files:

It retrieves the list of config files from the source VM’s folder. We filter for *.vmx and possibly .vmxf or other config-related files, though .vmx is primary. The script uses -Recurse and some filtering to avoid copying disk files at this stage.
Then for each such file, it constructs a destination path in the temp folder, replacing the old VM name with the new name in the filename. For example, VM-Main.vmx would become VM-Clone.vmx in the temp folder. It uses Copy-DatastoreItem to pull the file from the datastore to the local machine (PowerCLI handles the download via the API). Now we have a local copy of the VMX.
Next, it opens each local config file and does a search-and-replace of the old VM name with the new VM name inside the file’s contents. This is akin to editing the displayName and disk file references, just like we did manually in Method 2, but automatically. The -replace $VMName, $VMNewName will substitute all occurrences of “VM-Main” with “VM-Clone”. This should update lines such as displayName, any .vmdk references that include the VM’s name, etc. The modified text is then written back with Set-Content.

At this point, the temp folder’s VMX file is adjusted for the new VM.

# 9. Create the new VM folder on datastore and upload modified config files

New-Item -Path $VMDestinationFolder -ItemType Directory -Force | Out-Null

$localConfigFiles = Get-ChildItem -Path $TempLocalPath -Filter "*.vmx"

foreach ($file in $localConfigFiles) {

Copy-DatastoreItem -Source $file.FullName -Destination $VMDestinationFolder -Force -Confirm:$false -Verbose

}

# Remove the local temp folder as it's no longer needed

Remove-Item -Path $TempLocalPath -Recurse -Force

This segment handles creating the new VM’s folder on the datastore and putting the modified VMX there:

It uses New-Item with the datastore path to ensure the destination folder exists. The -Force ensures no error if it already exists.
Then it takes the edited config file(s) from the local temp and uploads them to the datastore using Copy-DatastoreItem. Now the datastore has a folder for the new VM containing a VMX that is already adjusted for the new VM name.
It cleans up by deleting the temp folder on the local machine, since it’s not needed anymore.

# 10. Copy each virtual disk to the new VM folder on the datastore

$hardDisks = Get-HardDisk -VM $VMName

foreach ($disk in $hardDisks) {

$newDiskPath = ($disk.Filename -replace $VMName, $VMNewName)

Copy-HardDisk -HardDisk $disk -Destination $newDiskPath -Force -Verbose

}

# 11. Copy miscellaneous files (nvram, logs) if needed

$otherFiles = Get-ChildItem -Path $VMSourceFolder -Include "*.nvram","*.vmsd","*.log" -Recurse

foreach ($file in $otherFiles) {

$dest = "$VMDestinationFolder$($file.Name.Replace($VMName, $VMNewName))"

Copy-DatastoreItem -Item $file -Destination $dest -Force -Confirm:$false -Verbose

}

Now the script copies the virtual disk(s) and any other important files:

It gets all hard disks of the source VM with Get-HardDisk -VM $VMName. For each disk object, it computes a new destination path by replacing the old VM’s name with the new name in the filename. For example, if a disk file is [Datastore1] VM-Main/VM-Main.vmdk, it changes it to [Datastore1] VM-Clone/VM-Clone.vmdk.
It then uses Copy-HardDisk to clone the disk to that destination. Copy-HardDisk is a PowerCLI cmdlet that will copy the contents of a VMDK to a new VMDK on a datastore. This is analogous to using vmkfstools -i under the hood – it preserves the disk format unless specified otherwise, and is an online operation via the host API. The -Force and -Verbose flags ensure it overwrites if needed and shows progress messages. This step can take a while for large disks, and you’ll see progress output in the PowerCLI console.
After disks are copied, the script also copies other supporting files: NVRAM file if present, VM snapshots metadata, and perhaps log files. These aren’t strictly necessary for the VM to run, but copying the NVRAM file can preserve BIOS settings. This loop takes each such file and uses Copy-DatastoreItem to copy it to the new folder, similarly replacing the name.

# 12. Register the cloned VM on the host and power it on

New-VM -Name $VMNewName -VMHost $EsxiHostName -VMFilePath "[${VMDatastoreName}] $VMNewName/$VMNewName.vmx" -Confirm:$false -Verbose

Start-VM -VM $VMNewName -Confirm:$false -Verbose

(Get-VMQuestion -VM $VMNewName) | Set-VMQuestion -Option "I Copied It" -Confirm:$false

# 13. Disconnect from the host

Disconnect-VIServer -Server $EsxiHostName -Confirm:$false

Finally, the script registers and starts the VM:

It uses New-VM with the -VMFilePath parameter pointing to the clone’s VMX on the datastore. New-VM in this context doesn’t actually create a brand new VM from scratch; when a VMFilePath is provided, it effectively tells the host “register the VM from this VMX file”. We also provide -Name $VMNewName and -VMHost to ensure it’s registered correctly. The script sets -Confirm:$false to avoid any confirmation prompts. After this, the new VM appears in the host’s inventory.
It then immediately tries to power on the VM with Start-VM. The -Confirm:$false avoids the “are you sure” prompt. The script uses -Verbose for additional output – you’ll see task info during execution.
The next line addresses the post-power-on question. It fetches any pending questions on the VM using Get-VMQuestion, then pipes it to Set-VMQuestion -Option “I Copied It”. This automatically answers the relocation question with “I Copied It”. This step ensures the VM will actually resume booting without requiring manual intervention in the GUI or console.
Finally, the script disconnects the PowerCLI session from the ESXi host (Disconnect-VIServer) to cleanly log out.

After the script completes, the new VM should be up and running on the ESXi host. The script outputs verbose messages throughout, so you can see each action’s status in the console. For instance, you’ll see confirmation of file copies, the new VM creation, and it powering on. If any step fails, the verbose output or error messages will indicate it.

Conclusion

Cloning a VM on a standalone ESXi host is entirely feasible with a bit of extra effort. We’ve covered three methods:

Each method has its use-cases: the Host Client is quick for the occasional clone, SSH gives granular control and is usable even if the host UI isn’t accessible, and PowerCLI is excellent for automation and integrating into broader workflows. Whichever method you choose, always remember to follow best practices: no active snapshots during clone, ensure VMs are powered off, and double-check that the new VM is using its own independent disks before powering on to avoid any chance of two VMs inadvertently writing to the same VMDK.

Lastly, for further reading and official guidance, VMware’s documentation and knowledge base provide additional context – for example, VMware KB articles on manually moving or registering VMs and on using vmkfstools to clone disks can offer deeper insights. By understanding the cloning process, you not only accomplish the immediate task at hand, but also gain insight into how ESXi manages VM files and registrations, which is useful for troubleshooting and advanced administration. Happy cloning!