# VM Migration and Cloning

> Chapter 7 of the Courseiva VMWARE-VCP-DCV curriculum — https://courseiva.com/learn/vmware-vcp-dcv/vm-migration-and-cloning

**Official objective:** 2.4 — Perform virtual machine migration and cloning operations

## Introduction

How do you keep servers running 24/7 when you need to perform maintenance, upgrade hardware, or fix a fault? That's the problem that VM migration and cloning solve for anyone studying the VCP-DCV exam. These operations let IT teams move or copy virtual machines with zero or minimal disruption, transforming how data centres handle updates, load balancing, and disaster recovery.

## The Packing a Moving Truck Analogy

A moving truck is the central tool for transporting household belongings from one house to another without losing or damaging anything.

Imagine you live in a house with all your furniture, clothes, and kitchenware, and you need to move to a new house across town. You could carry everything by hand, one item at a time, which would take days, risk breaking fragile things, and leave your old house empty while nothing is set up in the new place. Instead, you hire a moving truck. You carefully pack boxes, load the truck, drive it to the new house, and unload everything exactly as it was. Your belongings stay intact, the move is quick, and you can start living normally in the new house immediately.

Now imagine you want an identical copy of your current house's setup for a holiday home. You don't move your original furniture—you create a perfect duplicate: same sofa, same plates, same pictures on the wall. That's cloning. You end up with two independent houses, each with the same contents, but one can be modified without affecting the other.

In VMware, virtual machine migration (moving a VM while it runs) is like that moving truck—it transfers the entire VM's memory, storage, and settings to another host without downtime. Cloning is like the duplicate holiday home—it creates an exact copy of a VM so you can use it for testing, backups, or scaling up without touching the original.

## Core explanation

Virtual machines (VMs) are software-based computers running on a physical host server. Each VM has its own operating system, applications, and data, but it shares the underlying hardware with other VMs through a hypervisor (the layer that manages VMs). Migration is the process of moving a running VM from one physical host to another without turning it off. Cloning creates an exact duplicate of a VM that can be started independently.

Why do these capabilities exist? Traditional physical servers required downtime for maintenance—if you needed to replace a power supply or upgrade RAM, the server had to be switched off, taking all its services offline. With migration, you can move a live VM to another host, perform maintenance on the original host, then move it back—all without users noticing. Cloning exists because IT teams often need test environments, backups, or multiple identical servers quickly. Instead of manually installing an operating system and applications from scratch—which takes hours—you clone a pre-configured VM in minutes.

How do they work? VMware vMotion is the flagship migration technology. When you initiate a vMotion migration, the hypervisor copies the VM's memory (its active data) from the source host to the destination host over the network, while the VM continues to run. This happens in three phases: first, the hypervisor copies all memory pages to the destination; second, it tracks which memory pages changed during the copy; third, it copies those changed pages repeatedly until the difference is tiny—then it pauses the VM for a fraction of a second, copies the final changes, and resumes the VM on the destination host. The user sees no interruption. For storage, storage vMotion moves VM files from one datastore to another while the VM runs, using a similar iterative copy technique.

