A virtual machine migration method and device

By obtaining the distributed lock command response time and network metrics of candidate physical machines, and using the BPNN model to predict migration time, the virtual machine migration process is optimized, solving the problems of excessively long migration time and insufficient security in existing technologies, and achieving a more efficient and stable migration process.

CN119396528BActive Publication Date: 2026-07-31DAWNING CLOUD COMPUTING TECH CO LTD
View PDF 2 Cites 0 Cited by

Patent Information

Authority / Receiving Office
CN · China
Patent Type
Patents(China)
Current Assignee / Owner
DAWNING CLOUD COMPUTING TECH CO LTD
Filing Date
2024-10-21
Publication Date
2026-07-31

AI Technical Summary

Technical Problem

In cloud computing architectures, existing technologies lack intelligent virtual machine migration strategies, resulting in excessively long migration times, increased security risks and the possibility of deadlocks, and an inability to fully utilize the dynamic resource conditions in the cloud environment, affecting overall performance and stability.

Method used

By obtaining the performance parameters of candidate physical machines, including the response time of distributed lock commands, a BPNN model is used for prediction. The physical machine with the shortest predicted migration time is selected for migration, and the migration process is optimized by combining network metrics.

Benefits of technology

It effectively reduces the risk of deadlock during migration, reduces the problem of excessively long activation time for virtual machine resource sharing, and improves the security and overall performance of the migration process.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN119396528B_ABST
    Figure CN119396528B_ABST
Patent Text Reader

Abstract

This application relates to the field of cloud computing technology, specifically to a virtual machine migration method and apparatus. The method includes: obtaining performance parameters corresponding to K candidate physical machines, wherein the performance parameters of the i-th candidate physical machine include the response time of the i-th candidate physical machine to a distributed lock command; inputting the performance parameters corresponding to the K candidate physical machines into a first model to obtain a first prediction result output by the first model, wherein the first prediction result includes the predicted migration time corresponding to the K candidate physical machines; determining a second physical machine based on the predicted migration time corresponding to the K candidate physical machines, wherein the second physical machine is the physical machine with the shortest predicted migration time among the K candidate physical machines; and migrating the virtual machines in the first physical machine to the second physical machine. The above method can achieve efficient virtual machine migration.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] This application relates to the field of cloud computing technology, specifically to a virtual machine migration method and apparatus. Background Technology

[0002] In modern cloud computing architectures, efficient and secure management of shared storage resources is a crucial indicator of cloud platform reliability. To this end, distributed locking mechanisms such as Sanlock are typically employed to manage Logical Volume Managers (LVM).

[0003] For scenarios involving shared storage resources using distributed locking mechanisms, how to efficiently migrate virtual machines is a problem worth noting. Summary of the Invention

[0004] This application provides a virtual machine migration method and apparatus for achieving efficient virtual machine migration.

[0005] In a first aspect, embodiments of this application provide a virtual machine migration method, the method comprising:

[0006] Obtain the performance parameters corresponding to K candidate physical machines, where the performance parameters of the i-th candidate physical machine include the response time of the i-th candidate physical machine to the distributed lock command, and the i-th candidate physical machine is any one of the K candidate physical machines, i is less than or equal to K, and i and K are both positive integers;

[0007] The performance parameters corresponding to the K candidate physical machines are input into the first model to obtain the first prediction result output by the first model. The first prediction result includes the predicted migration time corresponding to the K candidate physical machines. The predicted migration time of the i-th candidate physical machine refers to the predicted time to migrate the virtual machine in the first physical machine to the i-th candidate physical machine.

[0008] The second physical machine is determined based on the predicted migration time corresponding to the K candidate physical machines, and the second physical machine is the physical machine with the shortest predicted migration time among the K candidate physical machines;

[0009] Migrate the virtual machines in the first physical machine to the second physical machine.

[0010] In this embodiment of the invention, the performance parameters corresponding to the K candidate physical machines include the response time of each candidate physical machine to the distributed lock command. This response time reflects the response capability of each candidate physical machine in executing the distributed lock command, which can effectively evaluate the lock performance of each candidate physical machine. Incorporating the response time of each candidate physical machine to the distributed lock command into the first model can effectively reduce the risk of deadlock during migration and reduce the probability of excessively long virtual machine resource sharing activation time, while improving the security of virtual machines during migration.

[0011] In one possible embodiment, the performance parameters of the i-th candidate physical machine may further include one or more of the following: the amount of CPU available in the i-th candidate physical machine, the amount of memory available in the i-th candidate physical machine, the memory utilization rate of the i-th candidate physical machine, and the load of the i-th candidate physical machine.

[0012] In this embodiment, the performance parameters of the i-th candidate physical machine include not only the response time of the i-th candidate physical machine to the distributed lock command, but also the conventional performance indicators of the i-th candidate physical machine. By comprehensively considering indicators such as CPU, memory and load, a more comprehensive performance evaluation of the candidate physical machine can be performed.

