Virtual machine migration method, device and storage medium

Abstract

Embodiments of the present application provide a virtual machine migration method, device and storage medium. When the virtual machine is hot migrated, the virtual machine can perceive the hot migration, suspend the use of the pass-through device, and migrate the task request on the pass-through device, so that the pass-through device enters an idle state before migration. Further, the pass-through device does not need to perform state recovery after being hot migrated to the destination device, and the pass-through device does not need to perform the suspension operation before being hot migrated. Based on this implementation, on the one hand, based on the migration operation of the task request, the influence of the hot migration operation on the task processing progress is reduced, so that the hot migration is not perceived by the user; on the other hand, the hot migration operation of the pass-through device is realized without relying on the suspension function at the hardware level, the limitation of the type of the pass-through device on the virtual machine hot migration is reduced, and the flexibility of the virtual machine hot migration is improved.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a virtual machine migration method, device and storage medium. Background Technology

[0002] A virtual machine (VM) is a complete computer system simulated by software, possessing full hardware system functionality and running in a completely isolated environment. Live migration of a VM, also known as dynamic migration or real-time migration, is essentially VM save / restore. During live migration, the VM's running state is typically saved completely and quickly restored to its original hardware platform or a different hardware platform. The restored VM can then run smoothly. Live migration of passthrough devices is a crucial part of the VM live migration process. In a seamless VM live migration process, the passthrough device must support hardware-level pause. However, for some passthrough devices that do not support hardware-level pause, live migration of the passthrough device cannot be completed. Therefore, a new solution is needed. Summary of the Invention

[0003] This application provides a virtual machine migration method, device, and storage medium to reduce the requirements of virtual machine hot migration operations on pass-through devices and realize hot migration on any pass-through device.

[0004] This application provides a virtual machine migration method, including: a first physical machine responding to a hot migration command and determining a first virtual machine to be migrated; setting the driving state of the first virtual machine to a first pass-through device on the first physical machine to a paused state; migrating the task request migration on the first pass-through device to control the first pass-through device to enter an idle state; pausing the first virtual machine and migrating the state data of the first virtual machine to a second physical machine, so that the second physical machine runs a second virtual machine according to the state data of the first virtual machine and sets the driving state of the second virtual machine to a second pass-through device on the second physical machine to a continue state.

[0005] Optionally, migrating the task request on the first passthrough device to the target object for processing includes: the hardware driver component initiating a virtual interrupt to the first virtual machine; and using the first virtual machine to migrate the task request on the first passthrough device to the target object for processing.

[0006] Optionally, migrating task requests from the first pass-through device includes: obtaining at least one task request to be processed on the first pass-through device; determining the software processing module adapted to each of the at least one task request; any software processing module being located on the first physical device or on a remote device; and migrating the at least one task request to its respective adapted software processing module for processing.

[0007] Optionally, obtaining at least one task request to be processed by the first pass-through device includes: obtaining a task request that the first pass-through device has received but not yet processed from the task queue of the first pass-through device; and / or, intercepting a task request issued by the first virtual machine with the first pass-through device as the destination device.

[0008] Optionally, determining the software processing module adapted to each of the at least one task request includes: determining the software processing module adapted to each of the at least one task request based on the calculation type of each of the at least one task request; or, determining the software processing module adapted to each of the at least one task request based on the type of pass-through device corresponding to each of the at least one task request.

[0009] This application also provides a virtual machine migration method, including: receiving a hot migration instruction for a first virtual machine; obtaining status data of the first virtual machine; the first virtual machine being migrated out of a first physical machine using the migration method provided in this application; running a second virtual machine on a second physical machine based on the status data of the first virtual machine; setting the drive status of the second virtual machine to a second pass-through device on the second physical machine to a continue state, so as to use the second pass-through device to execute the task request of the second virtual machine.

[0010] Optionally, before running the second virtual machine on the second physical machine, based on the status data of the first virtual machine, the method further includes: obtaining configuration data of the first virtual machine; the configuration data includes at least one of: configuration data of the pass-through device, driver configuration data, and environment configuration data; and allocating resources on the second physical machine according to the configuration data to create the runtime environment of the second virtual machine.

[0011] This application embodiment also provides a virtual machine migration system, including: a first physical machine and a second physical machine; wherein, the first physical machine is configured to respond to a hot migration command, determine a first virtual machine to be migrated; set the driving state of the first virtual machine to a first pass-through device on the first physical machine to a paused state; migrate task requests on the first pass-through device to control the first pass-through device to enter an idle state; pause the first virtual machine and migrate the state data of the first virtual machine to the second physical machine; the second physical machine is configured to receive the hot migration command of the first virtual machine; acquire the state data of the first virtual machine and run a second virtual machine on the second physical machine according to the state data of the first virtual machine; and set the driving state of the second virtual machine to a second pass-through device on the second physical machine to a continued state to execute the task requests of the second virtual machine using the second pass-through device.

[0012] This application also provides an electronic device, including: a memory and a processor; the memory is used to store one or more computer instructions; the processor is used to execute the one or more computer instructions to perform the steps in the method provided in this application.

[0013] This application also provides a computer-readable storage medium storing a computer program, which, when executed by a processor, can implement the steps in the method provided in this application.

