Cross-Hypervisor VM Migration: OVF Template

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✓

  Live migration

  Why this is correct

  Live migration is a hypervisor-level feature that transfers the complete execution state of a running VM—CPU, memory contents, storage, and network connections—from one physical host to another with sub-second downtime. It preserves the VM's private IP address and network identity because the virtual network interface remains attached to the same L2 segment, and techniques like memory pre-copying ensure the target host has a synchronized copy before a brief switchover. This is the only option that actually relocates the workload while it remains powered on, as required by the scenario.

• ✗

  Load balancing

  Why it's wrong here

  Load balancing distributes incoming network traffic across multiple servers based on algorithms like round-robin or least connections to optimize resource utilization and availability. It operates at the network or application layer, typically using a dedicated load balancer, and does not move or migrate a running VM's execution state between hypervisor hosts. In the context of VM management, load balancing may involve adjusting traffic flow or spinning up new instances, but it never performs the live migration of an existing VM from one physical host to another.

• ✗

  Auto-scaling

  Why it's wrong here

  Auto-scaling is a cloud orchestration mechanism that dynamically adds or removes VM instances based on predefined policies such as CPU utilization, memory usage, or request count. It responds to demand changes by provisioning new instances (scale-out) or terminating excess ones (scale-in), but it does not relocate an existing VM from one physical host to another. Auto-scaling is about adjusting capacity, not about zero-downtime mobility of a specific VM, so it is irrelevant to the requirement of moving a VM between hosts.

• ✗

  Elasticity

  Why it's wrong here

  Elasticity is the ability of a cloud system to rapidly expand or shrink resource allocations—such as CPU, RAM, or instance count—in response to workload changes, often in an automated fashion. It is a capacity-planning property that focuses on matching resources to demand, but it provides no mechanism for transferring a live VM's runtime state across hosts. While elasticity might be used to provision a new VM on another host, it cannot move a currently running VM with preserved network configuration, making it a wrong choice for this migration scenario.

Go deeper

Related to this question