[0013] In one possible embodiment, the performance parameters corresponding to the K candidate physics machines are input into a first model to obtain a first prediction result output by the first model, including:

[0014] The performance parameters corresponding to the K candidate physical machines and the performance parameters of the first physical machine are input into the first model to obtain the first prediction result. The performance parameters of the first physical machine include the response time of the first physical machine to the distributed lock command.

[0015] In this embodiment, by inputting the performance parameters corresponding to the K candidate physical machines and the response time of the first physical machine to the distributed lock command into the first model, the first model can more accurately predict the migration time of each candidate physical machine.

[0016] In one possible embodiment, the performance parameters of the first physical machine may further include one or more of the following: CPU availability of the first physical machine, memory availability of the first physical machine, memory utilization rate of the first physical machine, load of the first physical machine, CPU utilization rate and memory utilization rate of the virtual machines in the first physical machine.

[0017] In this embodiment, the performance parameters of the first physical machine include not only the response time of the first physical machine to the distributed lock command, but also the conventional performance indicators of the first physical machine. By comprehensively considering indicators such as CPU, memory and load, a more comprehensive performance evaluation of the first physical machine can be performed.

[0018] In one possible embodiment, the performance parameters corresponding to the K candidate physics machines are input into a first model to obtain a first prediction result output by the first model, including:

[0019] The performance parameters and network metrics corresponding to the K candidate physical machines are input into the first model to obtain the first prediction result. The network metrics include network latency and / or packet loss rate.

[0020] In this embodiment, network latency and packet loss rate are fundamental factors affecting virtual machine migration performance. For example, high network latency or high packet loss rate may lead to migration failure. By incorporating these metrics into the model, the impact of these network issues on migration time can be predicted, thereby facilitating the identification of the target physical machine with the shortest predicted migration time.

[0021] In one possible embodiment, the first model is trained using a training dataset, which includes the response times of historical source physical machines to distributed lock commands and the response times of historical target physical machines to distributed lock commands.

[0022] In this embodiment, by using historical migration data to train the BPNN model, the first model can comprehensively consider the response time of the historical source physical machine and the historical target physical machine in executing distributed lock commands during the training process, which helps to train a first model with more accurate prediction results.

[0023] In one possible embodiment, the response time of the historical source physical machine to the distributed lock command includes a first response time and a second response time; wherein, the first response time is the response time of the historical source physical machine to the distributed lock command of the shared activation type, and the second response time is the response time of the historical source physical machine to the distributed lock command of the deactivation type.

[0024] The response time of the historical target physical machine to the distributed lock command includes a third response time and a fourth response time; wherein, the third response time is the response time of the historical target physical machine to the distributed lock command of the shared activation type, and the fourth response time is the response time of the historical target physical machine to the distributed lock command of the exclusive activation type.

[0025] In this embodiment, by comprehensively considering the response times of the historical source physical machine and the historical target physical machine to the distributed lock command, including the first response time (used for the historical source physical machine to change the access state of the system volume and data volume in the virtual machine from exclusive active state to shared active state), the second response time (used for the historical source physical machine to change the access state of the system volume and data volume in the virtual machine from shared active state to deactivated state), the third response time (used for the historical target physical machine to change the access state of the system volume and data volume in the virtual machine from deactivated state to shared active state), and the fourth response time (used for the historical target physical machine to change the access state of the system volume and data volume in the virtual machine from shared active state to exclusive active state), the lock performance of the historical source physical machine and the historical target physical machine at different stages can be evaluated more comprehensively.

[0026] In one possible embodiment, the training dataset further includes one or more of the following: CPU availability of the historical source physical machine, memory availability of the historical source physical machine, memory utilization rate of the historical source physical machine, load of the historical source physical machine, CPU utilization rate and memory utilization rate of virtual machines in the historical source physical machine, CPU availability of the historical target physical machine, memory availability of the historical target physical machine, memory utilization rate of the historical target physical machine, load of the historical target physical machine, historical network latency time and / or historical packet loss rate.

[0027] In this embodiment, the training dataset also includes conventional performance metrics of historical source physics machines and historical target physics machines, as well as network metrics, which can improve the prediction accuracy of the first model.

[0028] In one possible embodiment, the response time of the i-th candidate physical machine to the distributed lock command is the same as the response time of the i-th candidate physical machine to the probe-type distributed lock command.

[0029] The response time of the first physical machine to the distributed lock command is the same as the response time of the first physical machine to the probe-type distributed lock command.

[0030] In this embodiment, by introducing the response time of the i-th candidate physical machine and the first physical machine to the distributed lock command of the probe type, the ability of the candidate physical machine and the first physical machine to execute the distributed lock command during the actual migration process can be detected in advance.

[0031] Thirdly, this application provides a virtual machine migration device, including:

[0032] Memory, used to store program instructions;

[0033] A processor is configured to invoke program instructions stored in the memory and execute the steps of the method described in any one of the first aspects according to the obtained program instructions.

