Move a Virtual Machine in VMware Player
Safely move a VMware Player virtual machine to another folder or computer while preserving its configuration, disks, and data.
A virtual machine (VM) is a software-defined computer with a guest operating system, virtual hardware, configuration, and virtual disks. VMware Player commonly stores these components as a collection of files inside a VM directory.
Moving a VM means copying that complete collection to a new location and opening its VMware configuration file there. You can move it to another folder on the same host system, or transfer it to a different physical host computer. A VM can generally move between hosts running different operating systems, provided the destination supports VMware Player, the guest operating system, and the VM's virtual hardware requirements.
Plan the Move and Check Compatibility
The host system is the physical computer running VMware Player. The guest operating system is the operating system installed inside the VM. Before transferring the VM, verify that the destination host can provide enough resources and compatible virtualization support.
- Confirm that VMware Player can run on the destination host and supports the guest operating system.
- Check the VM's virtual hardware requirements, including processor features, memory, storage, and required devices.
- Verify that the destination has enough free storage for the entire VM directory, including virtual disks, snapshots, and temporary working files.
- Reserve adequate host RAM and CPU capacity so the VM can run without starving the host or other workloads.
- Consider hardware differences. They can affect guest drivers, operating-system activation, performance, virtual device availability, and application behavior.
- Review removable devices, USB passthrough, shared folders, mapped host paths, and other host-specific settings. These may need to be configured again.
CPU Architecture and 64-bit Guests
A move from a 32-bit host environment to a 64-bit host is generally supported. The reverse direction needs more care. A 64-bit guest or VM moved to a 32-bit host may run only if the destination has supported 64-bit processor capabilities and the complete host software stack supports running that 64-bit workload. A 64-bit-capable CPU by itself is not enough if the destination operating system or VMware Player installation is limited to 32-bit operation.
When in doubt, use a compatible 64-bit host with the required processor virtualization support and a VMware Player version that supports the VM's hardware compatibility level.
Identify Every VM File
Start by locating the VM directory in the host operating system's file manager. The .vmx file is the VMware virtual machine configuration file. It stores settings that VMware Player uses to identify and open the VM.
A typical VM directory can contain:
- A
.vmxconfiguration file. - One or more virtual disk files, often using a
.vmdkextension. A disk may be split into multiple segment files, and every segment must remain together. - Snapshot-related files, if snapshots exist.
- VM log files and other associated configuration or state data.
- Additional files created by the guest or VMware integrations.
Verify that all required files are in the main VM directory before copying. A virtual disk or working file can sometimes be stored elsewhere. The working directory is a location VMware may use for VM-related files separately from the primary VM directory.
If a separate working directory is configured, identify its required contents, move those contents into the main VM directory, and change the VM's working-directory setting to use the consolidated location before beginning the transfer. The guide to changing a virtual machine's working directory covers that configuration task.
For additional background, see VMware virtual machine files and what a virtual disk is.
Shut Down the VM Completely
Use the guest operating system's normal shutdown command, then wait until VMware Player shows the VM as powered off. Do not copy a VM while it is running or suspended.
A running VM can still be changing virtual disk files. A suspended VM also depends on memory-state and device-state files. Copying during either condition can produce an inconsistent set of files that fails to resume, boots incorrectly, or reports disk errors.
After the VM is powered off, confirm that VMware Player is no longer writing to the VM directory. Close any relevant VMware Player window if necessary, and do not start the VM again until the copy has completed.
Copy the Complete VM Directory
Copy the entire VM directory to the destination folder, external storage, or destination host. Preserve the internal file structure, file names, and all virtual disk segments.
Copy first rather than deleting or moving the original immediately. Keeping the source copy provides a recovery option until the destination VM has booted and passed testing.
Source: C:\VMs\Ubuntu\
Destination: E:\VMs\Ubuntu\For a different host, transfer the complete directory over a trusted network share or external storage. Check that the transfer finishes without errors. Compare the source and destination contents and confirm that large virtual disk files have plausible matching sizes. Do not rename disk segments or omit files simply because their names look unrelated.
| Item | Source | Destination |
|---|---|---|
| VM directory | C:\VMs\Ubuntu | E:\VMs\Ubuntu |
| VM configuration file | C:\VMs\Ubuntu\Ubuntu.vmx | E:\VMs\Ubuntu\Ubuntu.vmx |
| Transfer method | Local disk | File copy, external storage, or network transfer |
| Validation result | Original retained | Boot, disks, network, and integrations tested |
Open the Relocated VM in VMware Player
- Install or start VMware Player on the destination host.
- Choose File > Open.
- Browse to the copied VM directory.
- Select the VM's
.vmxconfiguration file. - Review any prompt about whether the VM was moved or copied.
The .vmx file, not an individual virtual disk file, is the normal entry point for an existing VM. If VMware Player asks whether the VM was moved or copied, choose the answer that matches what you did. This choice can affect the VM's identity, including its virtual network adapter MAC address.
Understand MAC Address and Network Identity Changes
A MAC address is a hardware identifier assigned to a network adapter. Moving or copying a VM does not have one universal MAC-address outcome: VMware Player commonly preserves the existing virtual MAC address when you confirm that the VM was moved, while choosing that it was copied typically causes VMware Player to generate a new MAC address.
Check the resulting address and guest network behavior rather than assuming either outcome. A changed MAC address can affect:
- DHCP leases and reserved IP addresses.
- Firewall rules and network access-control policies.
- Monitoring or inventory systems that identify devices by MAC address.
- Software licenses or applications tied to network identity.
- Guest operating-system network configuration and adapter naming.
After the first boot, update DHCP reservations, firewall rules, or other MAC-based policies when appropriate. Review VMware Player's virtual networking components and the relevant networking configurations if the destination host uses a different network design.
Validate the Moved VM
Power on the VM from its new location and test the workload systematically:
- Confirm that the guest operating system boots without disk or configuration errors.
- Open files and applications that depend on the virtual disks.
- Check guest network connectivity, addressing, DNS, and access to required services.
- Verify VMware Tools integration, including display resizing or other guest integrations used by the workload.
- Test shared folders and confirm that their host paths still exist on the destination.
- Reconnect and test USB passthrough or other removable devices that matter to the VM.
- Check display behavior, sound, and any other virtual devices required by the guest.
- Observe performance and confirm that the destination has sufficient CPU and memory resources.
Keep the original VM copy until these checks succeed. If the destination VM fails, power it off before comparing files or attempting another transfer.
| Area | Possible change | Recommended verification |
|---|---|---|
| CPU and virtualization support | Different processor features or unavailable virtualization support | Confirm host compatibility and test boot and performance |
| Memory availability | Less RAM available for the VM | Review allocation and host free memory |
| Network adapter MAC address | Address preserved or regenerated according to the move/copy choice | Check the adapter and update MAC-based policies |
| Guest network settings | Different DHCP lease, adapter name, or access policy | Test IP configuration, DNS, and connectivity |
| USB and other host-attached devices | Devices may not exist or may require reconnection | Reconnect and test required devices |
| Shared folders and host paths | Old paths may not exist on the destination | Reconfigure and test shared folders |
Move Checklist
| Step | What to verify or do | Why it matters |
|---|---|---|
| Check destination host compatibility | Verify VMware Player, guest OS, VM hardware, CPU architecture, RAM, CPU, and storage support. | Prevents an incompatible host from receiving the VM. |
| Locate and consolidate all VM files | Find the .vmx, virtual disks, snapshots, and externally stored working files. | Prevents missing-file and missing-disk errors. |
| Power off the VM | Perform a full guest shutdown and confirm VMware Player is no longer writing. | Creates a consistent copy. |
| Copy the complete VM directory | Preserve names, disk segments, structure, and file contents; retain the source. | Allows recovery if validation fails. |
Open the .vmx file at the destination | Use File > Open and select the copied configuration file. | Loads the VM's complete configuration. |
| Start and validate the VM | Test boot, disks, applications, tools, display, devices, and performance. | Confirms that the copy is usable. |
| Confirm networking after the MAC-address decision | Check the resulting MAC, DHCP, firewall rules, and connectivity. | Prevents network identity conflicts. |
| Retain or remove the source copy | Delete the old copy only after successful testing and after checking backup needs. | Avoids premature data loss. |
Troubleshooting
The VM Does Not Open
Make sure you selected the .vmx file rather than an individual virtual disk. If the VM still does not open, compare the source and destination directories, recopy missing files, and preserve the original directory structure.
The VM Reports a Missing Disk or Fails to Boot
A virtual disk segment may have been omitted or renamed, or a referenced disk may have been outside the main VM directory. Restore the missing files from the source copy and check external working-directory or disk locations. Consolidate those files and update the working-directory setting before moving the VM again.
The Moved VM Has No Network Access
Confirm that the virtual adapter is enabled and connected, then inspect the guest's IP configuration. Check whether VMware Player preserved or regenerated the MAC address based on your move/copy response. Update DHCP reservations, firewall rules, and access controls if they still reference the previous address.
Also check whether the destination host uses a different NAT, bridged, or host-only setup. Relevant guides include NAT networking, bridged networking, and host-only networking.
The VM Performs Poorly or Devices Are Unavailable
Compare the destination's RAM, processor capacity, and virtualization support with the VM's allocation. Reconfigure shared folders, USB devices, and other host integrations that are not present on the new host. You may also need to adjust memory using VM memory allocation or review VM hardware compatibility.
A 64-bit VM Cannot Run on the Destination
The destination may lack supported 64-bit processor capabilities, or its host operating system or VMware Player installation may be constrained by 32-bit limitations. Use a compatible 64-bit-capable host and confirm that its complete hardware, operating system, and VMware software stack supports the guest.
Post-Move Cleanup
Once the destination VM has passed validation, remove the old copy only if it is no longer needed and an appropriate backup exists. Do not run both copies on the same network when they share a hostname, IP address, credentials, application identity, or other identity-dependent settings; duplicate instances can conflict with one another.
Finally, update shortcuts, backup jobs, automation, documentation, and storage references to use the new VM path. For related tasks, see deleting virtual machines, shared folders, and connecting USB devices.