Page cache management during migration using a list of outstanding store requests transmitted to a destination host machine

Systems and methods for page cache management during migration are disclosed. A method may include initiating, by a processing device of a source host machine, a migration process for migration of a virtualized component from the source host machine to a destination host machine. The method may also include obtaining a list of outstanding store requests corresponding to the virtualized component, the outstanding store requests maintained in a page cache of the source host machine and transmitting the list to the destination host machine. The method may further include providing instructions to cancel the outstanding store requests in the page cache, and providing instructions to clear remaining entries associated with the virtualized component in the page cache. The virtualized component may include a virtual machine or a container, and the outstanding store requests may correspond to requests for non-shared resources, such as a memory page. A request for the list may be generated by a user space component of an operating system (OS) of the source host machine, and transmitted to a kernel space component of a virtualization engine of the processing device.

TECHNICAL FIELD

The disclosure is generally related to computing devices, and is more specifically related to page cache management during migration.

BACKGROUND

Virtualization is a computing technique that improves system utilization, decoupling applications from the underlying hardware, and enhancing workload mobility and protection. One approach to virtualization is implementation of virtual machines (VMs). Another approach to virtualization is implementation of containers. The difference between a VM versus a container is primarily in the location of the virtualization layer and the way that operating system resources are used.

A VM is a portion of software that, when executed on appropriate hardware, creates an environment allowing the virtualization of a physical computer system (e.g., a server, a mainframe computer, etc.). The physical computer system is typically referred to as a “host machine,” and the operating system of the host machine is typically referred to as the “host operating system.” A virtual machine may function as a self-contained platform, executing its own “guest” operating system and software applications. Typically, software on the host machine known as a “hypervisor” (or a “virtual machine monitor”) manages the execution of one or more virtual machines, providing a variety of functions such as virtualizing and allocating resources, context switching among virtual machines, backing up the state of virtual machines periodically in order to provide disaster recovery and restoration of virtual machines, etc.

Containers are a form of operating system virtualization that encapsulates an application's code, configuration, and dependencies into building blocks that can be easily deployed. Containers allow for the execution of the application and its dependencies in resource-isolated processes (e.g., isolated user-space instances of the operating system). Containers provide for environmental consistency, operational efficiency, developer productivity, and version control. Containers further allow for applications to be deployed quickly, reliably, and consistently regardless of the deployment environment.

DETAILED DESCRIPTION

Described herein are methods and systems for page cache management during migration. Migration refers to the process of stopping execution of a virtualized component at a first computing device (e.g., source host machine), transferring the state of the virtualized component to a second computing device (e.g., destination host machine), and resuming execution of the virtualized component at the second computing device. A virtualized component may include, but is not limited to, a virtual machine (VM) or a container.

A VM is a portion of software that, when executed on appropriate hardware, creates an environment allowing the virtualization of a physical computer system (e.g., a server, a mainframe computer, etc.). The physical computer system is typically referred to as a “host machine,” and the operating system of the host machine is typically referred to as the “host operating system.” A virtual machine may function as a self-contained platform, executing its own “guest” operating system and software applications. Typically, software on the host machine known as a “hypervisor” (or a “virtual machine monitor”) manages the execution of one or more virtual machines, providing a variety of functions such as virtualizing and allocating resources, context switching among virtual machines, backing up the state of virtual machines periodically in order to provide disaster recovery and restoration of virtual machines, etc.

Containers are a form of operating system virtualization that encapsulates an application's code, configuration, and dependencies into building blocks that can be easily deployed. Containers allow for the execution of the application and its dependencies in resource-isolated processes (e.g., isolated user-space instances of the operating system). Containers provide for environmental consistency, operational efficiency, developer productivity, and version control. Containers further allow for applications to be deployed quickly, reliably, and consistently regardless of the deployment environment.