[0034] Fourthly, this application provides a computer-readable storage medium storing a computer program, the computer program including program instructions, which, when executed by a computer, cause the computer to perform the method described in any one of the first aspects.

[0035] Fifthly, this application provides a computer program product comprising: computer program code, which, when run on a computer, causes the computer to perform the method described in any one of the first aspects. Attached Figure Description

[0036] Figure 1 A flowchart illustrating a virtual machine migration method provided in this application embodiment;

[0037] Figure 2 A schematic diagram illustrating the acquisition of prediction results based on a first model, provided as an embodiment of this application;

[0038] Figure 3 Schematic diagram of the structure of the virtual machine migration device provided in the embodiments of this application Figure 1 ;

[0039] Figure 4 Schematic diagram of the structure of the virtual machine migration device provided in the embodiments of this application Figure 2 . Detailed Implementation

[0040] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this invention, and not all of them. Based on the embodiments of this invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this invention.

[0041] To facilitate understanding, the technical scenarios involved in the embodiments of this application will be explained first.

[0042] This application embodiment relates to a cloud computing environment consisting of multiple physical machines, where a management node is responsible for centralized management and control of each physical machine. Taking a virtual machine as an example, assuming the virtual machine is deployed on the first physical machine, its memory data is stored in the virtual machine's own memory, and its system volume and data volume are stored on shared storage resources and can only be accessed by the first physical machine. When the virtual machine needs to be migrated from the first physical machine to a target physical machine, the memory data needs to be transferred to the target physical machine, and the virtual machine's system volume and data volume must be accessible to the target physical machine.

[0043] For ease of understanding, the technical terms involved in the embodiments of this application are explained.

[0044] Virtual machine: refers to a software-based computing environment that simulates the hardware system of a physical computer, allowing users to run multiple operating systems and applications on a single physical server.

[0045] Distributed lock mechanism: It is a technique used in distributed systems to coordinate access to shared resources by multiple nodes. It prevents data inconsistency and conflicts by synchronizing the lock state among different nodes.

[0046] Management node: Also known as management server or control node, in cloud computing and distributed system environments, the management node is the central node responsible for managing and coordinating the operation of the entire system. It usually undertakes key functions such as resource management and task scheduling to ensure the stable operation and performance optimization of the entire system.

[0047] Logical Volume Manager (LVM) is a disk management technology used in Linux environments. It can combine multiple physical hard drives into a single logical volume for unified management. In addition, LVM supports dynamically adjusting the size of logical volumes without worrying about data loss, providing flexible storage space management capabilities.

[0048] Distributed lock commands are operation commands used to implement and manage locks in a distributed system. For example, distributed lock commands can be divided into several types. The following uses the Lvchange command as an example to introduce several main types of the Lvchange command:

[0049] 1) Lvchange-asy command: This is a distributed lock command for shared activation type, used to change the access state of the physical machine to the system volume and data volume of the virtual machine from exclusive activation state to shared activation state;

[0050] 2) The Lvchange-an command: This is a distributed lock command for deactivation type, used to change the access status of the physical machine to the system volume and data volume of the virtual machine from a shared active state to an inactive state;

[0051] 3) Lvchange-ae command: This is a distributed lock command for exclusive activation type, used to change the access state of the physical machine to the system volume and data volume of the virtual machine from shared activation state to exclusive activation state;

[0052] 4) Lvchange-help command: This is a distributed lock command for probe types, used to test the physical machine's response capability when executing distributed lock commands, without changing the access status of the virtual machine's system volume and data volume.

[0053] Currently, in operations involving node changes, such as virtual machine migration, excessively long migration times lead to prolonged activation times for the virtual machine's system and data volumes, increasing security risks during migration and the likelihood of deadlocks. Furthermore, existing technologies lack intelligent migration strategies, increasing total migration time and impacting service availability. Moreover, the static or simplified decision-making mechanisms used in existing technologies fail to fully utilize the dynamic resource conditions in the cloud environment, resulting in suboptimal target physical machine selection and affecting overall performance and stability.

[0054] Based on the above issues, such as Figure 1 As shown in the figure, an embodiment of the present invention provides a method for virtual machine migration, the method comprising:

[0055] Step 100: Obtain the performance parameters corresponding to the K candidate physical machines. The performance parameters of the i-th candidate physical machine include the response time of the i-th candidate physical machine to the distributed lock command. The i-th candidate physical machine is any one of the K candidate physical machines, i is less than or equal to K, and i and K are both positive integers.

[0056] First, the control node will filter all physical machines in the cluster based on their resource usage, network conditions, etc., and obtain K candidate physical machines with better performance.

[0057] In practice, all physical machines in the cluster are first assessed to determine if they meet the basic requirements for virtual machine migration. Resource usage includes, but is not limited to, the available CPU and memory of the physical machines, while network conditions include, but are not limited to, network latency and bandwidth. Furthermore, the management node also considers factors such as the energy consumption and fault history of the physical machines to ensure that the selected candidate physical machines not only provide the necessary resources but also guarantee the stable, efficient, and maintainable operation of the migrated virtual machines.