[0014] In the virtual machine migration method provided in this application embodiment, during virtual machine hot migration, the virtual machine can sense the hot migration, suspend the use of the passthrough device, and migrate the task requests on the passthrough device, so that the passthrough device enters an idle state before migration. Furthermore, no state restoration is required after the passthrough device is hot-migrated to the destination device, and no pause operation is required before the hot migration. Based on this implementation, on the one hand, the migration operation based on task requests reduces the impact of hot migration on task processing progress, making the hot migration imperceptible to the user; on the other hand, it realizes a passthrough device hot migration operation that does not rely on hardware-level pause functionality, reducing the restrictions of the passthrough device type on virtual machine hot migration and improving the flexibility of virtual machine hot migration. Attached Figure Description

[0015] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments and are used to explain this application, but do not constitute an undue limitation of this application. In the drawings:

[0016] Figure 1 A flowchart illustrating a virtual machine migration method provided as an exemplary embodiment of this application;

[0017] Figure 2 A flowchart illustrating a virtual machine migration method provided as another exemplary embodiment of this application;

[0018] Figure 3a A schematic diagram of the structure of a virtual machine migration system provided in an exemplary embodiment of this application;

[0019] Figure 3b A schematic diagram of a virtual machine hot migration process is provided as another exemplary embodiment of this application;

[0020] Figure 4 A timing diagram of cross-device signaling interaction during virtual machine hot migration provided as an exemplary embodiment of this application;

[0021] Figure 5 A schematic diagram of the structure of an electronic device provided for an exemplary embodiment of this application. Detailed Implementation

[0022] To make the objectives, technical solutions, and advantages of this application clearer, the technical solutions of this application will be clearly and completely described below in conjunction with specific embodiments and corresponding drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of them. Based on the embodiments in this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0023] The terminology used in the embodiments of this invention is for the purpose of describing particular embodiments only and is not intended to limit the invention. The singular forms “a,” “the,” and “the” used in the embodiments of this invention and the appended claims are also intended to include the plural forms, unless the context clearly indicates otherwise. “Multiple” generally includes at least two, but does not exclude the inclusion of at least one.

[0024] It should be understood that the term "and / or" used in this article is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, and B existing alone. Additionally, the character " / " in this article generally indicates that the preceding and following related objects have an "or" relationship.

[0025] It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a product or system comprising a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a product or system. Without further limitation, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the product or system that includes said element.

[0026] In view of the technical problem that some hardware devices in the prior art do not support hardware-level pause, thus making it impossible to achieve virtual machine hot migration, this application provides a solution in some embodiments. The technical solutions provided by the embodiments of this application are described in detail below with reference to the accompanying drawings. Figure 1 This is a flowchart illustrating a virtual machine migration method provided in an exemplary embodiment of this application. When executed on the first physical machine side, the method may include, for example: Figure 1 The steps shown are as follows:

[0027] Step 101: The first physical machine responds to the hot migration command and determines the first virtual machine to be migrated.

[0028] Step 102: Set the driver status of the first virtual machine for the first pass-through device on the first physical machine to a paused state.

[0029] Step 103: Migrate the task requests on the first through device to control the first through device to enter an idle state.

[0030] Step 103: Pause the first virtual machine and migrate the state data of the first virtual machine to the second physical machine, so that the second physical machine runs the second virtual machine according to the state data of the first virtual machine and sets the drive state of the second virtual machine to the second pass-through device on the second physical machine to the continue state.

[0031] In this embodiment, for ease of description and distinction, the original host machine where the virtual machine resides before hot migration is described as the first physical machine, and the destination host machine where the virtual machine resides after hot migration is described as the second physical machine. The execution entity in this embodiment can be the first physical machine, which can be any server device running a virtual machine. In a local hot migration scenario of a virtual machine, the first physical machine and the second physical machine can be the same physical machine. In a cross-device migration scenario of a virtual machine, the first physical machine and the second physical machine can be different physical machines; this embodiment does not impose any restrictions.

[0032] The first physical machine runs a Virtual Machine Monitor (VMM), which is virtualization software used to perform operations such as creating, migrating, powering on, and powering off virtual machines. The VMM can initiate hot migration of virtual machines under specific event triggers. For example, when the first physical machine is upgraded, the VMM can hot migrate virtual machines from the first physical machine to the second physical machine. Similarly, if the first physical machine fails, the VMM can hot migrate virtual machines from the first physical machine to the second physical machine. Furthermore, the VMM can hot migrate virtual machines from the first physical machine to the second physical machine under user intervention.

[0033] In this embodiment, to distinguish between the virtual machine before migration and the virtual machine after migration, a first virtual machine is used to describe any virtual machine to be migrated on the first physical machine, and a second virtual machine is used to describe the virtual machine corresponding to the first virtual machine migrated to the second physical machine. That is, the second virtual machine is obtained by hot migration of the first virtual machine.

[0034] Upon receiving a live migration command, the virtual machine manager on the first physical machine can identify the first virtual machine to be migrated and initiate live migration preparation operations. When initiating live migration preparation operations for the first virtual machine, the virtual machine manager can send a live migration message to the first virtual machine so that the first virtual machine is aware of the live migration process.

