Copying a Virtual Machine

Lesson purpose

A physical server is a box of hardware; a virtual machine is a set of files. That single fact changes how servers are copied, deployed, protected, and tested. A new server can be a file copy plus a few identity changes, a standard build can be stamped out from a template in minutes, and a snapshot can act as an Undo button before a risky patch. Students should leave able to identify the files that make up a VM, clone one manually and with a vendor tool, explain what makes a clone unique, describe templates and golden images, and use snapshots correctly without mistaking them for backups.

Learning objectives

By the end of the lesson, students should be able to:

Identify the files that make up a VMware virtual machine and state which ones matter when copying it.
Clone a VM manually and with a hypervisor tool, and explain why the tool is preferred.
List the identifiers that must be unique in a clone (name, UUID, MAC, IP, SID) and the role of Sysprep.
Distinguish full clones from linked clones and cloning from deploying a template.
Explain how snapshots work (parent disk, sparse child disks, copy-on-write) and how revert, delete, and merge behave.
Explain why snapshots are not backups and why virtual sprawl is a risk.

1. Virtual machines are files

Backup has always mattered, from tape to USB drives to cloud sync services. Because a VM’s physical form is a set of data files, copying those files captures everything: the operating system, applications, user data, and the virtual hardware configuration. The copy is both a backup and a fully functional VM that a hypervisor can start.

Key VMware files (from the slides and the book):

File	Purpose
`.vmx`	Configuration file: describes the virtual hardware (CPU, memory, disks, NICs)
`.vmdk`	Virtual disk file(s): hold the data
`.vmsd`, `.vmsn`, `.vmem`	Snapshot metadata, saved VM state, and memory state
`.nvram`	Virtual firmware (BIOS/UEFI) settings
`.log`	Log files
`.vmss` / paging files	Suspended state and swap, created while running

Only the .vmx and .vmdk files are essential for a copy; the rest are re-created when the VM powers on.

Why this speeds provisioning:

A copy with a few configuration changes is faster than installing a VM from scratch, and far faster than ordering, racking, and provisioning a physical server.
Virtual hardware is consistent from VM to VM and host to host, which removes firmware and driver mismatches common with physical servers.

2. Cloning a VM manually (and why not to do it in production)

The book walks through a manual copy in VMware Workstation Player because Player had no clone feature. It edits the .vmx by hand, which Lesson 4 warned against. The reasons for doing it anyway: it is a throwaway lab VM, it builds familiarity with the configuration file, and it shows exactly what a clone tool automates. This is not the recommended way to create VMs. Current VMware Workstation Pro (free for personal and educational use) includes a built-in Clone command, so students can compare both methods.

Steps:

Find the VM folder. In the VM settings, Options > Working directory shows it; the default is C:\Users\<username>\Documents\Virtual Machines.
Create a new folder named VM Copy.
Turn on file extensions in File Explorer (View > Show > File name extensions in Windows 11).
Copy only the .vmx and the .vmdk file(s) into VM Copy. There are two disks if students added the second drive in Lesson 9.
Open the copied .vmx in Notepad and replace every occurrence of the old name (for example, Windows 10 x64) with VM Copy. Use Edit > Replace, but do not change the guestOS line, which tells VMware what OS is installed.
Rename the copied files to match: VM Copy.vmx, VM Copy.vmdk, and VM Copy-0.vmdk for the second disk.
Double-click the .vmx to open and power on the VM.
When VMware asks whether the VM was moved or copied, choose I Copied It.

A portion of the edited configuration file might look like this:

displayName = "VM Copy"
guestOS = "windows9-64"
nvram = "VM Copy.nvram"
scsi0:0.fileName = "VM Copy.vmdk"
scsi0:1.fileName = "VM Copy-0.vmdk"

displayName: the name shown in the VM library.
guestOS: the OS type; leave it alone.
nvram: the firmware settings file for this VM.
scsi0:0.fileName and scsi0:1.fileName: the disks on the first and second SCSI slots. These must match the renamed .vmdk files exactly or the VM will not boot.

Troubleshooting: if it does not boot, the .vmx edits or the file names do not match. If the original disk was split into multiple files (not stored as a single file in Lesson 4), copy every piece and also edit the small descriptor .vmdk, which points to the other pieces.

Is the copy identical?

