WO2022086316A1

WO2022086316A1 - Method for monitoring live migration of virtual machine

Info

Publication number: WO2022086316A1
Application number: PCT/MY2020/050192
Authority: WO
Inventors: Shahrol Hisham BAHAROM; Sharipah Setapa; Jing Yuan Luke
Original assignee: Mimos Berhad
Priority date: 2020-10-23
Filing date: 2020-12-04
Publication date: 2022-04-28

Abstract

The present invention discloses a method for monitoring a live migration of virtual machine, VM, from a source host to a target host. The method comprises the steps of establishing a compiled migration reference report; establishing a route of the migration activities thereof; determining a migration status of the live migration thereof; identifying a migration error of the live migration bearing the negative migration status; assigning the migration error not falling within the standard migration failure category as an unknown error, the live migration of which is placed on hold; and determining a probable cause of the unknown error and a corrective solution based on the relation inference to solve the unknown error so as to relinquish the on-hold live migration.

Description

METHOD FOR MONITORING LIVE MIGRATION OF VIRTUAL MACHINE

FIELD OF THE INVENTION

The present invention generally relates to the field of virtual machines. More particularly, the present invention relates to a method for monitoring a live migration of virtual machine (VM) from a source host to a target host.

BACKGROUND OF THE INVENTION

A virtual machine (VM) is an emulation of an actual physical computer. VM technology allows multiple virtual machines (VMs) to run on a single physical hardware or machine such as that in a virtual server operating in a multi-tenant environment. VM can be migrated from one host to another host or cluster to perform maintenance, to balance loads, to move VMs apart to minimize fault domain and to migrate to a new server hardware. Depending on the power state of the virtual machine that you migrate, migration can be cold or hot migration.

The migration of VM to a new host must be correctly configured to avoid any unwanted failure events. The compatibility of the new host must be checked using various criteria. If a VM is migrated to a host with an unknown specification, or to a specification different than the previous host, it may cause a conflict and a migration failure during live migration. For instance, the new host must have sufficient a central processing unit (CPU), a graphic processing unit (GPU) or both to support the VM’s requirements especially graphic-intensive applications. Such migration failure must be analyzed to find out the reason for the failure as to whether the failure is caused by any anomaly behavior of the host or VM itself. A lot of time is required to reset the network connection if the connectivity is interrupted during live migration, which degrades the performance of VM. Most importantly, the failure to detect the anomaly behavior may open to many implications.

By way of background, United States Patent Application Publication No. 2015/0339156 A1 discloses systems and method for the management of migrations of virtual machine instances. A migration manager monitors a resource usable for migration of a virtual machine instance in order to predict availability of the migration resource. When migration of a virtual machine instance is desired, the migration manager schedules the migration to occur at a future point in time identified based on the predicted availability of the migration resource.

It would, therefore, be advantageous to provide a solution that would overcome the deficiencies and shortcomings of prior art by way of providing a method for monitoring a live migration of virtual machine (VM) from a source host and a target host. Although there are methods for the same in the prior art, for many practical purposes, there is still considerable room for improvement.

SUMMARY OF THE INVENTION

The following presents a simplified summary of the invention in order to provide a basic understanding of some aspects of the invention. This summary is not an extensive overview of the invention. Its sole purpose is to present some concepts of the invention in a simplified form as a prelude to the more detailed description that is presented later.

Accordingly, the present invention provides a method for monitoring a live migration of virtual machine (VM) from a source host to a target host.