[0035] The first pass-through device is the pass-through device of the first virtual machine on the first physical machine. A pass-through device refers to a physical device directly exposed to the virtual machine and operable directly by the virtual machine. After receiving the hot migration message, the first virtual machine can set its driver status for the first pass-through device to a paused state. The driver status describes the virtual machine's driver behavior for the first pass-through device, which includes pausing or resuming the driver. This driver status setting operation causes the first virtual machine to record the driver status for the first pass-through device and pause its use of the device, but the first pass-through device itself does not need to be paused.

[0036] After marking the driver state of the first passthrough device as paused, the first virtual machine ceases to use the first passthrough device and migrates task requests on the first passthrough device to meet task processing requirements. Based on the task migration operation, the first passthrough device can enter an idle state before hot migration. In the idle state, the first passthrough device is not paused and does not generate new state data. When the first passthrough device is hot migrated in the idle state, there is no need to migrate state data, and there is no need to perform state restoration operations on the migrated passthrough device on the second physical machine. Therefore, during hot migration, there is no need for hardware-level pause and restore of the passthrough device, meeting the migration requirements of different types of passthrough devices.

[0037] In this context, passthrough devices on the physical machine achieve passthrough to the virtual machine through a passthrough framework. For example, this passthrough framework could be VFIO (Virtual Function IO, a user-mode driver framework). This VFIO framework allows user-mode programs to manipulate data transmission independently and register interrupt handlers to implement device drivers in user mode.

[0038] In some optional embodiments, the virtual machine manager can send a hot migration message to the first virtual machine through the hardware driver component provided by the passthrough framework. Upon receiving the hot migration message, the hardware driver component can notify the first virtual machine to initiate hot migration preparation. The hardware driver component can register a virtual interrupt based on a mechanism that allows it to register its own interrupt handler function, and then send the hot migration message to the first virtual machine through the virtual interrupt. After receiving the virtual interrupt, the first virtual machine can migrate task requests from the first passthrough device to the target object for processing within the virtual interrupt, thereby controlling the passthrough device to enter an idle state.

[0039] When migrating task requests from the first direct-connect device, the first virtual machine can migrate the task requests from the first direct-connect device to the target object for processing. The target object can be a local processing object on the first physical machine or a remote processing object. For example, the target object can be located on another physical machine or on a cloud server; this embodiment does not impose any limitations.

[0040] The first virtual machine can use a fallback mechanism to roll back the task request from the first direct-access device to the target object, thereby completing the task request migration operation.

[0041] When the first virtual machine performs a task request migration operation, it can obtain at least one task request pending processing by the first direct-connect device from the task requests of the first direct-connect device. That is, the obtained at least one task request has not yet been processed by the first direct-connect device.

[0042] Optionally, the at least one task request to be processed may include task requests already sent to the first direct-connect device. Optionally, the at least one task request to be processed may also include task requests that still need to be executed by the first direct-connect device after its driver state is set to a paused state. That is, the first virtual machine can retrieve task requests that the first direct-connect device has received but not yet processed from its task queue; and / or, the first virtual machine can intercept task requests sent with the first direct-connect device as the destination device. This allows the first direct-connect device to stop issuing new task requests. Once the task requests in progress on the first direct-connect device are completed, the task requests on the first direct-connect device will be cleared, allowing the first direct-connect device to enter an idle state.

[0043] Optionally, the target object can be a software processing object or a hardware processing object; this embodiment does not impose any limitations. If it is a hardware processing object, it can be a hardware device connected to the first physical machine that is not directly accessible by the first virtual machine. If it is a software processing object, it can be implemented as a software module running locally or remotely on the first physical machine.

[0044] In some optional embodiments, after acquiring at least one task request to be processed, the first virtual machine can determine the software processing module adapted to each of the at least one task request, and migrate the at least one task request to the respective adapted software processing module for processing. Each software processing module can be located on the first physical device or on a remote device. For example, after the first virtual machine acquires the first task request, the second task request, and the third task request from the first direct-access device, it can migrate the first task request to the first software module on the first physical machine for processing; it can migrate the second task request to the second software module on the first physical machine for processing; and it can migrate the third task request to the third software module on the cloud server for processing.

[0045] In some optional embodiments, when determining the appropriate software processing module for each of the at least one task request, the first virtual machine can determine the appropriate software processing module based on the computation type of each of the at least one task request. That is, the first virtual machine can transfer different task requests to different types of software modules for processing according to the type of the task request. For example, if the type of the first task request is a network processing task, the first virtual machine can migrate the first task request to the virtual network card module on the first physical machine for processing; if the type of the second task request is a write data type, the first virtual machine can migrate the second task request to the software data queue in memory on the first physical machine for processing.

[0046] In some alternative embodiments, when the first virtual machine determines the software processing module adapted to each of the at least one task request, it can determine the software processing module adapted to each of the at least one task request based on the type of pass-through device corresponding to each of the at least one task request. The type of pass-through device can be classified according to its function or according to the protocol it follows. For example, when classified by function, the type of pass-through device may include, but is not limited to: network type, computing type, storage type, and display type. As another example, when classified by protocol, pass-through devices following a first protocol can be classified into the same type of device, and pass-through devices following a second protocol can be classified into the same type of device; this embodiment does not impose any limitations. For example, the first protocol may be the Peripheral Component Interconnect (PCI) protocol, and the second protocol may be the Peripheral Component Interconnect Express (PCI-E) protocol.