The same username and password work, and ipconfig shows the same number and type of adapters.
IP addresses may differ. Answering I Copied It generated a new UUID (and new MAC addresses), so DHCP hands out new addresses. Answering I Moved It keeps the original identity. A static IP would be duplicated and must be changed by hand.
Control Panel > System shows the same computer name. In any real network, two machines with the same name and address would conflict.

Clean up with Shut Down Guest, then right-click the copy and choose Delete VM From Disk.

3. Making clones unique

A clone is an exact copy, so it needs final customization before it joins a network. Identifiers to change:

Computer (host) name
VM UUID (regenerated by I Copied It)
MAC addresses of virtual NICs
IP addresses, especially static ones, and any matching DNS entries
Hard-coded names or addresses inside applications
On Windows, the security identifier (SID) and domain membership

Without these changes, two active systems with the same name or address “wreak havoc” on networking and applications.

Sysprep is Microsoft’s utility for preparing a Windows image for duplication. Running it with the generalize option strips machine-specific identity, so each deployed copy gets a unique identity on first boot. It can also add device drivers and applications. Each Windows version has its own Sysprep. Linux has its own equivalents, such as resetting the machine ID and SSH host keys or using cloud-init.

Scale matters. Copying one VM by hand is manageable; copying a hundred or five hundred is slow and error-prone. Administrators automate cloning with scripts or with management tools from the hypervisor vendor or third parties, which handle naming, addressing, and guest customization consistently.

4. Cloning with a vendor tool (VirtualBox)

In Oracle VirtualBox, select the VM and choose Machine > Clone (or right-click it).
Enter a unique name.
Set the MAC address policy to generate new MAC addresses for all network adapters (older versions show this as a Reinitialize the MAC address checkbox).
Choose the clone type and keep Full clone.
Select Clone. Progress depends on disk size (the book’s version of the progress dialog shows Dolly the Sheep).
Start the clone, log in with the original password, and compare its system name and MAC addresses with the original.

Full vs. linked clones

	Full clone	Linked clone
What it is	An independent, complete copy	A copy that references the original’s disk and stores only its changes in a delta disk
Storage	Same space as the original	Much less
Dependency	None	The original (or snapshot) must remain available
Performance	Normal	Can suffer, depending on workload and storage

5. Templates and golden images

Cloning needs a clean source. A template is a golden image: a validated, approved build with the OS, current patches, corporate-standard utilities, and sometimes applications. The idea came from physical provisioning, where an approved image was written to read-only media and applied to new servers.

How a template differs from an ordinary VM:

It includes the virtual hardware configuration as well as the software.
It usually cannot be powered on. It is a mold, kept read-only to prevent unintended changes.
It is created by building a clean VM and then converting it with a management tool.

In VMware vCenter (which manages ESXi hosts), the clone menu offers: clone to a virtual machine, clone to a template, or clone to a template in a content library. A VM can also be converted directly into a template.

Workstation Pro example (clone from a template):

In the source VM’s settings, Options > Advanced, check Enable Template mode.
Take a snapshot of the VM to serve as the clone source.
Choose VM > Manage > Clone. The wizard reminds you to enable template mode.
Select the snapshot as the clone source.
Choose Full clone or Linked clone.
Name the new VM and finish. It appears in the library, configured identically to the template.

Tool-based cloning is faster and much less error-prone than the manual method. Several clones can run at once, but cloning is mostly data copying, so storage I/O limits how many run well at the same time (Lesson 9).

6. Snapshots: saving a VM’s state

Why they matter for testing

Before virtualization, testing a patch or upgrade meant building a physical server that exactly matched production. Test environments in large organizations could be three to five times larger than production, and they were a bottleneck. With VMs, you clone production or deploy its template in minutes, apply the change, and test. If the change passes, the updated VM can become the new template.

A snapshot captures a VM’s configuration, disk state, and optionally its running memory state at a moment in time. You can return to that point again and again, effectively an Undo button for a server. All major hypervisors support snapshots; the details below are VMware’s.

What a snapshot creates

.vmsd: snapshot metadata (the snapshot tree)
.vmsn: the VM’s saved state at snapshot time
.vmem: the memory contents (when memory is included)
Child disks (.vmdk files numbered 000001, 000002, and so on), one per virtual disk

The child disk is a sparse disk using copy-on-write:

The parent disk is locked; nothing new is written to it.
Every changed block is written to the child disk.
Reads come from the child disk for changed blocks and from the parent for everything else.

Taking a second snapshot locks the first child disk and creates a second child. Each additional snapshot adds another layer the VM must search to find the current version of a block.