The isolated nature of a virtualized component makes it easy to move between environments (e.g., development, test, production, etc.), while retaining full functionality. For example, an application can be migrated from one host machine to another host machine by migrating the VM that deploys the application or by migrating the containers that deploy the functionality of the application. Migration of a virtualized component involves saving the state of the virtualized component on a source host machine and restoring it on a destination host machine.

A portion of a virtualized component's state is storage (i.e., data that the virtualized component stores to disk). This data may be located in a page cache in memory of the source host machine. As part of the migration process provided by conventional systems, the page cache data is flushed (i.e., stored) to a storage device (e.g., disk) shared with the destination host machine. The page cache data could then be read back at the destination host machine post-migration process. In the absence of this flush, the source host machine could crash and take down the virtualized component. However, the flush operation can take a long time (e.g., seconds) in some cases (e.g., due to slow networked storage). This increases application downtime and negatively impacts the user experience.

Implementations of the disclosure provide for page cache management during migration. During a migration process, implementations of the disclosure obtain a list of outstanding store requests (also referred to as write requests) for a virtualized component that is being migrated. This list is obtained from the page cache in the source host machine hosting the virtualized component. The outstanding store requests may also be referred to as dirty page cache entries. The list, and data (e.g., content of pages) associated with the outstanding store requests, are provided to the destination host machine in order for the destination host machine to resubmit the outstanding store requests at the destination host machine (e.g., write the outstanding store requests to the page cache of the destination host machine). The outstanding store requests are then canceled at the source host machine and all other page cache entries for the virtualized component at the source host machine are flushed to storage.

Implementations of the disclosure provide a technical improvement over the conventional systems by reducing and/or avoiding altogether the flush operation for page cache entries of a virtualized component at a source host machine. Reducing and/or avoiding the flush operation results in a faster migration process as access to slow networked storage is minimized. Correspondingly, this results in more efficient usage of processing resources and a better overall user experience.

FIG. 1depicts an illustrative architecture of elements of a virtualization system100, in accordance with an implementation of the disclosure. It should be noted that other architectures for virtualization system100(also referred to herein as system100) are possible, and that the implementation of a computer system utilizing embodiments of the disclosure are not necessarily limited to the specific architecture depicted byFIG. 1.

As shown inFIG. 1, system100comprises computer systems, including source host machine101-1and destination host machine101-2, connected via a network150. Each of host machines101-1and101-2may be one or more computing devices (such as a rackmount server, a router computer, a server computer, a personal computer, a mainframe computer, a laptop computer, a tablet computer, a desktop computer, etc.), data stores (e.g., hard disks, memories, databases), networks, software components, and/or hardware components that may be used to enable page cache management during migration. The network150may include a public network (e.g., the Internet), a private network (e.g., a local area network (LAN) or wide area network (WAN)), a wired network (e.g., Ethernet network), a wireless network (e.g., an 802.11 network or a Wi-Fi network), a cellular network (e.g., a Long Term Evolution (LTE) network), routers, hubs, switches, server computers, and/or a combination thereof. In some implementations, host machines101-1and101-2may belong to a cluster comprising additional computer systems not depicted inFIG. 1, while in some other implementations, host machines101-1and101-2may be independent systems that are capable of communicating via network150.

Each of host machines101-1and101-2comprises a central processing unit (CPU)160-1,160-2, a memory170-1,170-2, which may include volatile memory devices (e.g., random access memory (RAM)), non-volatile memory devices (e.g., flash memory), and/or other types of memory devices), and a storage device180-1,180-2(e.g., a magnetic hard disk, a Universal Serial Bus (USB) solid state drive, a Redundant Array of Independent Disks (RAID) system, a network attached storage (NAS) array, etc.). It should be noted that the fact that a single CPU is depicted inFIG. 1for each of host machines101-1and101-2is merely illustrative, and that in some other examples one or both of host machines101-1and101-2may comprise a plurality of CPUs. Similarly, in some other examples one or both of host machines101-1and101-2may comprise a plurality of storage devices, rather than a single storage device.