[0047] For example, if the passthrough device corresponding to the first task request is a network card, the first virtual machine can migrate the first task request to a network-type software module on the first physical machine for processing; if the passthrough device corresponding to the second task request is a graphics card, the first virtual machine can migrate the second task request to a display-type software module on the first physical machine for processing.

[0048] In this implementation, by migrating the task request of the first pass-through device to the target object, on the one hand, the impact of the hot migration operation on the task processing progress is reduced, making the hot migration process imperceptible to the user; on the other hand, the migration of the pass-through device can be completed even if the first pass-through device does not support hardware-level pause, reducing the dependence of hot migration on hardware type.

[0049] Once the first connected device enters an idle state, a hot migration operation for the first virtual machine can be performed. Before the first virtual machine is paused, a migration operation for existing state data can be performed to migrate most of the state data of the first virtual machine to the second physical machine. After the first virtual machine is paused, incremental state data generated before the pause can be migrated to the second physical machine to synchronize the state data of the first virtual machine between the first and second physical machines. Specifically, the state data of the first virtual machine is stored in the memory of the first physical machine, and the memory of the first virtual machine on the first physical machine can be copied to the second physical machine to achieve the migration of state data.

[0050] In this system, the first physical machine can utilize a virtual machine manager to perform state data migration operations. In some optional embodiments, after the first virtual machine determines that the first passthrough device has entered an idle state, it can notify the hardware driver component in the passthrough framework that it has completed the pre-migration preparations. For example, the first virtual machine can send a migration preparation completion notification message to the hardware driver component by writing to a register (e.g., the communication register of the hardware driver component). The hardware driver component can then send the migration preparation completion message back to the virtual machine manager. For example, the hardware driver component can send the migration preparation completion message to the virtual machine manager through the interface between kernel mode and user mode.

[0051] After receiving the migration preparation completion message, the virtual machine manager can begin migrating the memory of the first virtual machine. Once the proportion of memory migrated to the second physical machine exceeds a certain set threshold (e.g., 80% or 90%), the virtual machine is suspended. After the virtual machine is suspended, the first physical machine can continue migrating the remaining memory from the first virtual machine to the second physical machine. This allows the second physical machine to synchronize its state data with the first virtual machine and run the migrated second virtual machine based on that state data.

[0052] In this embodiment, during virtual machine hot migration, the virtual machine is aware of the hot migration, suspends its use of the passthrough device, and migrates the task requests on the passthrough device, so that the passthrough device enters an idle state before migration. Therefore, no state restoration is required after the passthrough device is hot-migrated to the destination device, and no pause operation is required before the hot migration. Based on this implementation, on the one hand, the migration operation based on task requests reduces the impact of hot migration on task processing progress, making the hot migration imperceptible to the user; on the other hand, it realizes hot migration operation of passthrough devices without relying on hardware-level pause functions, reducing the restrictions of the type of passthrough device on virtual machine hot migration and improving the flexibility of virtual machine hot migration.

[0053] It is worth noting that, in some optional embodiments, the first physical machine can identify the type of pass-through device and perform different migration operations for different types of pass-through devices. Before the hot migration begins, the first physical machine can use the first virtual machine to determine whether the first pass-through device supports hardware-level pause operations. For example, the first physical machine can pre-store the correspondence between the identifier of the pass-through device and the pause type, and determine whether the pass-through device to be migrated supports hardware-level pause operations based on this correspondence. If the pass-through device does not support hardware-level pause, the hot migration method described in the foregoing embodiments can be executed.

[0054] If the first passthrough device supports hardware-level pause operations, upon receiving a hot migration command, the first virtual machine can pause both the first passthrough device and itself, and save the hardware state data of the first passthrough device to its physical memory. During the hot migration, the virtual machine manager on the first physical machine can migrate the state data of the first virtual machine to the second physical machine, enabling the second physical machine to run the second virtual machine based on the state data of the first virtual machine. The first hardware driver component on the first physical machine can migrate the physical memory of the first passthrough device to the second physical machine, enabling the second physical machine to run the second passthrough device of the second virtual machine based on the hardware state data. The resumed second virtual machine can process task requests through the second passthrough device.

[0055] That is, in this implementation, the first virtual machine can identify the type of the first direct-access device and adaptively select different device hot migration methods according to the type of the first direct-access device, making the hot migration operation of the direct-access device more flexible.

[0056] This application also provides a virtual machine migration method, which can be executed by the destination device for virtual machine hot migration. For ease of description, the original device for virtual machine hot migration is described as a first physical machine, and the destination device is described as a second physical machine. The following will combine... Figure 2 An example is provided.

[0057] Figure 2 This is a schematic flowchart illustrating the execution of a virtual machine migration method provided in an exemplary embodiment of this application on the second physical machine side, as shown below. Figure 2 As shown, the method may include:

[0058] Step 201: Receive the hot migration command for the first virtual machine.

[0059] Step 202: Obtain the status data of the first virtual machine; the first virtual machine migrates the task request from the first direct communication device to the target object for processing and then removes it from the first physical machine.

[0060] Step 203: Based on the status data of the first virtual machine, run the second virtual machine on the second physical machine.

