METHOD AND SYSTEM FOR VIRTUAL MACHINE MIGRATION
Virtual machine (VM) technology allows multiple operating systems each deploying multiple applications to run on a single host. This invention presents an effective method and system for virtual machine migration from a source host to a target host. The method and system concern the migration of both the service VM and the element managing it. State of the migrating VM is preserved so that it can resume its execution on the target host.
The present patent application claims priority from the Canadian patent application serial number 2,547,047 to Anthony WHITE entitled “MANAGEMENT OF VIRTUAL MACHINES USING MOBILE AUTONOMIC ELEMENTS” filed on May 15, 2006, which is incorporated herein by reference.
FIELD OF INVENTIONThe present invention relates to the management of virtual machines, and particularly to the management of virtual machine migration from one host system to another by using mobile autonomic elements.
BACKGROUND OF THE INVENTIONThe drive to make more effective use of physical resources within an enterprise information technology (IT) infrastructure has led to the introduction of virtual machine technology. Virtual machine (VM) technology allows one or more guest operating systems to run concurrently on one physical device. There are several approaches to providing virtualization technology, the most recent being para-virtualization and native central processing unit (CPU) with basic input/output system (BIOS) or Extensible Firmware Interface (EFI) support. Concurrent with these approaches, the emergence of the management plane has occurred as the means by which hardware, operating system and applications are managed within the service plane.
One or more virtual machines may be operational on a single host computing system that will be referred to simply as a host system. A VM that may include an operating system with its concurrent applications is often separated from the elements that manage the VMs on the host system. The separation of management and service functionality has a number of distinct advantages that include separation of concerns, management of change and security improvements.
Finally, delegated management through the paradigm of Autonomic Computing has emerged. Autonomic Computing is a relatively recent field of study that focuses on the ability of computers to self-manage. Autonomic Computing is promoted as the means by which greater independency will be achieved in systems. This incorporates self-diagnosis, self-healing, self-configuration and other independent behaviors, both reactive and proactive. Such system will adapt and learn normal levels of resource usage and predict likely points of failure in the system. Certain benefits of computers that are capable of adapting to their usage environments and recovering from failures without human interaction have been known, including reducing the total cost of ownership of a device and increasing levels of system availability. Repetitive work performed by human administrators is reduced, knowledge of the system's performance over time is retained, assuming that the machine records or publishes information about the problems it detects and the solutions it applies, and events of significance are detected and handled with more consistency and speed than a human could likely provide. Such autonomic elements are used in the context of this invention for virtual machine management.
The introduction of virtualization along with management and service plane separation has produced a new important problem. A VM may be required to migrate from one host system to another. Such a migration may be necessary in various situations. These include the increase in load of the system currently hosting the VM, the occurrence of a fault in the host system, and the temporary unavailability of the system for hosting a VM due to routine maintenance. Specifically, if a virtual machine migrates, the associated units of manageability need to move as well, where the problem extends to more than simply moving code.
The general area of code mobility is well researched. Various environments for the general mobility of software and state have been built. However, there has been no such infrastructure for an autonomic element, which applies specifically to the system management domain where virtual machines are under management. In particular there is no effective mechanism for transferring a VM from one host to another on which it can resume operation seamlessly. Thus there is a need in the industry for an effective method and system for virtual machine migration by using mobile autonomic elements.
SUMMARY OF THE INVENTIONTherefore there is an object of the present invention to provide a method and system for the management of virtual machine migration from one host system to another by using mobile autonomic elements.
According to one aspect of the invention there is provided a method for migrating a service Virtual Machine (VM), comprising a VM managed element including components providing a service, and a VM managing element managing the service VM, from a source host to a target host, the method comprising the steps of:
-
- (a) queuing events to be processed by the service VM at the source host;
- (b) sending information regarding a current state of the VM managed element from the source host to the target host;
- (c) sending information regarding a state of the queued events from the source host to the target host;
- (d) sending components of the VM managed element that have changed during the execution of step (a)-step (c) from the source host to the target host;
- (e) terminating the service VM and the VM managing element on the source host; and
- (f) resuming execution of the service VM by using the information sent in step (b)-step (d) and resuming the VM managing element on the target host.
According to another aspect of the invention there is provided a system for migrating a service Virtual Machine (VM), comprising a VM managed element including components providing a service, and a VM managing element managing the service VM, from a source host to a target host, the system comprising:
-
- (a) means for queuing events to be processed by the service VM at the source host;
- (b) means for sending information regarding a current state of the VM managed element from the source host to the target host;
- (c) means for sending information regarding a state of the queued events from the source host to the target host;
- (d) means for sending components of the VM managed element that have changed during the queuing of events to be processed, the sending of information regarding the current state of the VM and the sending of information regarding the state of the queued events;
- (e) means for terminating the service VM and the VM managing element on the source host; and
- (f) means for resuming execution of the service VM by using the information regarding the current state of the VM managed element, the state of the queued events and the components of the VM managed element that have changed sent from the source host to the destination host and resuming the VM managing element on the target host.
Further features and advantages of the invention will be apparent from the following description of the embodiment, which is described by way of example only and with reference to the accompanying drawings in which:
To facilitate the understanding of the present invention, a reference is made herein to the previously filed applications of Embotics Corporation, all of which are incorporated herein by reference:
Canadian patent applications serial numbers 2,435,655 and 2,475,387 to Shannon et al, both entitled “Embedded System Administration”; and
Canadian patent applications serial numbers 2,504,333 and 2,543,938 to White et al, both entitled “Programming and Development Infrastructure For An Autonomic Element”.
The present invention focuses on systems that use autonomic computing principles to manage virtual machines in a scenario where management and service are separated in distinct execution environments, also referred to as management and service planes respectively. A single management plane may provide manageability for one or more service planes. The invention provides a method and system for VM migration, and the infrastructure to support the mobility of manageability components that provide autonomic management for a migrating virtual machine, or more generally an execution container, which constitutes a service plane.
The notion of the co-existence of a management and a service plane is explained with the help of
In some systems, referring to
As shown in
A typical scenario that provides an example of the utility of VM migration for achieving load distribution is provided next.
-
- 1. In this scenario there are two service planes running on domain 1 and domain 2 of a system as virtual machines.
- 2. A virtual machine managed element (VMManagedElement) has been created for each virtual machine. VMManagedElements are instantiated within the management plane, i.e. domain 0.
- 3. A migration policy that has a sensor which monitors the overall CPU utilization for the host is loaded.
- 4. The migration policy polls the CPU utilization sensor for percentage load data.
- 5. The migration policy consolidates the data into a moving average over a user-defined window, e.g. 15 minutes.
- 6. The average value is tested and if found to exceed a user-defined threshold, e.g., 80%, the migrateVM Application Programming Interface (API) on the VMManagedElementHome object is invoked.
- 7. The VMManagedElementHome object is responsible for managing the lifecycle of all VMManagedElement objects. In this scenario two objects exist. The first VMManagedElement object found has its migrate API invoked. The migrate API executes the method that is presented in
FIG. 9 and is described in the next paragraph. Should the migrate API throw an exception it is handled within the VMManagedElementHome object. In one embodiment a log is generated. Once the exception is handled, it is thrown again and handled within the migration policy.
The method for the VM migration is explained with the help of flowcharts 900-1200 that are captured in
The step of Proceed Migration (box 916) is explained with the help of Flowchart 1000 shown in
The step of Process management event state is explained further with the help of Flowchart 1050 presented in
The step of Migrate VM (box 1068) in Flowchart 1050 is explained further with the help of Flowchart 1100 presented in
The step of Complete VM migration (box 1118) in Flowchart 1100 is explained with the help of Flowchart 1200 presented in
A number of steps of the procedures described in the context of the flowcharts presented in the previous paragraph is further discussed. In response to the Start_Migration message sent from the source host in box 904 of
Procedure A (Start_Migration Message) Returns Message
-
- 1. The migration policy associated with the migration service is notified of the migration request. This request includes the location of the source of the request (either IP address or full qualified domain name).
- 2. The policy checks to see if migration from the requesting source is allowed. If not, a Migration_Denied message is returned.
- 3. If allowed, the policy checks to see if sufficient resources are available to run the migrating virtual machine. If not, a Migration_Denied message is returned.
- 4. If sufficient resources are available, a Migration_Permitted message is returned.
Executed on the source host, Procedure B used in box 1004 in
Procedure B (ManagedElement)
-
- 1. The sensor service is located using the service registry provided by EAF.
- 2. The queueEvents API is invoked on the sensor service with the ManagedElement passed as context. This API causes a queue of events to be created within the sensor service such that no further events will be forwarded to the ManagedElement; they will simply be queued pending reactivation of event forwarding.
- 3. For all dependent managed elements of this ManagedElement, the queueEventsRecursive API is invoked on the dependent managed element. This causes Procedure B to be invoked recursively.
Executed on the source or the destination host, Procedure C is used when it is required to re-start the process of dispatching events to managed elements. The queue of events is destroyed once messages are processed by the managed elements.
Procedure C (ManagedElement)
-
- 1. The sensor service is located using the service registry provided by EAF.
- 2. The startEvents API is invoked on the sensor service with the ManagedElement passed as context. This API causes the queue of events created within the sensor service for the ManagedElement to be added to a time-ordered queue of events stored within the sensor service. The queue associated with the ManagedElement is destroyed.
- 3. For all dependent managed elements of this ManagedElement, the startEventsRecursive API is invoked on the dependent managed element. This causes Procedure C to be invoked recursively.
Executed on the source host, Procedure D used in box 1210 of
Procedure D (ManagedElement)
-
- 1. The sensor service is located using the service registry provided by EAF.
- 2. The stopEvents API is invoked on the sensor service with the ManagedElement passed as context. This API causes events to cease being forwarded to the ManagedElement.
- 3. For all dependent managed elements of this ManagedElement, the destroyRecursive API is invoked on the dependent managed element. This causes Procedure D to be invoked recursively.
- 4. The managed object service is located using the service registry provided by EAF.
- 5. The ManagedElement is deregistered from the managed object service.
Procedure E (ManagedElement, SerializationStream)
-
- 1. The serialize API on the ManagedElement is invoked and the resulting byte stream written to the SerializationStream.
- 2. For all dependent managed elements of this ManagedElement, the serializeRecursive API is invoked on the dependent managed element. This causes Procedure E to be invoked recursively.
Executed on the target host for processing the message sent by the source host in box 1008 of
Procedure F (Management_State Message) Returns Message
-
- 1. The serialized objects associated with body of the message are deserialized and dependencies between them recreated. In the situation where classes are not resident locally, the source migration service is contacted in order to send the required classes. This process may be recursive dependent upon the class hierarchy represented in the managed objects.
- 2. If an object cannot be deserialized, a Management_State_Failed message is returned.
- 3. If an object class cannot be located either locally or retrieved from the source migration service, a Managed_Object_Instantiation_Error message is returned.
- 4. If no errors have been detected return a Management_State_Success message is returned.
Executed on the target host for processing the message sent by the source host in box 1058 of
Procedure G (Management_Event_State Message) Returns Message
-
- 1. The serialized queue of event messages associated with body of the message are deserialized. In the situation where classes are not resident locally, the source migration service is contacted in order to send the required classes. This process may be recursive dependent upon the class hierarchy represented in the managed objected.
- 2. If the queue of messages cannot be deserialized, a Management Event State_Failed message is returned.
- 3. If an object class cannot be located either locally or retrieved from the source migration service, a Managed_Object_Instantiation_Error message is returned.
- 4. The sensor service is located using the service registry provided by EAF.
- 5. The insertEvents API is invoked on the sensor service, with the queue of event messages being passed as context.
- 6. If no errors have been detected return a Management_Event_State_Success message is returned.
Executed on the source host, Procedure H deals with aborting the migration when a timeout occurs or when an error message is received from the target host.
Procedure H (Abort_Migration Message)
-
- 1. All deserialized managed objects are destroyed.
- 2. The sensor service is looked up.
- 3. The destroyEvents API is invoked on the sensor service. This API causes all events to be removed from the sensor service.
Executed on the source host in box 1056 of
Procedure I (SerializationStream)
-
- 1. The sensor service is looked up
- 2. The serializeQueue API on the sensor service is invoked and the resulting byte stream written to the SerializationStream.
Executed on the target host, Procedure J is similar to Procedure H. It performs the cleaning up operations on the target management plane.
Procedure J (Abort_Migration message)
-
- 1. All deserialized managed objects are destroyed.
- 2. The sensor service is looked up.
- 3. The destroyEvents API is invoked on the sensor service. This API causes all events to be removed from the sensor service.
Executed on the source host, Procedure K processes changes that occur to Managed Elements (as captured in box 1108 and box 1110 of
Procedure K (ManagedElement, SerializationStream)
-
- 1. While migration is in progress there is a potential for state to change—affected managed elements are then marked as dirty in this case. Access to the ManagedElement is synchronized for the execution of Procedure K.
- 2. Therefore, if ManagedElement is dirty, the state of the ManagedElement is written to the SerializationStream.
- 3. The dirty bit for the ManagedElement is reset.
- 4. Procedure K is recursively invoked for dependents of the ManagedElement.
- 5. Return the result of the dirty bit of step 2 along with the result of the recursive call.
Executed on the target host, Procedure L is used to restart the migrated VM on the target host after the reception of the Migration_Complete Message sent from the source host in box 1204 of
Procedure L (Migration_Complete message)
-
- 1. The migrated managed objects register with the sensor service for events.
- 2. The VMManagedElement is located within the set of migrated managed objects. Procedure C is then invoked with the VMManagedElement as context.
The embodiment of the present invention has the following features:
-
- Migration of an autonomic manager and the VM it manages;
- Management state preservation during migration;
- Lifecycle maintenance of management software in a virtualized environment; and
- Fault recovery of the management plane when migration of management components cannot be moved in conjunction with a migrated VM.
The embodiment of the invention has the following advantages:
-
- Improved system management through effective delegation;
- Results in reduced cost of ownership of system;
- Higher system availability;
- Management is delegated; management infrastructure responds dynamically to changes in service infrastructure;
- Ability to dynamically react to changes in the applications deployed on a system, e.g., if a new application is deployed, the system can automatically acquire and configure management functionality for it; and
- Provides a mechanism for coherent management of heterogeneous virtualized platforms, e.g., Windows and Linux operating systems.
The system used in the embodiment of this invention includes computing devices. A computing device has a memory for storing the program that performs the steps of the method for achieving VM migration.
Numerous modifications and variations of the present invention are possible in light of the above teachings. It is therefore to be understood that within the scope of the given system characteristics, the invention may be practiced otherwise than as specifically described herein.
Claims
1. A method for migrating a service Virtual Machine (VM), comprising a VM managed element including components providing a service, and a VM managing element managing the service VM, from a source host to a target host, the method comprising the steps of:
- (a) queuing events to be processed by the service VM at the source host;
- (b) sending information regarding a current state of the VM managed element from the source host to the target host;
- (c) sending information regarding a state of the queued events from the source host to the target host;
- (d) sending components of the VM managed element that have changed during the execution of step (a)-step (c) from the source host to the target host;
- (e) terminating the service VM and the VM managing element on the source host; and
- (f) resuming execution of the service VM by using the information sent in step (b)-step (d) and resuming the VM managing element on the target host.
2. A system for migrating a service Virtual Machine (VM), comprising a VM managed element including components providing a service, and a VM managing element managing the service VM, from a source host to a target host, the system comprising:
- (a) means for queuing events to be processed by the service VM at the source host;
- (b) means for sending information regarding a current state of the VM managed element from the source host to the target host;
- (c) means for sending information regarding a state of the queued events from the source host to the target host;
- (d) means for sending components of the VM managed element that have changed during the queuing of events to be processed, the sending of information regarding the current state of the VM and the sending of information regarding the state of the queued events;
- (e) means for terminating the service VM and the VM managing element on the source host; and
- (f) means for resuming execution of the service VM by using the information regarding the current state of the VM managed element, the state of the queued events and the components of the VM managed element that have changed sent from the source host to the destination host and resuming the VM managing element on the target host.
Type: Application
Filed: May 15, 2007
Publication Date: Nov 15, 2007
Inventor: Anthony Richard Phillip White (Ottawa)
Application Number: 11/748,816
International Classification: G06F 9/455 (20060101);