[0058] After selecting K candidate physical machines, the management node will also collect the performance parameters corresponding to the K candidate physical machines. Among them, the performance parameters of the i-th candidate physical machine include the response time of the i-th candidate physical machine to the distributed lock command.

[0059] The response time of the i-th candidate physical machine to the distributed lock command is the same as the response time of the i-th candidate physical machine to the probe-type distributed lock command.

[0060] In implementation, after selecting K candidate physical machines, the control node can trigger the i-th candidate physical machine to execute a distributed lock command. This distributed lock command is a probe-type distributed lock command, specifically the `lvchange-help` command, used to test the i-th candidate physical machine's response capability. This command does not change any configuration or state of the i-th candidate physical machine. After executing the `lvchange-help` command, the i-th candidate physical machine outputs a work log, recording the start and end timestamps of the command execution. The difference between the start and end timestamps represents the response time of the i-th candidate physical machine to the distributed lock command.

[0061] In addition, the performance parameters of the i-th candidate physical machine include one or more of the following: CPU availability, memory availability, memory utilization, and load.

[0062] Furthermore, the control node will also collect the performance parameters of the first physical machine, including the response time of the first physical machine to distributed lock commands.

[0063] The response time of the first physical machine to the distributed lock command is the same as the response time of the first physical machine to the probe-type distributed lock command.

[0064] In practice, the control node can trigger the first physical machine to execute a distributed lock command. This distributed lock command, specifically the `lvchange-help` command, is for probe-type distributed locks and is used to test the first physical machine's response capability. This command does not change any configuration or state of the first physical machine. After executing the `lvchange-help` command, the first physical machine outputs a work log, recording the start and end timestamps of the command execution. The difference between the start and end timestamps represents the first physical machine's response time to the distributed lock command.

[0065] In addition, the performance parameters of the first physical machine also include one or more of the following: CPU availability, memory availability, memory utilization, load, CPU utilization and memory utilization of the virtual machines in the first physical machine.

[0066] Step 110: Input the performance parameters corresponding to the K candidate physical machines into the first model to obtain the first prediction result output by the first model. The first prediction result includes the predicted migration time corresponding to the K candidate physical machines. The predicted migration time of the i-th candidate physical machine refers to the predicted time for migrating the virtual machine in the first physical machine to the i-th candidate physical machine.

[0067] For example, the first model is trained before inputting the performance parameters corresponding to the K candidate physical machines into the first model.

[0068] For example, the first model may be trained in, but is not limited to, the following manner:

[0069] 1. Obtain the training dataset. For example, the training dataset includes the response times of historical source physical machines to distributed lock commands and the response times of historical target physical machines to distributed lock commands.

[0070] The response time of the historical source physical machine to the distributed lock command includes a first response time and a second response time; the first response time is the response time of the historical source physical machine to the distributed lock command of the shared activation type, and the second response time is the response time of the historical source physical machine to the distributed lock command of the deactivation type. The response time of the historical target physical machine to the distributed lock command includes a third response time and a fourth response time; the third response time is the response time of the historical target physical machine to the distributed lock command of the shared activation type, and the fourth response time is the response time of the historical target physical machine to the distributed lock command of the exclusive activation type.

[0071] In practical implementation, the specific process of obtaining the response time of the historical source physical machine to the distributed lock command and the response time of the historical target physical machine to the distributed lock command is as follows:

[0072] The control node can trigger the historical source physical machine to execute a distributed lock command. This distributed lock command, specifically the `lvchange-asy` command, is for shared-activation types and changes the historical source physical machine's access status to the virtual machine's system volume and data volume from exclusive activation to shared activation. Executing the `lvchange-asy` command on the historical source physical machine ensures that the virtual machine's system volume and data volume are not only accessible to the current historical source physical machine but also accessible to other physical machines whose access status has been changed to shared activation.

[0073] After the historical source physical machine completes the lvchange-asy command, it will output a work log, which records the start and end timestamps of the command execution. The difference between the start and end timestamps is the first response time.

[0074] After the source physical machine executes the `lvchange-asy` command, it sends a first state update message to the target physical machine. This message indicates that the virtual machine's system volume and data volume can be shared. Upon receiving this message, the target physical machine executes a distributed lock command, specifically the `lvchange-asy` command, which is for shared-active access. This command changes the target physical machine's access to the virtual machine's system and data volumes from inactive to shared-active, meaning the target physical machine can now access these volumes.

[0075] After the historical target physical machine completes the lvchange-asy command, it will output a work log, which records the start and end timestamps of the command execution. The difference between the start and end timestamps is the third response time.

[0076] After the target physical machine executes the lvchange-asy command, it sends a second state update message to the source physical machine, indicating that the target physical machine can now access the virtual machine's system volume and data volume.