[0061] Step 204: Set the driver state of the second virtual machine to the second pass-through device on the second physical machine to the continue state, so as to use the second pass-through device to execute the task request of the second virtual machine.

[0062] The migration method for the first virtual machine can be referred to the description in the aforementioned embodiments, and will not be repeated here.

[0063] After the hot migration preparation is completed on the first physical machine, the virtual machine manager on the first physical machine can send a start migration command to the second physical machine. Upon receiving the start migration command, the second physical machine can start the second virtual machine. The virtual machine manager on the second physical machine can obtain the status data of the first virtual machine sent by the first physical machine, and run the second virtual machine according to the received status data, so that the second virtual machine can restore the running state of the first virtual machine, thereby providing the services corresponding to the first virtual machine.

[0064] The restored second virtual machine continues to run in the same state as the first virtual machine. The state data of the first virtual machine includes its driver state for the first passthrough device. Before the migration, the first virtual machine's driver state for the first passthrough device was paused; therefore, after the migration, the second virtual machine needs to restore its driver state for the passthrough device. After the virtual machine manager on the second physical machine completes the hot migration of the virtual machines, the hardware driver component on the second physical machine can notify the second virtual machine to restore the passthrough device. This hardware driver component can register a virtual interrupt based on a mechanism that allows it to register its own interrupt handler function, and send a notification message to the second virtual machine to restore the passthrough device via the virtual interrupt. After receiving the virtual interrupt, the second virtual machine can set its driver state for the second passthrough device to continue and send subsequent task requests to the second passthrough device for processing.

[0065] Optionally, before running the second virtual machine on the second physical machine based on the status data of the first physical machine, the second physical machine may also obtain the configuration data of the first virtual machine. The configuration data includes at least one of the following: configuration data of the pass-through device, driver configuration data, and environment configuration data. The configuration data of the pass-through device may include at least one of the following: the type, quantity, and communication protocol of the pass-through device. The driver configuration data may include at least one of the following: driver configuration data of the first virtual machine and driver configuration data of the first pass-through device. The environment configuration data may include data related to the external operating environment required to run the first virtual machine, such as memory, processor, and network. The virtual machine manager on the second physical machine can allocate resources on the second physical machine according to the configuration data to create the operating environment for the second virtual machine.

[0066] In this implementation, before virtual machine migration, the use of the passthrough device is paused, and task requests on the passthrough device are migrated. This eliminates the need for a pause operation before hot migration of the passthrough device and eliminates the need for state restoration after hot migration to the destination device. After the virtual machine hot migration is complete, the virtual machine on the destination physical machine can detect the completion of the hot migration and can actively resume the use of the passthrough device. Therefore, on the one hand, the migration operation based on task requests reduces the impact of hot migration on task processing progress, making the hot migration imperceptible to the user; on the other hand, it achieves hot migration operation of the passthrough device without relying on hardware-level pause functionality, reducing the restrictions of the passthrough device type on virtual machine hot migration and improving the flexibility of virtual machine hot migration.

[0067] In addition to the foregoing embodiments, this application also provides a virtual machine migration system, as shown in Figure 3. The virtual machine migration system 300 includes multiple physical machines, which may be located in the same data center or different data centers. This embodiment does not impose any restrictions. Figure 3a The illustration uses the first physical machine 301 and the second physical machine 302 as examples, but this illustration does not limit the number of physical machines included in the virtual machine migration system 300.

[0068] The first physical machine 301 is the original host machine where the virtual machine was located before the hot migration. The first physical machine 301 provides a first pass-through device for the first virtual machine to use. The first physical machine 301 is mainly used for: responding to the hot migration command and identifying the first virtual machine to be migrated; setting the driver status of the first virtual machine on the first physical machine to a paused state; migrating away task requests on the first pass-through device to control the first pass-through device to enter an idle state; pausing the first virtual machine and migrating the state data of the first virtual machine to the second physical machine.

[0069] The second physical machine 302 is the destination host machine where the virtual machine resides after hot migration. The second physical machine 302 provides a second passthrough device. The second passthrough device is of the same type as the first passthrough device and is used to replace the first passthrough device. The second physical machine 302 is mainly used to receive the hot migration instruction of the first virtual machine; obtain the status data of the first virtual machine and run the second virtual machine on the second physical machine according to the status data of the first virtual machine; and set the driver status of the second virtual machine on the second physical machine to the continued state, so as to execute the task request of the second virtual machine using the second passthrough device. The specific operations of the first physical machine 301 and the second physical machine 302 when performing virtual machine migration can be referred to the description in the foregoing embodiments, and will not be repeated here.

[0070] In the virtual machine migration system 300, the virtual machine is aware of hot migration. The virtual machine's driver state for the passthrough device is set to a paused state to suspend its use of the passthrough device, and task requests on the passthrough device are migrated, allowing the passthrough device to enter an idle state before migration. Therefore, no state restoration is required after the passthrough device is hot-migrated to the destination device, and no pause operation is needed before the hot migration. Based on this implementation, on the one hand, the migration operation based on task requests reduces the impact of hot migration on task processing progress, making the hot migration imperceptible to the user; on the other hand, it achieves hot migration operation for passthrough devices without relying on hardware-level pause functionality, reducing the restrictions of the passthrough device type on virtual machine hot migration and improving the flexibility of virtual machine hot migration.