Lab walkthrough (Workstation Pro)

Power on the cloned VM and take Snapshot v1 (toolbar button or VM > Snapshot > Take Snapshot).
Look at the VM folder: new .vmem, .vmsd, .vmsn, and a -000001.vmdk child for each disk.
Open the Snapshot Manager to see the map.
Create a Notepad file on the desktop. (Even with no user action, logs keep adding blocks to the child disk.)
Take Snapshot v2, then edit and save the Notepad file. A second set of child disks and state files appears.
Right-click Snapshot v2 and choose Go To Snapshot (revert). Workstation warns that changes since the snapshot will be lost. The Notepad file returns to its original text.
Revert to Snapshot v1. The Notepad file does not exist at all.

Snapshots can also form branches: revert to v1, make different changes, and take v3, giving two paths from the same starting point for comparing test scenarios.

Delete, merge, and discard

VMware’s wording is confusing: deleting a snapshot merges (consolidates) its changes into its parent. It does not undo them.

To keep tested changes (for example, patches that proved safe): delete the snapshots from the current state. The second child disk merges into the first, the first merges into the parent disk, the parent is unlocked, and the snapshot files are removed. Merging does not grow the parent disk beyond its configured size.
To discard changes: revert (Go To Snapshot) first, then delete the snapshots you no longer need.

Snapshots are not backups

Each child disk can grow as large as its parent, so long-lived or numerous snapshots consume large amounts of storage.
Long snapshot chains slow the VM because reads must search more layers, and the extra I/O hurts neighboring VMs.
Snapshots live on the same storage as the VM. If that storage fails, the snapshots are lost too.

Use snapshots for short-term testing and change windows, then remove them. Real backups are covered with availability in Lesson 13.

7. Virtual sprawl

Cloning and templates make new VMs so fast and cheap that organizations can end up with virtual sprawl: too many VMs deployed without life-cycle management. Forgotten VMs still consume CPU, memory, storage, licenses, and patching effort, and unpatched ones are security risks. Pair fast provisioning with ownership, naming standards, review dates, and decommissioning.

Classroom application

Lab sequence:

Manually copy a VM using the steps in section 2 and record which files were copied and which were re-created at power-on.
Open the original and copied .vmx files side by side and compare the uuid.location and uuid.bios entries. They differ because I Copied It generated a new identity; they would match if students chose I Moved It or had not yet powered on the copy.
Clone a VM in VirtualBox with new MAC addresses and compare the MAC addresses and computer names.
On the VirtualBox clone, take a snapshot, make a change, take more snapshots between further changes, then revert to the first snapshot and to a middle snapshot. Record what each revert keeps and removes. (Reverting to the first snapshot removes every later change; reverting to a middle one keeps only the changes made before it.)

Checks for understanding:

Which two VMware file types must be copied to duplicate a VM?
Why did the clone get a new IP address but keep the same computer name?
What identifiers must be unique before a clone joins a production network?
When would you choose a linked clone? What is the risk?
Why is a template usually unable to power on?
In VMware, what does deleting a snapshot do to the changes made after it?
Give two reasons snapshots are not a backup strategy.

Common misconceptions

“A clone is ready to use as soon as it’s copied.” It needs a unique name, addresses, and (on Windows) a generalized identity.
“A linked clone is independent.” It depends on the original disk; losing that disk breaks the clone.
“A template is just a VM with a label.” It is a protected, usually non-bootable golden image meant only for deployment.
“Deleting a snapshot throws away the changes.” In VMware, deleting merges changes into the parent; revert first to discard them.
“Snapshots are backups.” They live on the same storage, grow over time, and degrade performance.
“More snapshots are always safer.” Each one adds storage use and read overhead.

Lesson summary

Because a VM is a set of files (mainly the .vmx configuration and .vmdk disks), it can be copied, deployed, and restored far faster than a physical server. Manual copies show the mechanics, but vendor tools clone more reliably and must still be paired with identity changes such as new names, UUIDs, MAC and IP addresses, and Sysprep for Windows. Full clones are independent; linked clones save space but depend on the original. Templates serve as locked golden images for consistent deployments. Snapshots lock the parent disk and write changes to sparse child disks, giving testers a repeatable Undo point, but they must be merged or removed promptly and never used as backups. The same speed that makes these tools powerful can cause virtual sprawl, so fast provisioning needs life-cycle management.