[0077] After receiving this information, the source physical machine begins transferring the virtual machine's memory data to the target physical machine. Once all the memory data has been transferred to the target physical machine, the source physical machine executes a distributed lock command. This distributed lock command is a deactivation type command, specifically the `lvchange-an` command, which changes the source physical machine's access status to the system volume and data volume from a shared active state to an inactive state, preventing the source physical machine from accessing the virtual machine's system volume and data volume.

[0078] After the historical source physical machine completes the lvchange-an command, it will output a work log, which records the start and end timestamps of the command execution. The difference between the start and end timestamps is the second response time.

[0079] After the source physical machine executes the `lvchange -an` command, it sends a third-state update message to itself, instructing it to cancel access to the system volume and data volume in the virtual machine. Upon receiving this message, the target physical machine executes a distributed lock command, specifically the `lvchange -ae` command, for exclusive activation. This command changes the source physical machine's access to the virtual machine's system and data volumes from shared activation to exclusive activation, making the source physical machine the sole physical machine authorized to access these volumes.

[0080] After the historical target physical machine completes the lvchange-ae command, it will output a work log, which records the start and end timestamps of the command execution. The difference between the start and end timestamps is the fourth response time.

[0081] Furthermore, in addition to the response times of the historical source physical machine to the distributed lock command (first response time and second response time) and the response times of the historical target physical machine to the distributed lock command (third response time and fourth response time), the training dataset also includes one or more of the following: CPU availability of the historical source physical machine, memory availability of the historical source physical machine, memory utilization of the historical source physical machine, load of the historical source physical machine, CPU utilization and memory utilization of virtual machines in the historical source physical machine, CPU availability of the historical target physical machine, memory availability of the historical target physical machine, memory utilization of the historical target physical machine, load of the historical target physical machine, historical network latency time and / or historical packet loss rate.

[0082] In one possible design, the training dataset may also include the number of other distributed lock commands received by the historical source physical machine in the current migration task, and the number of other distributed lock commands received by the historical target physical machine in the current migration task.

[0083] After obtaining the training dataset, a normalization function is used to scale all data in the training dataset to the range [0, 1] to improve the distribution characteristics of the data. This application does not limit the specific normalization function.

[0084] 2. Train the first model based on the training dataset.

[0085] In practical implementation, firstly, the number of hidden layer neurons in the BackPropagation Neural Network (BPNN) is designed according to the empirical formula l = √n + m + a. BPNN is a basic deep learning model composed of multiple layers of neurons and connection weights. Here, n is the number of input layer neurons, i.e., the number of features in the training dataset; m is the number of output layer neurons, i.e., the number of targets the model predicts; and a is a constant, typically between 1 and 10, used to adjust the number of hidden layer neurons to obtain better network performance.

[0086] Secondly, a suitable activation function is selected for each neuron. For example, the Rulu function is used for the hidden layer and the Sigmoid function is used for the output layer. This application does not limit the specific activation function.

[0087] Third, the normalized training dataset is input into the model. During training, an appropriate loss function is used to improve model performance, such as the cross-entropy loss function. Simultaneously, parameters such as the learning rate, batch size, and number of training epochs are continuously adjusted to optimize the model. Through multiple iterations of training, a first model with higher prediction accuracy can be obtained.

[0088] After obtaining the trained first model, the performance parameters corresponding to the K candidate physical machines, the performance parameters of the first physical machine, and network metrics are input into the first model to obtain the first prediction result output by the first model. The first prediction result may include the predicted migration time corresponding to the K candidate physical machines. The performance parameters corresponding to the K candidate physical machines and the performance parameters of the first physical machine are the performance parameters corresponding to the K candidate physical machines and the performance parameters of the first physical machine collected by the control node in step 100 above. The network metrics include network latency and / or packet loss rate.

[0089] In practical implementation, after obtaining the first model based on the BPNN model, as follows: Figure 2 As shown, after inputting the performance parameters of the i-th candidate physical machine, the performance parameters of the first physical machine, and the network metrics, the first model can output the predicted migration time corresponding to the i-th candidate physical machine. Here, the predicted migration time of the i-th candidate physical machine refers to the predicted time for migrating the virtual machines in the first physical machine to the i-th candidate physical machine.

[0090] Step 120: Determine the second physics machine based on the predicted migration time corresponding to each of the K candidate physics machines. The second physics machine is the physics machine with the shortest predicted migration time among the K candidate physics machines.

[0091] In practice, after the first model outputs the predicted migration times for K candidate physical machines, the management node needs to compare the predicted migration times for the K candidate physical machines to identify which candidate physical machine has the shortest predicted migration time. At the same time, the shortest predicted migration time also means that the shared activation time of the virtual machine's system volume and data volume is the shortest, ensuring the security of the virtual machine migration process.

[0092] By comparing the predicted migration times, the candidate physical machine with the shortest predicted migration time is selected as the second physical machine. After confirming the second physical machine, the management node issues migration commands to both the first and second physical machines to initiate the virtual machine migration process.