Cloning uses a different approach. The hypervisor takes a snapshot (a point-in-time state) of the source VM, then copies its virtual disk files, configuration, and memory state to create a new VM. You can create a full clone (completely independent, uses its own disk space) or a linked clone (shares the parent VM's disk and only stores changes—saving storage but requiring the parent to exist).

What do these operations replace? Before virtualisation, cloning meant buying duplicate physical hardware and manually installing everything. Migration meant taking servers offline, which could mean hours of downtime for large applications. These VMware features eliminate those pain points, making data centres more agile and resilient.

Key components to understand:

- Hypervisor: the software layer (like VMware ESXi) that creates and runs VMs.
- Host: the physical server running the hypervisor.
- vMotion: live migration of a VM's memory and execution state.
- Storage vMotion: live migration of a VM's disk files.
- Snapshot: a saved state of a VM at a specific moment, used before cloning.
- Full clone: an independent copy that doesn't rely on the source.
- Linked clone: a copy that shares disk with the source to save space.

For VCP-DCV, you must know the prerequisites for each operation. vMotion requires: shared storage (both hosts can access the same datastores), compatible CPUs (or Enhanced vMotion Compatibility - EVC), a VMkernel network interface dedicated to vMotion traffic, and sufficient network bandwidth. Storage vMotion doesn't require shared storage—it moves data between datastores directly. Cloning doesn't require the VM to be powered on or off; you can clone a powered-on VM, but the resulting clone will be in a consistent state only if you use VMware Tools quiescence (which flushes pending disk writes).

The practical effect is simple: migration enables zero-downtime maintenance, load balancing across hosts, and disaster avoidance. Cloning enables rapid provisioning, testing, and backup verification. Both are foundational to any modern virtualised data centre.

## Real-world context

Sarah is a junior data centre administrator for a mid-sized e-commerce company. The company runs its online store, inventory system, and customer database on a cluster of four VMware ESXi hosts. On a Tuesday morning, the system sends an alert: Host-03 has a failing memory module. The vendor says the replacement will arrive on Wednesday, but the e-commerce site must stay online continuously—downtime means lost sales.

Sarah logs into vCenter, the central management tool. She identifies the five VMs running on Host-03, including the critical database server and the web front-end. Using vMotion, she migrates each VM to other hosts in the cluster while they remain live. Customers continue browsing, placing orders, and checking out without any interruption. One VM, the inventory system, has its virtual disk on a local datastore that's not shared, so she uses Storage vMotion to move its files to a shared storage array, then migrates it with regular vMotion. The entire process takes an hour, and she documents each step.

The next day, her manager asks her to test a new security patch for the web server. Sarah doesn't want to risk breaking the live site. She creates a full clone of the web server VM, isolating it on a separate test network. She applies the patch, runs tests, and finds a conflict with the payment gateway. She rolls back by deleting the clone and reports the issue. The live site remains untouched.

Later that week, the company launches a marketing campaign that increases traffic by 300%. Sarah uses cloning to spin up four additional web server VMs from a template (a master copy), balances the load, and the site handles the spike easily.

Sarah's daily tasks with these features:

- Scheduling maintenance windows for host firmware updates using vMotion to evacuate VMs beforehand.
- Creating linked clones for developers who need isolated environments to test new features.
- Using storage vMotion to relocate VMs to faster SSDs when performance degrades on slow hard drives.
- Setting up disaster recovery by cloning critical VMs to a secondary site.
- Verifying that vMotion prerequisites are met (compatible CPUs, sufficient network ports, VMkernel interfaces configured correctly).

This real-world workflow shows that VM migration and cloning aren't just exam topics—they're daily tools for keeping businesses running, minimising risk, and responding quickly to changing demands.

## Exam focus

The VCP-DCV exam tests VM migration and cloning heavily, with 10-15% of questions coming from objective 2.4. You must memorise exact prerequisites, supported scenarios, and the differences between operation types. The exam uses multiple-choice questions, often with 'select all that apply' or scenario-based formats where you choose the correct operation for a given situation.

Key exam topics:

- vMotion prerequisites: shared storage (or not? Actually, Storage vMotion doesn't require it, but regular vMotion requires shared storage—trap: they ask 'can you vMotion without shared storage?' and the answer is 'yes, if you combine it with Storage vMotion').
- Compatibility: CPU compatibility via EVC (Enhanced vMotion Compatibility) is required when moving between different CPU generations. The exam tests which EVC mode to use.
- Network requirements: vMotion requires a VMkernel port on a dedicated network (or a separate physical network) with minimum 1 Gbps bandwidth (10 Gbps recommended).
- Concurrent operations: maximum of 4 simultaneous vMotion migrations per host (often tested).
- Cloning and templates: difference between cloning a powered-on VM (requires quiescence) versus cloning a powered-off VM (no quiescence needed). Templates are master copies that can't be run directly—they're used to deploy new VMs.
- Cold migration: migrating a powered-off VM—this is simpler but causes downtime. The exam asks when to choose cold migration over vMotion.

Common traps:

- The exam presents a scenario where a VM has large, frequently updated memory pages. They ask whether vMotion would work. The trick: vMotion works, but if memory changes too quickly (called 'memory contention'), it may timeout. The answer is to use 'vMotion with a high priority' or just 'it's possible'.
- They mix up 'cross-host vMotion' (between hosts in the same cluster) with 'cross-cluster vMotion' (requires long-distance vMotion or different feature sets). The exam expects you to know that cross-cluster vMotion is only possible with compatible settings (like same virtual switch types).
- Cloning a VM that is part of a fault-tolerant pair—the exam tests that you must disable FT before cloning.
- The difference between 'full clone' and 'linked clone' in terms of storage independence: linked clones require the parent VM to remain available.

Key definitions to memorise:

- vMotion: live migration of a running VM with zero downtime.
- Storage vMotion: live migration of virtual disk files between datastores.
- Cold migration: moving a powered-off VM.
- Template: a master copy used for rapid deployment (cannot be started).
- Clone: an exact copy of a VM that can be started independently.
- Quiescence: the process of making a VM's data consistent before taking a snapshot or cloning (requires VMware Tools).

The exam also tests you on what happens during migration: the VM retains its MAC address and UUID, which is critical for network identity and licensing. VMs cannot be migrated across different virtual switch types (e.g., from a standard switch to a distributed switch) without additional configuration.

One specific question pattern: they describe a scenario where an administrator needs to move a VM to a host with different CPU features but similar architecture. The correct answer is to enable EVC on the cluster to a baseline CPU that both hosts support.

Finally, the exam loves to ask about failure scenarios: if a vMotion fails mid-way, the VM continues running on the source host (no data loss). If a storage vMotion fails, the VM's disk remains on the source datastore. Understanding these safety nets is crucial.

## Step by step

1. **1. Verify prerequisites** — Ensure both source and destination hosts are in the same cluster, have shared storage accessible to both, compatible CPUs or EVC enabled, a VMkernel port configured for vMotion on each host, and enough network bandwidth. This prevents failures mid-migration.
2. **2. Select the VM to migrate** — In vSphere Client, right-click the target VM and choose Migrate. You'll be prompted to select the destination host, compute resource (like a cluster), and datastore. This step initiates the wizard.
3. **3. Choose the migration type** — Select 'Change host' for vMotion (moves CPU/memory), 'Change datastore' for storage vMotion (moves disk files), or both simultaneously. This determines which resources move and which prerequisites apply.
4. **4. Set priority and options** — Choose 'High priority' for faster migration (uses more network bandwidth) or 'Normal priority'. For storage vMotion, pick a datastore format (same as source, thin, or thick provisioning). This affects performance and disk space usage.
5. **5. Monitor the migration** — vCenter displays a task progress bar. During vMotion, the VM remains accessible. If the migration fails, the VM stays on the source host with no data loss. After completion, the VM runs on the destination host with the same network identity.
6. **6. For cloning: create a full or linked clone** — Right-click the VM, choose Clone, name the new VM, select the host and datastore. Choose 'Create a full clone' for independence or 'Create a linked clone' for storage efficiency. If the VM is powered on, ensure VMware Tools is installed and quiescence is selected.

## Comparisons

### vMotion vs Storage vMotion

**vMotion:**
- Moves the VM's memory and CPU execution state to another host
- Requires shared storage between source and destination hosts
- VM stays on the same datastore; only the host changes

**Storage vMotion:**
- Moves the VM's virtual disk files to another datastore
- Does not require shared storage; moves files between datastores directly
- VM stays on the same host (unless combined with vMotion)

### Full Clone vs Linked Clone

**Full Clone:**
- Creates an independent copy with its own virtual disk
- Can be moved or deleted without affecting the parent VM
- Consumes as much storage as the original VM

**Linked Clone:**
- Shares the parent VM's base virtual disk; only differences are stored
- Requires the parent VM to remain available and unmodified
- Uses significantly less storage, ideal for test environments

### Cold Migration vs vMotion (Live Migration)

**Cold Migration:**
- Requires the VM to be powered off before starting
- Causes downtime—service is unavailable during migration
- Simpler, no memory-copy overhead, works with any CPU

**vMotion (Live Migration):**
- Migrates the VM while it remains powered on and serving users
- Zero downtime—users don't notice the move
- Requires compatible CPUs and specific network configuration

### Template vs Clone

**Template:**
- A master copy that cannot be powered on or edited directly
- Used solely to deploy new VMs (can't run applications)
- Created from a VM using 'Convert to Template' option

**Clone:**
- An exact copy of a VM that can be powered on immediately
- Used for testing, backup, or rapid deployment of identical VMs
- Created via 'Clone' operation; the clone is a fully functional VM

## Diagram

_This flowchart shows how vMotion moves a running VM from source to destination host using shared storage and network, while cloning uses a snapshot to create an independent copy._

```mermaid
flowchart TD
    A[Running VM]
    B[Source Host]
    C[Destination Host]
    D[Shared Storage]
    E[Network]
    A-->|vMotion copies memory iteratively|B
    B-->|Final memory copy and switch|C
    C-->|VM resumes on destination|A
    B-->|Accesses VM disk|D
    C-->|Accesses same disk|D
    B-->|Uses vMotion VMkernel port|E
    C-->|Uses vMotion VMkernel port|E
    F[Snapshot]
    G[Clone VMs]
    A-->|Create snapshot|F
    F-->|Copy disk and config|G
```

## Common misconceptions

- **Misconception:** vMotion requires the VM to be powered off. **Reality:** vMotion migrates a running VM with zero downtime. (The name 'migration' sounds like physically moving something, which people associate with stopping it first.)
- **Misconception:** You can clone a VM only when it is powered off. **Reality:** You can clone a powered-on VM, but you need VMware Tools and quiescence for data consistency. (Cloning appears to 'copy' the VM, and copying a file while it's open can cause corruption—but VMware's snapshot technology solves that.)
- **Misconception:** A linked clone is exactly the same as a full clone in terms of independence. **Reality:** A linked clone depends on the parent VM's virtual disk; if the parent is deleted, the linked clone breaks. (The word 'clone' implies an independent duplicate, but linked clones share storage to save space at the cost of independence.)
- **Misconception:** Storage vMotion and vMotion are the same thing. **Reality:** vMotion moves the VM's memory and execution; storage vMotion moves the VM's disk files. They are separate operations that can be combined. (Both involve moving a running VM, so beginners lump them together despite different prerequisites and purposes.)
- **Misconception:** Cold migration is always slower than vMotion. **Reality:** Cold migration can be faster because it doesn't require iterative memory copying, but it causes downtime. (People assume 'live' means always faster, but cold migration transfers a non-running VM in one shot.)

## Key takeaways

- vMotion migrates a running VM between hosts with zero downtime by copying memory iteratively, then switching execution.
- Storage vMotion moves a VM's virtual disk files between datastores while the VM continues running.
- A full clone is independent and consumes its own disk space; a linked clone shares the parent's disk and requires the parent to exist.
- Cloning a powered-on VM requires VMware Tools and quiescence to ensure file system consistency.
- Enhanced vMotion Compatibility (EVC) enables migration between hosts with different CPU generations by masking features to a baseline.
- VMs retain their MAC address and UUID during vMotion, preserving network identity and software licensing.
- Cold migration (moving a powered-off VM) is simpler but incurs downtime, while vMotion avoids downtime.
- A template is a master copy that cannot be powered on; it is used exclusively to deploy new VMs.

## FAQ

**Does vMotion work between hosts with different CPU brands (Intel vs AMD)?**

No—vMotion requires compatible CPUs from the same vendor (Intel to Intel or AMD to AMD) unless using EVC mode, which masks features to a baseline. Cross-vendor migration is not supported.

**Can I move a VM from one cluster to another using vMotion?**

Yes, but both clusters must have compatible resources (like the same virtual switch type) and shared storage accessible to the destination cluster. This is called cross-cluster vMotion.

**What happens to the VM's network connection during vMotion?**

The VM retains its MAC address and IP configuration, so network connections remain active. However, there is a brief pause (less than a second) when the final memory transfer happens, which may cause a TCP timeout for very long-lived connections.

**Is vMotion the same as live migration in other hypervisors?**

vMotion is VMware's version of live migration. Other hypervisors like Hyper-V have similar features (called live migration), but the implementation details differ. The VCP-DCV exam tests only VMware vMotion specifics.

**Can I clone a VM that is part of a vSphere cluster with DRS enabled?**

Yes—cloning works independently of DRS. The clone will be placed according to DRS rules after creation. However, you cannot clone a VM that is part of a fault-tolerant pair without removing FT first.

**What is the maximum number of simultaneous vMotion migrations per host?**

The default maximum is 4 concurrent vMotion migrations per host, but this can be configured higher. The exam tests the default value.

## Check your understanding

1. **Which VMware feature migrates a running VM from one host to another without downtime?**

   Answer: vMotion.

2. **What is the primary prerequisite for vMotion regarding storage?**

   Answer: Both source and destination hosts must have access to the same shared storage (e.g., a SAN or NAS).

3. **What is the difference between a full clone and a linked clone in terms of disk independence?**

   Answer: A full clone has its own independent virtual disk; a linked clone shares the parent VM's base disk and only stores changes.

4. **When cloning a powered-on VM, what must be installed and enabled to ensure data consistency?**

   Answer: VMware Tools must be installed, and quiescence must be enabled during the cloning operation.

5. **What is a template in VMware, and how does it differ from a clone?**

   Answer: A template is a master copy of a VM that cannot be powered on; it is used only to deploy new VMs, whereas a clone is a fully operational copy.

---

Interactive version with quiz and diagrams: https://courseiva.com/learn/vmware-vcp-dcv/vm-migration-and-cloning