[0071] The virtual machine migration method provided in this application will be further illustrated below with reference to the accompanying drawings.

[0072] Figure 3b This is a schematic diagram of the virtual machine hot migration process. (Example) Figure 3b As shown, in some optional embodiments, hot migration of a virtual machine may include the following stages:

[0073] The virtual machine runs on the first physical machine. In the first phase, the first physical machine can transfer the virtual machine's configuration and device information to the second physical machine. Resource initialization can be performed on the second physical machine to prepare for receiving the virtual machine to be migrated. This resource initialization operation is used to initialize and configure one or more resources required for the virtual machine to run, including but not limited to at least one of the following: encryption / decryption device resources, CPU resources, memory resources, disk resources, and network resources.

[0074] In the first phase, when the virtual machine manager initiates the hot migration, the first physical machine's virtual machine is still running. At this time, the first hardware driver component on the first physical machine can notify the first physical machine's virtual machine to begin the hot migration via a virtual interrupt. For example... Figure 4 As shown, after receiving an interrupt, the virtual machine marks the current hardware state of the passthrough device as a migration state and sets the task requests for the passthrough device to be rolled back to software execution. The virtual machine can wait for the ongoing task requests from the passthrough device to complete processing and transfer any unprocessed task requests in the hardware queue of the passthrough device to software execution until the task requests in the passthrough device's queue are cleared. When the passthrough device is in an idle state, the first hardware driver component can send a rollback completion message to the first physical machine through the communication register between the first physical machine and the virtual machine. The first hardware driver component can then return a migration preparation completion message to the virtual machine manager, allowing the virtual machine manager to proceed to the next stage.

[0075] In the second stage (i.e., the Pre-copy, dirty page copying stage), the virtual machine continues to run on the first physical machine, and the memory of the virtual machine in the first physical machine can be copied to the second physical machine.

[0076] At the beginning of a hot migration, the virtual machine manager can mark all memory pages of the virtual machine as dirty pages, awaiting migration. During the memory migration process, the virtual machine manager can iteratively scan the virtual machine's memory and copy and migrate the memory pages marked as dirty. If a memory page is modified by a process after migration, it is considered updated, and the virtual machine manager can continue to mark the memory page as dirty, migrating it to the second physical machine in the next iteration of copying. Based on this implementation, modifications to the virtual machine's memory can be tracked, thereby ensuring that the memory state of the virtual machine on the second physical machine is the same as the memory state of the virtual machine on the first physical machine.

[0077] In the second phase, if the virtual machine's passthrough device supports hardware-level pause, the first hardware driver component in the passthrough framework can migrate the physical memory of the passthrough device to the second physical machine. The physical memory of the passthrough device stores its status code, which can be used to restore the passthrough device's running state on the second physical machine based on the status code when the passthrough device supports hardware-level pause. If the virtual machine's passthrough device does not support hardware-level pause, the migration of the passthrough device's physical memory is unnecessary.

[0078] In the third phase, the virtual machine manager puts the virtual machine into a paused state and migrates the remaining memory. Before being paused, the virtual machine continued to run on the first physical machine, and user access was still ongoing; therefore, some updated memory was not migrated. After pausing the virtual machine in the third phase, the updated memory can be migrated.

[0079] like Figure 3bAs shown, in the third stage, if the passthrough device supports hardware-level pause operations, the first physical machine can save the first hardware driver components and the relevant state of the passthrough device to the physical memory of the passthrough device. The virtual machine manager can then migrate the physical memory of the passthrough device to the second physical machine.

[0080] In the fourth stage, the virtual machine's state synchronization is complete, at which point the virtual machine manager can release the virtual machine's resources on the first physical machine.

[0081] In the fifth phase, the second physical machine resumes running virtual machines. During this phase, the virtual machine manager can start virtual machines on the second physical machine and, based on the migrated virtual machines' memory, restore them from a suspended state to a running state. On the second physical machine, the virtual machine's driver behavior is consistent with that of the virtual machines on the first physical machine, indicating a rollback state.

[0082] In the sixth phase, the second physical machine synchronizes the passthrough device. The second hardware driver component on the second physical machine can send a migration complete message to the virtual machine via a virtual interrupt. The virtual machine can mark the passthrough device's state as ready and send a task request to the passthrough device to resume its use. If the passthrough device supports hardware-level pause, the virtual machine manager can notify the device driver component on the second physical machine to restore the passthrough device's state based on the physical memory of the passthrough device migrated from the third phase, ensuring hardware consistency.

[0083] It should be noted that the execution subject of each step of the method provided in the above embodiments can be the same device, or the method can be executed by different devices. For example, the execution subject of steps 101 to 104 can be device A; or the execution subject of steps 101 and 102 can be device A, and the execution subject of step 103 can be device B; and so on.

[0084] Furthermore, some processes described in the above embodiments and accompanying drawings include multiple operations appearing in a specific order. However, it should be clearly understood that these operations may not be executed in the order they appear herein, or they may be executed in parallel. The operation numbers, such as 101, 102, etc., are merely used to distinguish different operations and do not represent any execution order. Additionally, these processes may include more or fewer operations, and these operations may be executed sequentially or in parallel. It should be noted that the descriptions such as "first" and "second" in this document are used to distinguish different messages, devices, modules, etc., and do not represent a sequential order, nor do they limit "first" and "second" to different types.