The method of the present invention comprises the steps of establishing a compiled migration reference report, comprising collecting data and information pertaining to migration activities associated with a plurality of VMs, a plurality of source hosts and a plurality of target hosts including a success migration activity and a non-success migration activity related to a hardware, a software, a network connectivity or any combinations thereof; and processing the said data and information to detect the non-success migration activity having an error associated with the hardware, the software, the network connectivity or any combinations thereof directly resolved by a solution which retains the plurality of VMs, the plurality of source hosts, the plurality of target hosts and the network connectivity unaffected, and to classify the same to a standard migration failure category; establishing a route of the migration activities thereof, comprising providing a migration signature comprising a predetermined list of VM behavior groups corresponding to the said error of the standard migration failure category of the compiled migration reference report; determining a relation inference in respect of the success migration activity and the non-success migration activity based on the migration signature thereof; and plotting a simulation of the success migration activity and the non-success migration activity based on the migration signature; determining a migration status of the live migration thereof, wherein the migration status comprises a positive migration status indicating the success migration activity and a negative migration status indicating the non-success migration activity; identifying a migration error of the live migration bearing the negative migration status, including determining if the migration error falls within the standard migration failure category; assigning the migration error not falling within the standard migration failure category as an unknown error, the live migration of which is placed on hold; and determining a probable cause of the unknown error and a corrective solution based on the relation inference to solve the unknown error so as to relinquish the on-hold live migration.

Preferably, the predetermined list of VM behavior groups includes a hardware behavior group, a software behavior group and a network connectivity behavior group.

Preferably, the hardware behavior group includes VM suspension and incompatible processor.

Preferably, the software behavior group includes unsupported files, disability to lock files, failed memory allocation, undetected devices, and insufficient access permission.

Preferably, the connectivity behavior group includes spoof detection, resource manipulation, and blocking of new connection.

Preferably, the method further comprising verifying the probable cause and the corrective solution; and updating the migration signature by incorporating the probable cause and the corrective solution to the said predetermined list of VM behaviors.

Preferably, the step of determining a probable cause of the unknown error and a corrective solution including combining at least two behavior groups selected from the predetermined list of VM behavior groups for use with the relation inference. The foregoing and other objects, features, aspects and advantages of the present invention will become better understood from a careful reading of a detailed description provided herein below with appropriate reference to the accompanying drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

A more complete appreciation of the invention and many of the attendant advantages thereof will be readily as the same becomes better understood by reference to the following detailed description when considered in connection with the accompanying drawings, wherein:

Figure 1 is a flow diagram of a method for monitoring a live migration of virtual machine (VM) from a source host to a target host according to one embodiment of the present invention;

Figure 2 is a flow diagram of the step of establishing a compiled migration reference report of the method in Figure 1 according to one embodiment of the present invention;

Figure 3 is a flow diagram of the step of establishing a route of the migration activities thereof of the method in Figure 1 according to one embodiment of the present invention;

Figure 4 illustrates the method of Figure 1 according to one embodiment of the present invention;

Figure 5 illustrates the step of plotting a simulation of success migration activity and non-success migration activity of the method in Figure 1 according to one embodiment of the present invention;

Figure 6 illustrates a decision plot of success migration activity resulting from the step of plotting illustrated in Figure 5 according to one embodiment of the present invention; Figure 7 illustrates a decision plot of non-success migration activity resulting from the step of plotting illustrated in Figure 5 according to one embodiment of the present invention;

Figure 8 illustrates an example of the step of determining a probable cause of the unknown error and a corrective solution of the method in Figure 1 according to one embodiment of the present invention; and

Figure 9 illustrates another example of the step of determining a probable cause of the unknown error and a corrective solution of the method in Figure 1 according to one embodiment of the present invention.

It is noted that the drawings may not be to scale. The drawings are intended to depict only typical aspects of the invention, and therefore should not be considered as limiting the scope of the invention.

DETAILED DESCRIPTION OF THE INVENTION

The present invention discloses a method for monitoring a live migration of virtual machine (VM) between hosts, namely from a source host to a target host. The method of the present invention preferably identifies and distinguishes different types of migration occurred including any potential or suspicious negative migration activity.

Specifications set during an initialization of a VM can influence its migration to the target host. The specifications of a hardware including a processor (e.g. central processing unit or CPU and graphic processing unit or GPU), a processor architecture and a hardware manufacturer, of a software including a hypervisor, an image file and a state of virtualization (not corrupted), and of a network connectivity including a network response, a network loss and an unknown network are among the important parameters to check and compare before the initialization. The migration of VM to the target host must be correctly configured in terms of the hardware, the software and the network connectivity.