Source host machine101-1runs a host operating system (OS)120-1that manages the hardware resources of the computer system and that provides functions such as interprocess communication, scheduling, virtual memory management, and so forth. In one example, host operating system120-1also comprises a virtualization engine125-1. Virtualization engine125-1may provide a virtual operating platform for virtualized component130-1,130-2(collectively referred to herein as virtualized component130) and that manages its execution. Virtualized component130may be accessed by one or more clients140over network150. In some implementations, clients140may be hosted directly by source host machine101-1as local clients.

In some implementations, virtualization engine125-1may be external to host OS120-1, rather than embedded within host OS120-1. For simplicity and ease of explanation, a single virtualized component130is depicted inFIG. 1. However, in some implementations, source host machine101-1may host a plurality of virtualized components130.

Virtualization engine125-1may include, but is not limited to, a hypervisor or a container engine (such as Docker™engine, etc.). When virtualization engine125-1is implemented as a hypervisor, it can provide a virtual operating platform for the virtualized component130that is implemented as a virtual machine (VM) (referred to herein as a VM virtualized component130). A hypervisor can emulate the underlying hardware platform (e.g., CPU160-1, memory170-1, storage device180-1, etc.) of the source host machine101-1for the VM virtualized component130. A hypervisor may also be referred to as a virtual machine monitor (VMM), a kernel-based hypervisor, or a host operating system. A VM virtualized component130is a software implementation of a machine that is hosted by source host machine101-1and that executes programs as though it were an actual physical machine. In some embodiments, these programs may include one or more guest applications and a guest operating system (OS) that manages resources and provides functions such as interprocess communication, scheduling, memory management, and so forth. VM virtualized component130may provide a virtual desktop for the client140.

When virtualization engine125-1is implemented as a container engine, it can provide a virtual operating platform for the virtualized component130that is implemented as a container (referred to herein as a container virtualized component130). A container virtualized component130implements a form of operating system virtualization that encapsulates an application's code, configuration, and dependencies into building blocks that can be easily deployed. Container virtualized components130allow for the execution of the application and its dependencies in resource-isolated processes (e.g., isolated user-space instances of the host OS120-1).

When virtualized component130is implemented as a container, the virtualization engine125-1is installed as a container layer on top of the host OS120-1. Container instances (i.e., virtualized component130) can then be provisioned, via the container layer, from the source host machine's101-1available resources (e.g., CPU160-1, memory170-1, storage180-1, etc.). Applications can then be deployed within the container virtualized components130. The container virtualized component130is implemented on top of the host OS120-1, while sharing the host OS120-1kernel and, in some cases, the binaries and libraries, with other container virtualized components130. Shared components may be read-only, with each container able to be written to through a unique mount.

The isolated nature of virtualized component130makes it easy to move between environments (e.g., development, test, production, etc.), while retaining full functionality. For example, an application can be migrated from the source host machine101-1to the destination host machine101-2by migrating the virtualized component130that deploys the application. Migration of virtualized component130involves saving the state of the virtualized component130on source host machine101-1and restoring it on destination host machine101-2.

In accordance with one example, virtualization engine125-1may include a migration manager128-1that is capable of page cache management during a migration process of the virtualized component130. For purposes of the below description, virtualized component130is migrated from source host machine101-1to destination host machine101-2during a migration process. As part of the migration process for the virtualized component130, the state of the virtualized component130at the source host machine101-1is saved (checkpointed) and restored at the destination host machine101-2One portion of the virtualized component130state may be data stored on disk. Disk may refer to a local storage device180-1and/or a shared storage device190. Shared storage device190may be accessible by more than one host machine101-1,101-2over network150. Shared storage device190may include, but is not limited to, a magnetic hard disk, a USB solid state drive, a RAID system, a NAS array, etc.