[0085] Figure 5 This application illustrates a schematic diagram of the structure of an electronic device provided in an exemplary embodiment, as shown below. Figure 5 As shown, the electronic device includes: a memory 501, a processor 502, and a communication component 503.

[0086] Memory 501 is used to store computer programs and can be configured to store various other data to support operation on the electronic device. Examples of this data include instructions for any application or method used to operate on the electronic device.

[0087] In some embodiments, the electronic device is implemented as the original host machine in a virtual machine hot migration scenario. Processor 502, coupled to memory 501, is used to execute a computer program in memory 501 for: responding to a hot migration instruction on a first physical machine and determining a first virtual machine to be migrated; setting the drive state of the first virtual machine on a first pass-through device on the first physical machine to a paused state; migrating away task requests on the first pass-through device to control the first pass-through device to enter an idle state; pausing the first virtual machine and migrating the state data of the first virtual machine to a second physical machine, so that the second physical machine runs a second virtual machine on the second physical machine according to the state data of the first virtual machine and sets the drive state of the second virtual machine on a second pass-through device to a continue state.

[0088] Optionally, when the processor 502 migrates the task request from the first passthrough device to the target object for processing, it specifically performs the following: the hardware driver component initiates a virtual interrupt to the first virtual machine using the hardware driver component; and uses the first virtual machine to migrate the task request from the first passthrough device to the target object for processing.

[0089] Optionally, when the processor 502 migrates a task request from the first pass-through device, it is specifically configured to: obtain at least one task request to be processed by the first pass-through device; determine the software processing module adapted to each of the at least one task request; any software processing module is located on the first physical device or on a remote device; and migrate the at least one task request to its respective adapted software processing module for processing.

[0090] Optionally, when the processor 502 obtains at least one task request to be processed by the first pass-through device, it is specifically configured to: obtain a task request that the first pass-through device has received but has not yet processed from the task queue of the first pass-through device; and / or, intercept a task request issued by the first virtual machine with the first pass-through device as the destination device.

[0091] Optionally, when determining the software processing module adapted to each of the at least one task request, the processor 502 is specifically configured to: determine the software processing module adapted to each of the at least one task request based on the computing type of each of the at least one task request; or, determine the software processing module adapted to each of the at least one task request based on the type of pass-through device corresponding to each of the at least one task request.

[0092] Optionally, the processor 502 is further configured to: if the first pass-through device supports hardware-level pause operations, pause the first pass-through device and the first virtual machine, and save the hardware status data of the first pass-through device to the physical memory of the first pass-through device; migrate the status data of the first virtual machine and the physical memory of the first pass-through device to the second physical machine, so that the second physical machine runs the second virtual machine according to the status data of the first virtual machine and runs the second pass-through device according to the hardware status data.

[0093] In some embodiments, the electronic device is implemented as a destination host in a virtual machine hot migration scenario. Processor 502, coupled to memory 501, is used to execute a computer program in memory 501 for: receiving a hot migration instruction for a first virtual machine; acquiring state data of the first virtual machine; moving the first virtual machine from a first physical machine (i.e., the original host machine) using the migration method provided in the foregoing embodiments; running a second virtual machine on a second physical machine (i.e., the destination host machine) based on the state data of the first virtual machine; setting the drive state of the second virtual machine to a second passthrough device on the second physical machine to a continue state, so as to utilize the second passthrough device to execute the task request of the second virtual machine.

[0094] Optionally, before running the second virtual machine on the second physical machine based on the status data of the first virtual machine, the processor 502 is further configured to: obtain configuration data of the first virtual machine; the configuration data includes at least one of: configuration data of the pass-through device, driver configuration data, and environment configuration data; and allocate resources on the second physical machine based on the configuration data to create the runtime environment of the second virtual machine.

[0095] Furthermore, such as Figure 5 As shown, the electronic device also includes other components such as a power supply component 504. Figure 5 The diagram only shows some components and does not mean that the electronic device includes only these components. Figure 5 The components shown.

[0096] The memory 501 can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic storage, flash memory, magnetic disk or optical disk.

[0097] The communication component 503 is configured to facilitate wired or wireless communication between the device containing the communication component and other devices. The device containing the communication component can access wireless networks based on communication standards, such as WiFi, 2G, 3G, 4G, or 5G, or combinations thereof. In one exemplary embodiment, the communication component receives broadcast signals or broadcast-related information from an external broadcast management system via a broadcast channel. In one exemplary embodiment, the communication component may be implemented based on Near Field Communication (NFC), Radio Frequency Identification (RFID), Infrared Data Association (IrDA), Ultra Wideband (UWB), Bluetooth (BT), and other technologies.

[0098] The power supply component 504 is used to provide power to various components of the device in which it resides. The power supply component may include a power management system, one or more power supplies, and other components associated with generating, managing, and distributing power to the device in which it resides.