The terms “virtual machine”, “virtual machines”, “VM” and “VMs” are used interchangeably and generally refer to any operating system environment that is abstracted from a physical or computing hardware by a virtual machine manager (e.g., a hypervisor). Multiple VMs each running its own operating system (OS) may exist in any one or more servers. Applications may run on one or more VMs in each internal network. Applications may include, but not limited to, web services that run on dedicated web servers, application services that run on dedicated application servers, and database services that run on dedicated database servers. VMs, in some embodiments, operate with their own guest operating systems on a host machine using resources of the host virtualized by virtualization software (e.g. a hypervisor). The tenant (i.e. the owner of the VM) can choose which applications to operate on top of the guest operating system. Some containers, on the other hand, are constructs that run on top of a host operating system without the need for a hypervisor or separate guest operating system. The host operating system can use name spaces to isolate the containers from each other and therefore can provide operating-system level segregation of the different groups of applications that operate within different containers. This segregation is akin to the VM segregation that may be offered in hypervisor-virtualized environments that virtualize system hardware, and thus can be viewed as a form of virtualization that isolates different groups of applications that operate in different containers.

The term “migration” as used herein generally indicates that a VM is migrated from one host (i.e. a source host) to another host (i.e. a target or destination host). For example, a VM in a source host being migrated to a target host may mean that the VM is generated in the target host, and data in the source host and the VM is transferred to the target host. The term “live migration” is used to designate the processes of moving a running application or a running virtual machine from the source host to the target host. The “migration” is “live” as the application is kept running for the majority of the move.

The term “host machine” or “host” as used herein generally refers to a machine that includes the elements of the system under discussion. However, this disclosure should not be read to limit a host machine in that manner when one having skill in the art will recognize that one or more of those elements may be performed remotely.

The term “virtualization layer” as used herein generally refers to any data layer and/or application layer that overlays and/or is abstracted from an operating system environment. Additionally, or alternatively, the modules and/or data described herein may reside and/or execute within the virtualization layer. A virtualization layer may be managed by a software virtualization solution, for instance, a file system filter that presents the virtualization layer as though it were part of an underlying base operating system. For example, a software virtualization solution may redirect calls that are initially directed to locations within a base file system and/or registry to locations within a virtualization layer.

The term “operating system” or OS as used herein generally refers to any kind, size, or configuration of operating system including, for example, a program or a collection of programs that interact with resources of a computer system, for example, a processor, a memory, a storage device, and input/output devices, manage the use of those resources by other programs, and provide features that are useful to the other programs and to the user of the computer system. The term "guest" operating system refers to a VM’s operating system, in contrast to a "host" operating system. In many embodiments, the guest operating system may be different from the host operating system.

The term “central processing unit” or CPU as used herein generally refers to a processing resource which may be implemented with one or more physical processing cores which may be apportioned into one or more processing resources associated with each processing core. The term CPU may be used to refer to a one or more physical processing units or cores or a portion of such providing a processing resource.

The term “graphic processing unit” or GPU as used herein generally refers to an electronic data processing unit which is designed specifically for calculations in the field of computer graphics.

The term “data” as used herein generally refers to information in a form suitable for use with a computer, comprising one or more computer-executable program code portions, executable and non-executable files, machine binary code, and/or any other digital information used on a computer. It may be taken to encompass information stored in electronic or electronically readable form. The terms “data” and “information” may be used synonymously and interchangeably herein. The term “information” may refer to data that is processed, organized, structured or presented in context of a computing or archiving process, so as to make it useful.

According to one preferred embodiment of the present invention, with reference to Figure 1 , the method comprises the following steps:

S100 - establishing a compiled migration reference report;

The step S100 of establishing a compiled migration reference report, with reference to Figure 2, preferably comprises the steps:

5101 - collecting data and information pertaining to migration activities associated with a plurality of VMs, a plurality of source hosts and a plurality of target hosts including a success migration activity and a non-success (or failed) migration activity related to a hardware, a software, a network connectivity or any combinations thereof; and

5102 - processing the said data and information to detect the nonsuccess migration activity having an error associated with the hardware, the software, the network connectivity or any combinations thereof directly resolved by a solution which retains the plurality of VMs, the plurality of source hosts, the plurality of target hosts and the network connectivity unaffected, and to classify the same to a standard migration failure category.

It is preferred that the predetermined list of VM behavior groups includes, but not limited to, a hardware behavior group, a software behavior group and a network connectivity behavior group. The hardware behavior group preferably includes VM suspension and incompatible processor. The software behavior group preferably includes, but not limited to, unsupported files, disability to lock files, failed memory allocation, undetected devices, and insufficient access permission. The connectivity behavior group preferably includes, but not limited to, spoof detection, resource manipulation, and blocking of new connection.

S200 - establishing a route of the migration activities thereof; The step S200 of establishing a route of the migration activities thereof, with reference to Figure 3, preferably comprises the steps:

5201 - providing a migration signature comprising a predetermined list of VM behavior groups corresponding to the said error of the standard migration failure category of the compiled migration reference report;

5202 - determining a relation inference in respect of the success migration activity and the non-success migration activity based on the migration signature thereof; and

5203 - plotting a simulation of the success migration activity and the non-success migration activity based on the migration signature.

S300 - determining a migration status of the live migration thereof, wherein the migration status comprises a positive migration status indicating the success migration activity and a negative migration status indicating the non-success migration activity;

S400 - identifying a migration error of the live migration bearing the negative migration status;

The step S400 of identifying a migration error of the live migration bearing the negative migration status preferably includes the step of determining if the migration error falls within the standard migration failure category.

S500 - assigning the migration error not falling within the standard migration failure category as an unknown error, the live migration of which is placed on hold; and

S600 - determining a probable cause of the unknown error and a corrective solution based on the relation inference to solve the unknown error so as to relinquish the on-hold live migration. The step S600 of determining a probable cause of the unknown error and a corrective solution preferably includes the step of combining at least two behavior groups selected from the predetermined list of VM behavior groups for use with the relation inference.

The method of the present invention further comprises the steps of: a. verifying the probable cause and the corrective solution; and b. updating the migration signature by incorporating the probable cause and the corrective solution to the said predetermined list of VM behaviors.

Essentially, according to the present invention, various possible migration activities including the success migration activity and the non-success migration activity can be arranged and organized. Each structure can be plotted through the migration activities. The non-success migration activity can happen at any time and are thus non-deterministic, i.e. unpredictable. The non-success migration activity is analyzed in order to differentiate as to whether the failed migration activity is related to or originates from the hardware, the software, the network connectivity or any combinations thereof or an unknown cause. The non-success migration activity with the unknown cause (when checked and compared to that of the standard migration failure category in the said compiled migration reference report) is assigned as an unknown error. The detected unknown error is further analyzed to simplify or to ensure that the failure of such migration activity is not caused on purpose or purposely by an error or anomaly other than those from the hardware and the software. The anomaly is preferably a symptom error which is different from a standard error affecting a host or VM. The standard error generally refers to an error caused by knowledgeable error or legitimate error.

The migration signature is adopted to designate the mechanism used to detect that a non-success migration activity has occurred. The migration signature is used to trigger an action of differentiating the error according to its type, i.e. the hardware, the software and the network connectivity. The probable cause of the unknown error is determined alongside the corrective solution to solve or resolve the unknown error and to relinquish or release the live migration which is placed on hold.

The live migration can be interfered or disrupted or interrupted by the following interferences:

• Network Interference - communication interference

• Inter-VM Interference - sharing the same platform can cause a degradation due to shared resources