As storage to disk can often be a time-consuming process, the virtualized component130state data that is to be written to disk may be stored in a page cache175-1prior to being written to disk. A page cache (also referred to as a disk cache) refers to a hardware or software (instructions implemented by hardware) component that stores data as an interim location on the way to secondary storage (such as storage device180-1, shared storage device190), so that future requests for that data can be served faster. The host OS101-1may maintain the page cache175-1in otherwise unused portions of memory170-1, resulting in quicker access to the contents of the cached pages (contiguous blocks of virtual memory) and overall performance improvements. A page cache can be implemented in kernels with paging memory management, and is transparent to applications.

When a migration process for the virtualized component130is initiated (e.g., by a migration manager115of a host controller110, by host machines101-1,101-2, etc.), the migration manager128-1stops execution of the virtualized component130. After the virtualized component130is stopped, a page cache manager129-1of the migration manager128-1retrieves a list of store requests (e.g., write requests) submitted by the virtualized component130and still outstanding (i.e., dirty) in the page cache175-1. Instead of flushing (i.e., writing the store requests in the page cache175-1out to storage180,190and clearing the corresponding entry in the page cache175-1) these outstanding store requests to storage (as was done by conventional systems), the store requests and their corresponding data are sent to the destination host machine101-2as part of the migration process.

In one implementation, the page cache manager129-1obtains a list of outstanding store requests corresponding to the virtualized component130in the page cache175-1. In addition, the page cache manager129-1obtains the data corresponding to the outstanding store requests in the list. In one implementation, the page cache175-1may include a bit or a flag that indicates that an associated entry is outstanding (e.g., dirty) and has not yet been written out to disk. The list of outstanding store requests may include those requests that are not shared with other virtualized components130on the source host machine101-1. In other words, if a store request associated with the virtualized component130in the page cache175-1is indicated as shared with processes other than the virtualized component130(e.g., a flag or other marker in the page cache175-1may provide this indication), then this store request is not included in the list of outstanding store requests obtained by the page cache manager129-1. In one implementation, a shared resource may refer to a memory page that is accessible and/or utilized by a plurality of virtualized components130hosted on the source host machine101-1.

In one implementation, the page cache manager129-1may be implemented as a modular component of the virtualization engine125-1. As a modular process, the page cache manager may include a user space portion and a kernel space portion.FIG. 2is a block diagram illustrating a page cache manager200as a modular component having user space and kernel space portions. Page cache manager200may be the same as page cache manager129-1described with respect toFIG. 1. In one example, page cache manager200may be implemented when virtualized component130ofFIG. 1is a container virtualized component130.

Page cache manager200may include a user space210portion and a kernel space220portion. In one implementation, user space210portion of page cache manager200may include the processes and/or component of page cache manager200that execute in a user space of the host OS (e.g., host OS120-1ofFIG. 1). In one implementation, kernel space220portion of page cache manager200may include the processes and/or components of page cache manager200that execute in a kernel space of the host OS (e.g., host OS120-1ofFIG. 1). These processes and/or components may include, but are not limited to, outstanding store request generator202, outstanding store request list generator204, and outstanding store request data structure206.

User space210portion of page cache manager200may include an outstanding store request generator202. The outstanding store request generator202can generate a request for all store requests corresponding to the virtualized component130in the page cache175-1and still outstanding (i.e., not written out to disk, dirty, etc.) in the page cache175-1. In one example, for a container virtualized component130, the outstanding store request generator202may generate a request for outstanding write requests for a block input/output (I/O) (blkio) container group of the container virtualized component130. The outstanding store request generator202may transmit this generated request to the kernel space220portion of the page cache manager200.

The kernel space220portion of the page cache manager200may include an outstanding store request list generator204. The outstanding store request list generator204may have access to the page cache175-1of the source host machine101-1. The outstanding store request list generator204may access the page cache175-1to identify those page cache entries corresponding to the virtualized component130that are still outstanding (e.g., dirty entry in page cache175-1). As discussed above, the outstanding store request list generator204may also identify, from among the still outstanding page cache entries of the virtualized component130, those page cache entries that are not shared with any other virtualized components130or other components of the source host machine101-1. The outstanding store request list generator204then populates a list with the identified page cache entries and provides this list to the user space210portion of page cache manager200.