[0093] Step 130: Migrate the virtual machines in the first physical machine to the second physical machine.

[0094] In implementation, the control node issues a migration command to the first physical machine. Upon receiving the command, the first physical machine executes the `lvchange-asy` command to change its access status to the virtual machine's system and data volumes from exclusive to shared. After executing the `lvchange-asy` command, the first physical machine sends a first state update message to the second physical machine, indicating that the virtual machine's system and data volumes can be shared. Upon receiving this message, the second physical machine executes the `lvchange-asy` command to change its access status to the virtual machine's system and data volumes from inactive to shared. After executing the `lvchange-asy` command, the second physical machine sends a second state update message to the first physical machine, indicating that it can now access the virtual machine's system and data volumes. Upon receiving this message, the first physical machine begins transferring the virtual machine's memory data to the second physical machine. Once all the memory data has been transferred to the second physical machine, the first physical machine executes the `lvchange-an` command to change its access status to the system and data volumes from shared to inactive. After the first physical machine executes the `lvchange -an` command, it sends a third state update message to the second physical machine, instructing it to cancel access to the virtual machine's system and data volumes. Upon receiving this message, the second physical machine executes the `lvchange -ae` command to change its access status to the virtual machine's system and data volumes from shared to exclusive, ensuring the virtual machine can run independently on the second physical machine. At this point, the virtual machine in the first physical machine has been successfully migrated to the second physical machine.

[0095] In summary, this application provides a virtual machine migration method. The response times of candidate physical machines and the first physical machine to distributed lock commands are input into a first model. These two response times reflect the responsiveness of the candidate and first physical machines in executing distributed lock commands, helping to more comprehensively evaluate their lock performance. By inputting performance parameters including these two response times into the first model, the predicted migration time for each candidate physical machine can be obtained more accurately. This approach effectively reduces the risk of deadlocks during migration, decreases the probability of excessively long virtual machine resource sharing activation times, and improves the security of virtual machines during migration.

[0096] Figure 3 and Figure 4 This is a schematic diagram of a possible virtual machine migration device provided in an embodiment of the present invention. This virtual machine migration device can be used to implement the function of the management node in the above method embodiments.

[0097] like Figure 3 As shown, the virtual machine migration device 300 includes a communication unit 310 and a processing unit 320.

[0098] When the virtual machine migration device 300 is used to implement Figure 1 When managing the function of the control node in the method embodiment shown:

[0099] The communication unit 310 is used to obtain the performance parameters corresponding to the K candidate physical machines respectively. The performance parameters of the i-th candidate physical machine include the response time of the i-th candidate physical machine to the distributed lock command. The i-th candidate physical machine is any one of the K candidate physical machines, i is less than or equal to K, and i and K are both positive integers.

[0100] The processing unit 320 is used to input the performance parameters corresponding to the K candidate physical machines into the first model to obtain the first prediction result output by the first model. The first prediction result includes the predicted migration time corresponding to the K candidate physical machines. The predicted migration time of the i-th candidate physical machine refers to the predicted time for migrating the virtual machine in the first physical machine to the i-th candidate physical machine.

[0101] The processing unit 320 is further configured to determine a second physical machine based on the predicted migration time corresponding to each of the K candidate physical machines, wherein the second physical machine is the physical machine with the shortest predicted migration time among the K candidate physical machines.

[0102] The processing unit 320 is further configured to migrate the virtual machine in the first physical machine to the second physical machine.

[0103] In one possible design, the processing unit 320 is further configured to input the performance parameters corresponding to the K candidate physics machines into the first model, and obtain the first prediction result output by the first model, including:

[0104] The performance parameters corresponding to the K candidate physical machines and the performance parameters of the first physical machine are input into the first model to obtain the first prediction result. The performance parameters of the first physical machine include the response time of the first physical machine to the distributed lock command.

[0105] In one possible design, the performance parameters of the first physical machine may also include one or more of the following: CPU availability of the first physical machine, memory availability of the first physical machine, memory utilization rate of the first physical machine, load of the first physical machine, CPU utilization rate and memory utilization rate of the virtual machines in the first physical machine.

[0106] In one possible design, the processing unit 320 is further configured to input the performance parameters corresponding to the K candidate physics machines into the first model, and obtain the first prediction result output by the first model, including:

[0107] The performance parameters and network metrics corresponding to the K candidate physical machines are input into the first model to obtain the first prediction result. The network metrics include network latency and / or packet loss rate.

[0108] In one possible design, the first model is trained using a training dataset that includes the response times of historical source physical machines to distributed lock commands and the response times of historical target physical machines to distributed lock commands.

[0109] In one possible design, the response time of the historical source physical machine to a distributed lock command includes a first response time and a second response time; wherein, the first response time is the response time of the historical source physical machine to a distributed lock command of the shared activation type, and the second response time is the response time of the historical source physical machine to a distributed lock command of the deactivation type.