• Application Performance Interference - resource, process file, system interference

As can be seen above, during live migration, there are various factors involved such as network, sharing platform and application. These factors which also run during the live migration can cause interferences since they share resources which, consequently, will affect and render the process migration not smooth because they would need to handle other VMs at the same time. Other factors, such as connectivity, will impact the migration if the connectivity is down or halted even for a while then the live migration will be not succeeded or failed.

The following tables show examples of success migration activities according to exemplary embodiment of the present invention:

Table 1 : First Example of Migration of VM from Source Host to Target Host

Note: Success migration activity with specific identification (ID) is stored in a success migration activity or positive database for use in analyzing cases with a negative migration status. As can be seen above, ID 1 is in status OK/success without a GPU. The machine is in a power off condition. There is no activity inside the machine during migration.

Table 2: Second Example of Migration of VM from Source Host to Target Host

Note: Non-success migration activity with specific identification (ID) is stored in a non-success migration activity or negative database for use in analyzing a specific error threshold in cases with a negative migration status by comparing with those of the positive database.

As can be seen above, ID 2 which is different from ID 1 (previously described) bears a suspended status. This is to save the current state as a backup if anything happens to the machine should the migration continues.

Table 3: Second Example of Migration of VM with GPU from Source Host to Target Host

Note: Success migration activity with specific identification (ID) is stored in a success migration activity or positive database for use in analyzing cases with a negative migration status.

As can be seen above, ID 3 shows that the migration of VM with a GPU is successful. The following table shows an example of non-success migration activity according to exemplary embodiment of the present invention:

Table 4: Example of Migration of VM with GPU from Source Host to Target Host

Note: Error with specific identification (ID) is stored in an error database for use in analyzing cases with a negative migration status and to check whether the error is based on hardware or software.

As can be seen above, ID 5 bears the mentioned status indicating that it is unable to proceed with the migration. For this status, it would be necessary to hold the migration for further analysis, including but not limited to, to check whether the issue is based on or originates from the processor or any related matters.

According to one exemplary embodiment of the present invention, the migration signature is tabulated below:

Table 5: Migration Signature

As can be seen above, the migration signature is about the behaviors of VMs and the respective IDs. By having this migration signature, any VM behavior will be associated or redirected to the stipulated specific ID to avoid overlapping or redundancy in respect to behaviors of the same nature.

Figure 4 illustrates an illustration of the method according to the present invention. During a migration of VMs into another, there would be a plethora of situations and issues which are faced. They can be categorized as a behavior error handled by a behavior error agent, a standard error handled by a standard error agent and an uncertainty or uncertain error handled by an uncertainty agent (see “1” in the figure). It is crucial, based on the present invention, to create a relation inference and to obtain a behavior for use in plotting the negative migration and the positive migration based on comparison against the migration signature thereof (see “2”). The relation inference generally is a relative concept established between the standard error and the uncertainty error through behaviors of the components, i.e. hardware, software and network connectivity. The plotting preferably involves a plotting of a simulation for the negative migration and the positive migration for compliance with the standard knowledgeable error. The standard knowledgeable error is an error which has a solution and is not going to harm or affect the host, the VM, the application and the network connectivity thereof.

Once the positive migration can be affirmed, then any potential negative migration can be plotted (see “3”). The signature migration will be stored and compared with the ones already established and any linkage or references with other relation inferences which do not involved in the live migration (see “4”). In one embodiment, other relation inferences are adopted to differentiate a standalone migration which is not connected to any online activity.

In “5”, the present invention will compare the compatibility of the problem or issue as to whether it is related to the hardware, the software, the network connectivity, or any combinations thereof. Subsequently, it will trigger the negative migration (bearing the negative migration status) to the standard migration failure category (i.e. the standard knowledgeable error). If the said migration error does not fall within the standard migration failure category, then the migration error will be categorized as an unknown error (see “6”). In “7”, if the probable cause is not known, then it will be allocated as negative or suspicious. The negative or suspicious migration error generally refers to an activity caused by a nonstandardization error. The migration will be put on hold until the said unknown or undetectable, suspicious migration error can be justified or cleaned with a minimal risk during assessment of decision (see “8”).