The user space210portion of page manager may use this list to obtain data associated with the outstanding store requests of the list. This data may refer to the contents of the pages to be written to the storage location identified by each of the page cache entries of the list. In one implementation, the outstanding store request generator202may separately request the data from the kernel space220portion of the page cache manager. In other implementations, the outstanding store request generator202may include the request for data as part of the original request for the list. When the requested data is received from the kernel space220portion of the page cache manager200, the data may be stored in outstanding store request data structure206(e.g., a buffer) of the user space210portion of page cache manager200. The list and the data may then be transmitted by page cache manager200to the destination host machine101-2as part of the migration process.

In some implementations, the user space210portion of page cache manager200may maintain a mapping (e.g., in outstanding store request data structure206) of the page cache entries corresponding to the virtualized component130. This mapping may include pointers to the page cache entries maintained in page cache175-1that correspond to the virtualized component130. The outstanding store request generator202may utilize this mapping to identify the page cache entries that correspond to outstanding (and, in some cases, non-shared) store requests of the virtualized component130. The outstanding store request generator202may then provide pointers corresponding to the identified page cache entries in the mapping to the kernel space220component along with instructions to transmit the respective page cache entries and corresponding data from the page cache175-1to the destination host machine101-2.

Referring back toFIG. 1, destination host machine101-2, like source host machine101-1, runs a host OS120-2that manages the hardware resources of the destination host machine101-2and that provides functions such as interprocess communication, scheduling, virtual memory management, and so forth. In one example, host OS120-2comprises a virtualization engine125-2that manages virtualized components (such as VMs or containers). It should be noted that in some alternative examples, virtualization engine125-2may be external to host OS120-2, rather than embedded within host OS120-2.

In accordance with one example, virtualization engine125-2, like virtualization engine125-1of computer system101-1, includes a migration manager128-2that, like migration manager128-1, is capable of page cache management during migration. The migration manager128-2manages the migration process of the virtualized component130-1at destination host machine101-2, where virtualized component130-1is resumed as virtualized component130-2. Specifically, the migration manager128-2can receive and process the list (and corresponding data) of outstanding store requests sent from source host machine101-1. The page cache manager129-2of migration manger128-2causes the outstanding store requests to be submitted at the destination host machine101-2. Submission of the store requests includes resubmitting the store requests for writing to storage (e.g., storage device180-2, shared storage device190) at the destination host machine101-2. As a result of memory management processes at the destination host machine101-2, the store requests are rewritten to page cache175-2at the destination host machine101-2.

In one implementation, if the page cache manager129-2at the destination host machine101-2encounters a problem or error when resubmitting the outstanding store requests at the destination host machine101-2, the migration manager128-2can notify the migration manager128-1of the source host machine101-1of the occurrence of this problem or error. The migration manager128-1of the source host machine101-1can then cause the migration process to abort. As the page cache175-1at the source host machine101-1remains in its pre-migration state, the virtualized component130-1can resume execution at the source host machine101-1without any loss of data, or the migration process can be re-tried with the destination host machine101-2or another host machine (not shown).

Subsequent to the migration manager128-2successfully resubmitting the received store requests corresponding to the virtualized component130, the migration manager128-2may transmit a confirmation to the source host machine101-1indicating that the resubmission of the outstanding store requests of the list was successful. Once the migration manager128-1of the source host machine101-1receives this confirmation, it can instruct the page cache manager129-1to cancel the outstanding store requests from the list in the page cache175-1, and clear (e.g., flush; write each entry to storage and mark entry as clean in page cache175-1) any remaining entries (e.g., shared entries, etc.) in the page cache175-1corresponding to the virtualized component130.