[0110] The response time of the historical target physical machine to the distributed lock command includes a third response time and a fourth response time; wherein, the third response time is the response time of the historical target physical machine to the distributed lock command of the shared activation type, and the fourth response time is the response time of the historical target physical machine to the distributed lock command of the exclusive activation type.

[0111] In one possible design, the training dataset further includes one or more of the following: CPU availability of the historical source physical machine, memory availability of the historical source physical machine, memory utilization rate of the historical source physical machine, load of the historical source physical machine, CPU utilization rate and memory utilization rate of virtual machines in the historical source physical machine, CPU availability of the historical target physical machine, memory availability of the historical target physical machine, memory utilization rate of the historical target physical machine, load of the historical target physical machine, historical network latency time and / or historical packet loss rate.

[0112] In one possible design, the response time of the i-th candidate physical machine to the distributed lock command is the same as the response time of the i-th candidate physical machine to the probe-type distributed lock command.

[0113] The response time of the first physical machine to the distributed lock command is the same as the response time of the first physical machine to the probe-type distributed lock command.

[0114] For a more detailed description of the communication unit 310 and the processing unit 320 mentioned above, please refer to [link / reference]. Figure 1 The relevant descriptions in the method embodiments shown are directly obtained and will not be repeated here.

[0115] like Figure 4 As shown, the virtual machine migration apparatus 400 includes a processor 410 and a communication interface 420. The processor 410 and the communication interface 420 are coupled together. It is understood that the communication interface 420 can be a transceiver or an input / output interface. Optionally, the virtual machine migration apparatus 400 may further include a memory 430 for storing instructions executed by the processor 410, or storing input data required by the processor 410 to execute instructions, or storing data generated after the processor 410 executes instructions.

[0116] When the virtual machine migration device 300 is used to implement Figure 1 In the method shown, the processor 410 is used to implement the functions of the processing unit 320, and the communication interface 420 is used to implement the functions of the communication unit 310.

[0117] The unit division in this embodiment is illustrative and represents only one logical functional division. In actual implementation, other division methods may be used. Furthermore, the functional units in the various embodiments of this application can be integrated into a single processor, exist as separate physical units, or be integrated into a single unit. The integrated units described above can be implemented in hardware or as software functional units.

[0118] Based on the same inventive concept, embodiments of this application provide a computer-readable storage medium. The computer program product includes computer program code, which, when executed on a computer, causes the computer to perform any of the virtual machine migration methods discussed above. Since the principle by which the above-described computer-readable storage medium solves the problem is similar to that of the virtual machine migration method, the implementation of the above-described computer-readable storage medium can be found in the implementation of the method; repeated details will not be elaborated further.

[0119] Based on the same inventive concept, this application also provides a computer program product, which includes computer program code. When the computer program code is run on a computer, it causes the computer to execute any of the virtual machine migration methods discussed above. Since the principle by which the above computer program product solves the problem is similar to that of the virtual machine migration method, the implementation of the above computer program product can be referred to the implementation of the method, and repeated details will not be described again.

[0120] Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application can take the form of a computer program product embodied on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0121] This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to this application. It should be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart illustrations. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0122] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0123] Obviously, those skilled in the art can make various modifications and variations to this application without departing from the spirit and scope of this application. Therefore, if such modifications and variations fall within the scope of the claims of this application and their equivalents, this application also intends to include such modifications and variations.

Claims

1. A virtual machine migration method, characterized in that, The method includes: Obtain the performance parameters corresponding to K candidate physical machines, wherein the performance parameters of the i-th candidate physical machine include the response time of the i-th candidate physical machine to a probe-type distributed lock command, and the i-th candidate physical machine is any one of the K candidate physical machines, i is less than or equal to K, and i and K are both positive integers; wherein the probe-type distributed lock command is used to test the response capability of the physical machine to execute the distributed lock command, and does not change the access status of the virtual machine's system volume and data volume; the distributed lock command includes the probe-type distributed lock command, and at least one of the following: The shared-activation type of distributed lock command is used to change the access state of the physical machine to the system volume and data volume of the virtual machine from exclusive activation state to shared activation state; The deactivation type of distributed lock command is used to change the access status of the physical machine to the system volume and data volume of the virtual machine from a shared active state to an inactive state; The exclusive activation type of distributed lock command is used to change the access state of the physical machine to the system volume and data volume of the virtual machine from the shared activation state to the exclusive activation state. The performance parameters corresponding to the K candidate physical machines are input into the first model to obtain the first prediction result output by the first model. The first prediction result includes the predicted migration time corresponding to the K candidate physical machines. The predicted migration time of the i-th candidate physical machine refers to the predicted time to migrate the virtual machine in the first physical machine to the i-th candidate physical machine. The second physical machine is determined based on the predicted migration time corresponding to the K candidate physical machines, and the second physical machine is the physical machine with the shortest predicted migration time among the K candidate physical machines; Migrate the virtual machines in the first physical machine to the second physical machine; The performance parameters corresponding to the K candidate physics machines are input into the first model to obtain the first prediction result output by the first model, including: The performance parameters corresponding to the K candidate physical machines and the performance parameters of the first physical machine are input into the first model to obtain the first prediction result. The performance parameters of the first physical machine include the response time of the first physical machine for the distributed lock command of the probe type.