Figure 5 illustrates the step of plotting a simulation of success migration activity and non-success migration activity of the method in the present invention. The positive migration status indicating the success migration activity and the negative migration status indicating the non-success migration activity retrieved from the respective databases are gathered. If the positive migration is affirmed, then elect the negative migration as a new design of structure for the negative migration. During the assembly, they will be categorized into different fields (e.g. success migration activity and non-success migration activity. Once the fields are satisfied, provides a time frame for the negative migration proceeding. If the fields are not satisfied and not ready for the negative migration proceeding, then create an input with various decisions to firm or confirm that the said negative migration is not an anomaly, and that it is caused by those of the standard migration failure category (i.e. the standard knowledgeable error. If all the above cannot be satisfied, then the present invention will proceed with a new terminology or category for classifying the unknown error thereof which is not caused by the anomaly.

Figure 6 illustrates a decision plot of success migration activity resulting from the step S203 in of the present invention. Based on the decision plot, there is no software and/or hardware related issue pertaining to the migration bearing the positive migration status.

Figure 7 illustrates a decision plot of non-success migration activity resulting from the step S203 in of the present invention. Based on the decision plot, there is no software and/or hardware related issue pertaining to the migration bearing the negative migration status.

Figure 8 illustrates an example of the step S600 in the present invention. As shown in the figure, two groups related to the negative migration activity will be tracked to obtain a decision classification for onward action. The two groups comprise the first group (i.e. Group A) which relates to network connectivity, particularly to network behavior and policy, and the second group (i.e. Group B) which relates to hardware, particularly to behavior of architecture and processor.

Figure 9 illustrates another example of the step S600 in the present invention. As shown in the figure, two groups related to the negative migration activity will be tracked to obtain a decision classification for onward action. The two groups comprise the first group (i.e. Group C) which relates to network connectivity, particularly to network behavior and policy, and the second group (i.e. Group H) which relates to software, particularly to behavior of the lower or updated software version.

Although an overview of the inventive subject matter has been described with reference to specific example embodiments, various modifications and changes may be made to these embodiments without departing from the broader scope of embodiments of the present disclosure. Such embodiments of the inventive subject matter may be referred to herein, individually or collectively, by the term “invention” merely for convenience and without intending to voluntarily limit the scope of this application to any single disclosure or inventive concept if more than one is, in fact, disclosed.

The embodiments illustrated herein are described in sufficient detail to enable those skilled in the art to practice the teachings disclosed. Other embodiments may be used and derived therefrom, such that structural and logical substitutions and changes may be made without departing from the scope of this disclosure. The Detailed Description, therefore, is not to be taken in a limiting sense, and the scope of various embodiments is defined only by the appended claims, along with the full range of equivalents to which such claims are entitled.

As used herein, the term “or” may be construed in either an inclusive or exclusive sense. Moreover, plural instances may be provided for resources, operations, or structures described herein as a single instance. Additionally, boundaries between various resources, operations, modules, engines, and data stores are somewhat arbitrary, and particular operations are illustrated in a context of specific illustrative configurations. Other allocations of functionality are envisioned and may fall within a scope of various embodiments of the present disclosure. In general, structures and functionality presented as separate resources in the example configurations may be implemented as a combined structure or resource. Similarly, structures and functionality presented as a single resource may be implemented as separate resources. These and other variations, modifications, additions, and improvements fall within a scope of embodiments of the present disclosure as represented by the appended claims. The specification and drawings are, accordingly, to be regarded in an illustrative rather than a restrictive sense.

The foregoing description, for the purpose of explanation, has been described with reference to specific example embodiments. However, the illustrative discussions above are not intended to be exhaustive or to limit the possible example embodiments to the precise forms disclosed. Many modifications and variations are possible in view of the above teachings. The example embodiments were chosen and described in order to best explain the principles involved and their practical applications, to thereby enable others skilled in the art to best utilize the various example embodiments with various modifications as are suited to the particular use contemplated.

It will also be understood that, although the terms “first,” “second,” and so forth may be used herein to describe various elements, these elements should not be limited by these terms. These terms are only used to distinguish one element from another. For example, a first contact could be termed a second contact, and, similarly, a second contact could be termed a first contact, without departing from the scope of the present example embodiments. The first contact and the second contact are both contacts, but they are not the same contact.

The terminology used in the description of the example embodiments herein is for the purpose of describing particular example embodiments only and is not intended to be limiting. As used in the description of the example embodiments and the appended examples, the singular forms “a,” “an,” and “the” are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will also be understood that the term “and/or” as used herein refers to and encompasses any and all possible combinations of one or more of the associated listed items. It will be further understood that the terms “comprises” and/or “comprising,” when used in this specification, specify the presence of stated features, integers, steps, operations, elements, and/or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and/or groups thereof.

As used herein, the term “if” may be construed to mean “when” or “upon” or “in response to determining” or “in response to detecting,” depending on the context. Similarly, the phrase “if it is determined” or “if [a stated condition or event] is detected” may be construed to mean “upon determining” or “in response to determining” or “upon detecting [the stated condition or event]” or “in response to detecting [the stated condition or event],” depending on the context.

Claims

CLAIMS A method for monitoring a live migration of virtual machine, VM, from a source host to a target host, characterized in that, the method comprising the steps: establishing a compiled migration reference report (S100), comprising: collecting data and information pertaining to migration activities associated with a plurality of VMs, a plurality of source hosts and a plurality of target hosts including a success migration activity and a non-success migration activity related to a hardware, a software, a network connectivity or any combinations thereof (S101 ); and processing the said data and information to detect the non-success migration activity having an error associated with the hardware, the software, the network connectivity or any combinations thereof directly resolved by a solution which retains the plurality of VMs, the plurality of source hosts, the plurality of target hosts and the network connectivity unaffected, and to classify the same to a standard migration failure category (S102); establishing a route of the migration activities thereof (S200), comprising: providing a migration signature comprising a predetermined list of VM behavior groups corresponding to the said error of the standard migration failure category of the compiled migration reference report (S201 ); determining a relation inference in respect of the success migration activity and the non-success migration activity based on the migration signature thereof (S202); and plotting a simulation of the success migration activity and the non- success migration activity based on the migration signature (S203); determining a migration status of the live migration thereof (S300), wherein the migration status comprises a positive migration status indicating the success migration activity and a negative migration status indicating the non-success migration activity; identifying a migration error of the live migration bearing the negative migration status (S400), including determining if the migration error falls within the standard migration failure category; assigning the migration error not falling within the standard migration failure category as an unknown error, the live migration of which is placed on hold (S500); and determining a probable cause of the unknown error and a corrective solution based on the relation inference to solve the unknown error so as to relinquish the on-hold live migration (S600). The method according to Claim 1 , wherein the predetermined list of VM behavior groups includes a hardware behavior group, a software behavior group and a network connectivity behavior group. The method according to Claim 2, wherein the hardware behavior group includes VM suspension and incompatible processor. The method according to Claim 2, wherein the software behavior group includes unsupported files, disability to lock files, failed memory allocation, undetected devices, and insufficient access permission. The method according to Claim 2, wherein the connectivity behavior group includes spoof detection, resource manipulation, and blocking of new connection. The method according to Claim 1 , wherein the method further comprising: verifying the probable cause and the corrective solution; and updating the migration signature by incorporating the probable cause and the corrective solution to the said predetermined list of VM behaviors. The method according to Claim 1 , wherein the step of determining a probable cause of the unknown error and a corrective solution (S600) including: combining at least two behavior groups selected from the predetermined list of VM behavior groups for use with the relation inference.