In one implementation, there may be outstanding store requests at the source host machine101-1that have not yet been written into the page cache175-1. As part of the migration process, the migration manager128-1and/or page cache manager129-1of the source host machine101-1may retrieve such outstanding requests from the virtualized component130and handle the requests in the same manner as described above (i.e., cancel the requests and restart on the destination host machine101-2).

Once the page cache manager129-1indicates successful completion of the cancel and clear operations, the migration manager128-1can send an acknowledgment to the migration manager128-2of the destination host machine101-2that the source host machine101-1page cache175-1is clean. The migration manager128-2may then proceed with any remaining tasks of the migration process in order to resume the virtualized component130-2on the destination host machine101-2.

FIG. 3illustrates an example source host machine300in which implementations of the disclosure may operate. The source host machine300may be the same or similar to one of the source host machine101-1within the virtualization system100described with respect toFIG. 1. Source host machine300may include components and modules for page cache management during migration. The source host machine300may include a data store310that can store a page cache320(with outstanding store requests321and remaining entries322), an outstanding store requests list323, instructions to cancel324, and instructions to clear326. The data store310may include any non-persistent data storage (e.g., memory), persistent data storage (e.g., flash storage, hard drive, tape), other medium, or combination thereof that is capable of storing instructions for carrying out the operations of the components and modules discussed herein.

The source host machine300may include a processing device330with a virtualized component340and a migration manager350. The migration manager may include a list retriever352, a list transmitter354, and a page cache instruction generator356. The migration manager350may initiate a migration process for migration of a virtualized component340from a source host machine300to a destination host machine360. The list retriever352may obtain a list323of outstanding store requests321corresponding to the virtualized component340. The outstanding store requests321of the list323may be maintained in a page cache320of the source host machine300. The list transmitter354may transmit the list323to the destination host machine360. The page cache instruction generator356may provide instructions to cancel324the outstanding store requests321of the list323in the page cache320at the source host machine300. The page cache instruction generator356may also provide instructions to clear326remaining entries322associated with the virtualized component340in the page cache320of the source host machine300.

FIGS. 4 and 5depict flow diagrams for illustrative examples of methods400and500for page cache management during migration. Method400includes a method of page cache management during migration at a source host machine. Method500includes a method of page cache management during migration at a destination host machine. Methods400and500may be performed by processing devices that may comprise hardware (e.g., circuitry, dedicated logic), computer readable instructions (e.g., run on a general purpose computer system or a dedicated machine), or a combination of both. Methods400and500and each of their individual functions, routines, subroutines, or operations may be performed by one or more processors of the computer device executing the method. In certain implementations, methods400and500may each be performed by a single processing thread. Alternatively, methods400and500may be performed by two or more processing threads, each thread executing one or more individual functions, routines, subroutines, or operations of the method.

For simplicity of explanation, the methods of this disclosure are depicted and described as a series of acts. However, acts in accordance with this disclosure can occur in various orders and/or concurrently, and with other acts not presented and described herein. Furthermore, not all illustrated acts may be needed to implement the methods in accordance with the disclosed subject matter. In addition, those skilled in the art understand and appreciate that the methods could alternatively be represented as a series of interrelated states via a state diagram or events. Additionally, it should be appreciated that the methods disclosed in this specification are capable of being stored on an article of manufacture to facilitate transporting and transferring such methods to computing devices. The term “article of manufacture,” as used herein, is intended to encompass a computer program accessible from any computer-readable device or storage media. In one implementation, methods400and500may be performed by a host machine, specifically migration manager128or source host machine101-1or destination host machine101-2, as shown inFIG. 1.

Referring toFIG. 4, method400may be performed by processing devices of a computing device and may begin at block410. At block410, a processing device may initiate a migration process for migration of a virtualized component from a source host machine to a destination host machine. At block420, the processing device may obtain a list of outstanding store requests corresponding to the virtualized component. In one implementation, the outstanding store requests are maintained in a page cache of the source host machine.

