Mastering Windows Server 2016 Hyper-V

(Romina) #1

Live Migration


Live Migration is the Hyper-V technology that enables a virtual machine to be moved
between Hyper-V hosts. In Windows Server 2008 R2, Live Migration provided the
functionality to migrate the memory and state of a virtual machine between hosts in a
cluster while the virtual machine was still running. The storage of the virtual machine
was available to both hosts in the cluster simultaneously through the use of Cluster
Shared Volumes.


There are six key stages to the original Live Migration process in Windows Server
2008 R2, and they remain today when using shared storage:


1 . A   Live    Migration   connection  is  made    between the source  and target  Hyper-V hosts.
2 . The virtual machine configuration and device information is transferred, and a
container virtual machine is created on the target Hyper-V host.
3 . The memory of the virtual machine is transferred.
4 . The source virtual machine is suspended, and the state and remaining memory
pages are transferred.
5 . The virtual machine is resumed on the target Hyper-V host.
6 . A reverse ARP is sent over the network to enable network traffic to find the virtual
machine on the new host.

The transfer of the memory is the most interesting aspect of Live Migration. It’s not
possible just to copy the memory of a virtual machine to another node. As the memory
is being copied, the VM is still running, which means parts of the memory being
copied are changing, and although the copy is from memory to memory over very fast
networks, it still takes a finite amount of time, and pausing the VM while the memory
is copied would be an outage. The solution is to take an iterative approach that does
not result in a perceived period of unavailability by any clients of the virtual machine
and ensures that any TCP/IP connections do not timeout.


An initial transfer of the VM memory is performed, which involves the bulk of the
information and the bulk of the time taken during a Live Migration. Remember that
the virtual machine is still running, and so we need a way to track pages of memory
that change while we are copying. To this end, the worker process on the current node
creates a “dirty bitmap” of memory pages used by the virtual machine and registers for
modify notifications on the pages of memory used by the VM. When a memory page is
modified, the bitmap of memory is updated to show that a page has been modified.
Once the first pass of the memory copy is complete, all of the pages of memory that
have been marked dirty in the memory map are recopied to the target. This time, only
the changed pages are copied, so there will be far fewer pages to copy and the
operation should be much faster. Once again, though, while we are copying these
pages, other memory pages may change, and so this memory copy process repeats

Free download pdf