2. The method as described in claim 1, characterized in that, The performance parameters of the i-th candidate physical machine also include one or more of the following: the amount of CPU available in the i-th candidate physical machine, the amount of memory available in the i-th candidate physical machine, the memory utilization rate of the i-th candidate physical machine, and the load of the i-th candidate physical machine.

3. The method as described in claim 1, characterized in that, The performance parameters of the first physical machine also include one or more of the following: CPU availability of the first physical machine, memory availability of the first physical machine, memory utilization rate of the first physical machine, load of the first physical machine, CPU utilization rate and memory utilization rate of the virtual machines in the first physical machine.

4. The method as described in claim 1, characterized in that, The performance parameters corresponding to the K candidate physics machines are input into the first model to obtain the first prediction result output by the first model, including: The performance parameters and network metrics corresponding to the K candidate physical machines are input into the first model to obtain the first prediction result. The network metrics include network latency and / or packet loss rate.

5. The method as described in claim 1, characterized in that, The first model is obtained by training a training dataset, which includes the response times of historical source physical machines to distributed lock commands and the response times of historical target physical machines to distributed lock commands.

6. The method as described in claim 5, characterized in that, The response time of the historical source physical machine to the distributed lock command includes a first response time and a second response time; wherein, the first response time is the response time of the historical source physical machine to the distributed lock command of the shared activation type, and the second response time is the response time of the historical source physical machine to the distributed lock command of the deactivation type. The response time of the historical target physical machine to the distributed lock command includes a third response time and a fourth response time; wherein, the third response time is the response time of the historical target physical machine to the distributed lock command of the shared activation type, and the fourth response time is the response time of the historical target physical machine to the distributed lock command of the exclusive activation type.

7. The method as described in claim 5, characterized in that, The training dataset also includes one or more of the following: CPU availability of the historical source physical machine, memory availability of the historical source physical machine, memory utilization rate of the historical source physical machine, load of the historical source physical machine, CPU utilization rate and memory utilization rate of virtual machines in the historical source physical machine, CPU availability of the historical target physical machine, memory availability of the historical target physical machine, memory utilization rate of the historical target physical machine, load of the historical target physical machine, historical network latency time and / or historical packet loss rate.

8. A virtual machine migration device, characterized in that, The device includes: a communication unit and a processing unit; The communication unit is used to acquire performance parameters corresponding to K candidate physical machines; wherein, the performance parameters of the i-th candidate physical machine include the response time of the i-th candidate physical machine to a probe-type distributed lock command, the i-th candidate physical machine is any one of the K candidate physical machines, i is less than or equal to K, and i and K are both positive integers; wherein, the probe-type distributed lock command is used to test the response capability of the physical machine to execute the distributed lock command, and does not change the access status of the virtual machine's system volume and data volume; the distributed lock command includes the probe-type distributed lock command, and at least one of the following: The shared-activation type of distributed lock command is used to change the access state of the physical machine to the system volume and data volume of the virtual machine from exclusive activation state to shared activation state; The deactivation type of distributed lock command is used to change the access status of the physical machine to the system volume and data volume of the virtual machine from a shared active state to an inactive state; The exclusive activation type of distributed lock command is used to change the access state of the physical machine to the system volume and data volume of the virtual machine from the shared activation state to the exclusive activation state. The processing unit is configured to input the performance parameters corresponding to the K candidate physical machines into a first model, obtain a first prediction result output by the first model, wherein the first prediction result includes the predicted migration time corresponding to the K candidate physical machines, wherein the predicted migration time of the i-th candidate physical machine refers to the predicted time for migrating virtual machines in the first physical machine to the i-th candidate physical machine; and determine a second physical machine based on the predicted migration time corresponding to the K candidate physical machines, wherein the second physical machine is the physical machine with the shortest predicted migration time among the K candidate physical machines; and migrate the virtual machines in the first physical machine to the second physical machine; The processing unit is further configured to input the performance parameters corresponding to the K candidate physical machines and the performance parameters of the first physical machine into the first model to obtain the first prediction result. The performance parameters of the first physical machine include the response time of the first physical machine to the distributed lock command of the probe type.

9. A virtual machine migration device, characterized in that, include: Memory, used to store program instructions; A processor is configured to invoke program instructions stored in the memory and execute the steps of the method according to any one of claims 1-7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program, the computer program including program instructions that, when executed by a computer, cause the computer to perform the method as described in any one of claims 1-7.

11. A computer program product, characterized in that, The computer program product includes: computer program code, which, when run on a computer, causes the computer to perform the method described in any one of claims 1-7.