Subsequently, at block430, the processing device may transmit the list to the destination host machine. At block440, the processing device may provide instructions to cancel the outstanding store requests in the page cache at the source host machine. Lastly, at block450, the processing device may provide instructions to clear remaining entries associated with the virtualized component in the page cache of the source host machine.

Referring toFIG. 5, method500may be performed by processing devices of a computing device and may begin at block510. At block510, a processing device may initiate a migration process for migration of a virtualized component from a source host machine to the destination host machine. At block520, the processing device may receive, from the source host machine, a list of outstanding store requests corresponding to the virtualized component and data corresponding to each of the outstanding store requests in the list.

Subsequently, at block530, the processing device may write the outstanding store requests and data to a first page cache of the destination host machine. At block540, the processing device may transmit, to the source host machine, an acknowledgement of successful submission of the outstanding store requests. Lastly, at block550, the processing device may, responsive to receiving confirmation of successful cancellation and clearing of entries of a second page cache of the source host machine, cause the virtualized component to resume execution on the destination host machine as part of the migration process.

FIG. 6depicts a block diagram of a computer system operating in accordance with one or more aspects of the disclosure. In various illustrative examples, computer system600may correspond to a computing device, such as migration manager128-1,128-2within host machine101-1,101-2ofFIG. 1. The computer system may be included within a data center that supports virtualization. Virtualization within a data center results in a physical system being virtualized using virtual machines to consolidate the data center infrastructure and increase operational efficiencies. A virtual machine (VM) may be a program-based emulation of computer hardware. For example, the VM may operate based on computer architecture and functions of computer hardware resources associated with hard disks or other such memory. The VM may emulate a physical computing environment, but requests for a hard disk or memory may be managed by a virtualization layer of a host machine to translate these requests to the underlying physical computing hardware resources. This type of virtualization results in multiple VMs sharing physical resources.

In a further aspect, the computer system600may include a processing device602, a volatile memory604(e.g., random access memory (RAM)), a non-volatile memory606(e.g., read-only memory (ROM) or electrically-erasable programmable ROM (EEPROM)), and a data storage device616, which may communicate with each other via a bus608.

Computer system600may further include a network interface device622coupled to network674. Computer system600also may include a video display unit610(e.g., a liquid crystal display (LCD)), an alphanumeric input device612(e.g., a keyboard), a cursor control device614(e.g., a mouse), and a signal generation device620.

Data storage device616may include a non-transitory computer-readable storage medium624which may store instructions626encoding any one or more of the methods or functions described herein, including instructions for a migration manager128(e.g.,128-1or128-2) ofFIG. 1for implementing methods400and500.

Instructions626may also reside, completely or partially, within volatile memory604and/or within processing device602during execution thereof by computer system600, hence, volatile memory604and processing device602may also constitute machine-readable storage media.

The methods, components, and features described herein may be implemented by discrete hardware components or may be integrated in the functionality of other hardware components such as application specific integrated circuit (ASICs) field programmable gate arrays (FPGAs), digital signal processors (DSPs) or similar devices. In addition, the methods, components, and features may be implemented by firmware modules or functional circuitry within hardware devices. Further, the methods, components, and features may be implemented in any combination of hardware devices and computer program components, or in computer programs.

Unless specifically stated otherwise, terms such as “receiving,” “invoking,” “associating,” “providing,” “storing,” “performing,” “utilizing,” “deleting,” “initiating,” “marking,” “generating,” “recovering,” “completing,” or the like, refer to actions and processes performed or implemented by computer systems that manipulate and transform data represented as physical (electronic) quantities within the computer system registers and memories into other data similarly represented as physical quantities within the computer system memories or registers or other such information storage, transmission or display devices. Also, the terms “first,” “second,” “third,” “fourth,” etc. as used herein are meant as labels to distinguish among different elements and may not have an ordinal meaning according to their numerical designation.