A Brief Tutorial on Live Virtual Machine Migration From a Security Perspective

Virtualization has gained traction in a wide variety of contexts. The rise of Cloud Computing and the wide adoption of the OpenFlow API in computer networks are just a few examples of how virtualization has changed the foundations of computing. In general, the term ”virtualization” refers to the process of turning a hardware-bound entity into a software-based component. The end result of such procedure encapsulates an entity’s logic and is given the name of Virtual Machine (VM). The main advantage of this technique is that multiple VMs can run on top of a single physical host, which can make resource utilization much more efficient. Of particular interest are those VMs with high availability requirements, such as the ones deployed by cloud providers, given that they generate the need to minimize the downtime associated with routine operations. VMs can deal with availability constraints much more gracefully than their physical equivalents. While physical hosts have to be powered down for maintenance, the VMs that they serve can migrate to execute on other physical nodes. It is also common to migrate VMs when load balancing is needed in the physical plane. The process of migrating VMs without any perceptible downtime is known as Live Virtual Machine Migration and is the topic of this paper. This nontrivial problem has been studied extensively and popular hypervisors (e.g. Xen, VMware, OpenVZ) have now put reasonable solutions to practice. After covering the pre-copy and post-copy approaches to live VM migration, a variety of design decisions will be discussed along with their pros and cons. Having set the necessary theoretical background, a security-focused survey will be carried out, documenting the state-of-the-art in Live VM Migration exploits and countermeasures. 1. SYSTEM VS PROCESS MIGRATION The problem of process migration was thoroughly studied during the 90’s. Unfortunately, the fact that applications are strongly connected with the OS by way of open sockets, file descriptors and other resource pointers makes process migration very difficult. In some cases (e.g. shared memory between processes), such migration is not even possible unless processes are partitioned a priori [1]. Migrating an entire OS with its applications is a much more manageable procedure, especially in the presence of a Virtual Machine Monitor (VMM). VMMs expose a narrow interface to the OS, so the entity to be migrated encapsulates most of the complexity. That is, the details of what is occurring inside the VM can be ignored during migration. 2. LIVE VM MIGRATION STRATEGIES In this section, we will consider the most common setting for Live VM Migration: a clustered server environment. The three main physical resources that are used under such conditions are memory, network and disk [2]. While memory can be copied directly from one host to another, local disk and network interface migration are not trivial. To be able to preserve open network connections and to avoid network redirection mechanisms, a VM should retain its original IP address after migration. If the migration is within the same LAN, which is the norm in a clustered server environment, this can be done by generating an unsolicited ARP reply advertising the new location for the migrated VM’s IP [2]. Local disk migration should not be needed inside a server farm. Data centers use network-attached storage (NAS) devices, which can be accessed from anywhere inside the cluster. Thus, secondary storage doesn’t have to be migrated with the VM. Consequently, in a clustered server environment, the Live VM Migration problem is reduced to finding a way of consistently transferring VM memory state from one host to another. 2.1 Memory Migration Memory migration can be divided into three phases [3]: • Push phase: The source VM continues running while certain pages are pushed across the network to the new destination. To ensure consistency, pages modified during this process must be resent. • Stop-and-copy phase: The source VM is stopped, pages are copied across to the destination VM, then the new VM is started. • Pull phase: The new VM starts its execution and, if it accesses a page that has not yet been copied, this page is faulted in across the network from the source VM. Most migration strategies select either one or two of the above phases. While the pre-copy approach combines push with stop-and-copy, the post-copy approach combines pull with stop-and-copy.