[0099] In this embodiment, during virtual machine hot migration, the virtual machine is aware of the hot migration, sets the virtual machine's driver state for the passthrough device to a paused state to suspend the virtual machine's use of the passthrough device, and migrates the task requests on the passthrough device so that the passthrough device enters an idle state before migration. Therefore, no state restoration is required after the passthrough device is hot-migrated to the destination device, and no pause operation is required before the hot migration. Based on this implementation, on the one hand, the migration operation based on task requests reduces the impact of hot migration on task processing progress, making the hot migration imperceptible to the user; on the other hand, it realizes a passthrough device hot migration operation that does not rely on hardware-level pause functionality, reducing the restrictions of the passthrough device type on virtual machine hot migration and improving the flexibility of virtual machine hot migration.

[0100] Accordingly, embodiments of this application also provide a computer-readable storage medium storing a computer program, which, when executed, can implement the steps that can be executed by the server in the above method embodiments.

[0101] Those skilled in the art will understand that embodiments of the present invention can be provided as methods, systems, or computer program products. Therefore, the present invention can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the present invention 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.

[0102] This invention is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will 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 and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0103] 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.

[0104] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0105] In a typical configuration, a computing device includes one or more processors (CPU), input / output interfaces, network interfaces, and memory.

[0106] Memory may include non-persistent storage in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.

[0107] Computer-readable media includes both permanent and non-permanent, removable and non-removable media that can store information using any method or technology. Information can be computer-readable instructions, data structures, modules of programs, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, disk storage or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transient computer-readable media, such as modulated data signals and carrier waves.

[0108] It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0109] The above description is merely an embodiment of this application and is not intended to limit the scope of this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of the claims of this application.

Claims

1. A virtual machine migration method, characterized in that, include: The first physical machine responds to the live migration command and determines the first virtual machine to be migrated; Set the first virtual machine's drive status for the first pass-through device on the first physical machine to a paused state; The hardware driver component notifies the first virtual machine to migrate task requests on the first pass-through device, thereby controlling the first pass-through device to enter an idle state. The first virtual machine is paused, and its state data is migrated to the second physical machine, so that the second physical machine runs the second virtual machine according to the state data of the first virtual machine and sets the driver state of the second virtual machine to the second pass-through device on the second physical machine to the continue state.

2. The method according to claim 1, characterized in that, The hardware driver component notifies the first virtual machine to migrate task requests from the first passthrough device, including: A virtual interrupt is initiated on the first virtual machine using the hardware driver component; Using the first virtual machine, task requests from the first pass-through device are migrated to the target object for processing.

3. The method according to claim 1, characterized in that, Migrating task requests away from the first through device includes: Obtain at least one task request pending processing from the first through device; Determine the software processing module that is adapted to each of the at least one task request; any software processing module is located on the first physical device or on a remote device; The at least one task request is migrated to its respective adapted software processing module for processing.

4. The method according to claim 3, characterized in that, Obtaining at least one task request to be processed by the first through device includes: Retrieve task requests that the first through device has received but not yet processed from its task queue; and / or, Intercept the task request issued by the first virtual machine with the first pass-through device as the destination device.

5. The method according to claim 3, characterized in that, Determining the software processing module adapted to each of the at least one task request includes: Based on the computation type of each of the at least one task request, determine the appropriate software processing module for each of the at least one task request; or, Based on the type of the pass-through device corresponding to each of the at least one task request, determine the software processing module that is suitable for each of the at least one task request.

6. A virtual machine migration method, characterized in that, include: Receive the hot migration command for the first virtual machine; Obtain the status data of the first virtual machine; The first virtual machine is migrated out of the first physical machine using the method described in any one of claims 1-5; Based on the status data of the first virtual machine, run the second virtual machine on the second physical machine; Set the driver state of the second virtual machine to the second passthrough device on the second physical machine to the continue state, so as to use the second passthrough device to execute the task request of the second virtual machine.

7. The method according to claim 6, characterized in that, Based on the state data of the first virtual machine, before running the second virtual machine on the second physical machine, the following steps are also included: Obtain the configuration data of the first virtual machine; the configuration data includes at least one of the following: configuration data of the pass-through device, driver configuration data, and environment configuration data; Based on the configuration data, resources are allocated on the second physical machine to create the runtime environment for the second virtual machine.

8. A virtual machine migration system, characterized in that, include: First physics machine and second physics machine; The first physical machine is used to respond to the hot migration command, determine the first virtual machine to be migrated; set the first virtual machine's drive state for the first pass-through device on the first physical machine to a paused state; notify the first virtual machine through the hardware driver component to use the first virtual machine to migrate the task requests on the first pass-through device, so as to control the first pass-through device to enter an idle state; pause the first virtual machine and migrate the state data of the first virtual machine to the second physical machine. The second physical machine is configured to receive a hot migration instruction from the first virtual machine; acquire the status data of the first virtual machine, and run the second virtual machine on the second physical machine based on the status data of the first virtual machine; and set the drive status of the second virtual machine to the second pass-through device on the second physical machine to the continue state, so as to execute the task request of the second virtual machine using the second pass-through device.

9. An electronic device, characterized in that, include: Memory and processor; The memory is used to store one or more computer instructions; The processor is configured to execute one or more computer instructions for performing the steps of the method according to any one of claims 1-7.

10. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by a processor, it can implement the virtual machine migration method according to any one of claims 1-7.

Images