Virtual Machine Creation Method, Migration Method and Computer-Readable Medium

Abstract

The present invention provides a virtual machine creation method, a migration method and a computer-readable medium. The migration method includes extracting a register list, determining the same registers included in the register lists of the physical hardware respectively configured at the source end and the target end; extracting and saving the intersection of the register values formed by the same registers possessed by the source end and the target end; writing the intersection of the register values into the simulated registers of the virtual hardware, and calling the intersection of the register values through the virtualized hardware acceleration module; creating a virtual machine to be migrated identical to the virtual machine being migrated at the source end at the target end, writing the intersection of the register values into the simulated registers of the virtual hardware at the target end, and migrating and loading the virtual machine data of the virtual machine being migrated at the source end to the virtual machine to be migrated that has been created at the target end. Through the present invention, the creation operation and the hot migration operation of the virtual machine are realized between the physical machines constructed by heterogeneous hardware provided by different manufacturers with the same architecture.

Description

Technical Field

[0001] The present invention relates to the technical field of virtual machine migration, and in particular, to a method for creating a virtual machine, a method for migrating the virtual machine, and a computer-readable medium. Background Art

[0002] Performing live migration on a virtual machine that has been created in a cloud platform means completely preserving the running state of the virtual machine, and at the same time, it can be quickly restored to the original hardware platform or even a different hardware platform. After restoration, the virtual machine still runs smoothly, and users will not notice any difference. Live migration plays an important role in scenarios such as double-click fault tolerance, database backup, environment reproduction, computer sharing, etc. Live migration usually performs migration between two physical machines (i.e., P2P, Physical-to-Physical), and ensures that the virtual machine performs the migration operation in the startup state, and changes the computing resources and stored data of the virtual machine after the live migration is completed.

[0003] Refer Figure 1 As shown, when performing a virtual machine live migration operation between physical machine 1 (i.e., the source end) and physical machine 2 (i.e., the target end), the virtual machine VM2 to be migrated can be first created at the target end, and during the virtual machine migration stage, the virtual machine data included in the virtual machine VM1 that has been deployed and running at the source end is, under the control of a virtual machine migration system (such as Hypervisor), migrated online to the virtual machine VM2 at the target end to implement the live migration operation; at the same time, after the live migration operation ends, the virtual machine VM1 stops running, and the virtual machine VM2 starts to run officially. The aforementioned virtual machine data is the following data included in the virtual machine being migrated: the memory data of the virtual machine, the virtual machine description information (including the configuration and device information of the virtual machine), and the status data of the virtual machine.

[0004] Generally, the implementation methods of virtual machines include stack - based virtual machines (such as JVM, CPython, and.Net CLR) and register - based virtual machines (such as Dalvik and Lua5.0). The operand stack of a stack - based virtual machine is laid out in memory. Although it can ignore the specific physical architecture, especially registers, any operation of a stack - based virtual machine has to go through the operand stack structure. Therefore, stack - based virtual machines run slowly and are not suitable for open - source systems based on the ARM architecture. In a register - based virtual machine, there is no concept of an operand stack, but there are many virtual registers. Generally, these registers (operands) are aliases, and the execution engine needs to resolve these registers (operands) to find the specific location of the operand and then fetch the operand for calculation. A continuous memory area in the current stack frame. When these data are being calculated, they are directly sent to the physical CPU for calculation without having to be transferred to the operand stack and then calculated again. Register - based virtual machines can provide more powerful instruction sets. Register - based virtual machines need to use registers to store intermediate results, variables, etc. Although the code size of a register - based virtual machine is smaller than that of a stack - based virtual machine, in actual deployment and running environments, the performance of register - based virtual machines is significantly better than that of stack - based virtual machines, and register - based virtual machines can better optimize instructions.

[0005] However, in a heterogeneous scenario, for physical hardware of the same architecture from different manufacturers, since different manufacturers will separately define the instruction specifications (SPEC) for the same kind of hardware, there are differences in the meanings of some optional registers defined by the same architecture but different manufacturers. Therefore, when a service, application, functional module, or cloud platform is deployed to a virtual machine, if the physical machine on which the virtual machine is deployed (or created) is in a heterogeneous scenario caused by different manufacturers (such as AMD and INTEL) for the same hardware architecture (such as both being x86 architecture), there is a hidden danger of addressing failure, resulting in the technical problem of poor effect in performing live migration of the virtual machine, and further resulting in the problem of service interruption caused by the failure of the live migration of the virtual machine. Therefore, it is particularly important to simulate different registers in the hardware architecture in a heterogeneous scenario, especially to urgently propose corresponding solutions to the problem of the failure of live migration of virtual machines in a heterogeneous scenario caused by the customization of multiple registers deployed by the instruction sets supported by the physical hardware in the called heterogeneous scenario.

[0006] In view of this, it is necessary to improve the method for migrating virtual machines in the existing technology for hardware heterogeneous scenarios to solve the above problems. Summary of the Invention

[0007] The object of the present invention is to disclose a virtual machine creation method, a migration method and a computer-readable medium, so as to implement the creation operation and hot migration operation of a virtual machine between physical machines constructed by heterogeneous hardware provided by different manufacturers with the same architecture, improve the success rate of virtual machine hot migration, effectively prevent the failure probability caused by the virtual machine performing hot migration, reduce the computational overhead of simulating the heterogeneous hardware of heterogeneous manufacturers, improve the simulation efficiency, and ensure the continuity and stability of the service.

[0008] To achieve one of the above objects, the present invention first discloses a virtual machine creation method, including:

[0009] Obtain a virtual machine creation request;

[0010] Extract the register lists included in the physical hardware respectively configured at the source end and the target end;

[0011] Determine the same registers included in the register lists of the physical hardware respectively configured at the source end and the target end;

[0012] Extract and save the intersection of the register values formed by the same registers of the source end and the target end;

[0013] Write the intersection of the register values into the simulation registers of the virtual hardware, and call the intersection of the register values through the virtualized hardware acceleration module to create a virtual machine at the source end and / or the target end.

[0014] As a further improvement of the present invention, the intersection of the register values is determined by performing a binary AND operation on the register values respectively possessed by the source end and the target end.

[0015] As a further improvement of the present invention, the register values are described by the values of one or any combination of custom registers, page table registers, control registers, status registers, memory access registers or cache registers included in the physical hardware, wherein the physical hardware includes a physical CPU or a physical GPU.

[0016] As a further improvement of the present invention, the register values further include bits representing the acceleration instructions supported by both the source end and the target end.

[0017] Based on the same inventive concept, the present invention also discloses a virtual machine migration method for migrating a virtual machine between a source end and a target end, and the migration method includes:

[0018] Extract the register lists included in the physical hardware respectively configured at the source end and the target end;

[0019] Determine the same registers included in the register lists of the physical hardware respectively configured at the source end and the target end;

[0020] Extract and save the intersection of register values formed by the same registers in the source end and the target end;

[0021] Write the intersection of the register values into the simulated registers of the virtual hardware, and call the intersection of the register values through the virtualized hardware acceleration module;

[0022] Create a virtual machine to be migrated in the target end that is the same as the virtual machine being migrated in the source end, write the intersection of the register values into the simulated registers of the virtual hardware in the target end, and after migrating and loading the virtual machine data of the virtual machine being migrated in the source end to the virtual machine to be migrated that has been created in the target end through the virtual machine migration system, shut down the virtual machine being migrated in the source end.

[0023] As a further improvement of the present invention, the operation of extracting the register lists included in the physical hardware respectively configured in the source end and the target end is performed by the Hypervisor that manages the source end and the target end, and the Hypervisor includes Hyper-V, Xen, Linux OS or EXSi.

[0024] As a further improvement of the present invention, the intersection of the register values is determined by performing a binary AND operation on the register values respectively possessed by the source end and the target end through the Hypervisor.

[0025] As a further improvement of the present invention, the register values are described by the values of one or any combination of custom registers, page table registers, control registers, status registers, memory access registers or Cache registers included in the physical hardware, wherein the physical hardware includes a physical CPU or a physical GPU.

[0026] As a further improvement of the present invention, the register values further include bits representing acceleration instructions adapted to both the source end and the target end.

[0027] Finally, based on the same inventive concept, the present invention also discloses a computer-readable medium, in which computer program instructions are stored, and when the computer program instructions are read and run by a processor, the steps in the virtual machine migration method described in any one of the above inventive creations are executed.

[0028] Compared with the prior art, the beneficial effects of the present invention are:

[0029] In this application, the intersection of register values is written into the simulated registers of the virtual hardware, and the intersection of register values is called through the virtualized hardware acceleration module, so that the virtual machines created at the source end and the target end have the function of live migration. In particular, when live migration needs to be performed on a virtual machine, it is possible to ignore the differences in register definitions of the same architecture hardware by different manufacturers in a heterogeneous scenario, thereby realizing efficient and reliable live migration operations of virtual machines and ensuring the continuity and stability of services. Description of the Drawings

[0030] Figure 1 It is a schematic diagram of performing live migration of a virtual machine between two physical machines in the prior art;

[0031] Figure 2 It is a schematic diagram of performing live migration of a virtual machine between two physical machines with heterogeneous hardware using a method for migrating a virtual machine according to the present invention;

[0032] Figure 3 It is an example diagram of Physical Machine 1 and Physical Machine 2 being managed by a Hypervisor;

[0033] Figure 4 It is a flowchart of a method for creating a virtual machine according to the present invention;

[0034] Figure 5 It is a flowchart of a method for migrating a virtual machine according to the present invention;

[0035] Figure 6 It is an example diagram of extracting and saving the intersection of register values formed by the same registers possessed by the source end and the target end in a heterogeneous physical CPU scenario in Physical Machine 1 and Physical Machine 2;

[0036] Figure 7 It is a topology diagram of a computer-readable medium according to the present invention. Detailed Embodiments

[0037] The present invention will be described in detail below in conjunction with the various embodiments shown in the drawings. However, it should be noted that these embodiments are not limitations of the present invention, and any equivalent transformation or substitution in terms of function, method, or structure made by those of ordinary skill in the art based on these embodiments shall fall within the protection scope of the present invention.

[0038] Example 1:

[0039] Refer Figures 1 to 4 and Figure 6 to the specific embodiments of a method for creating a virtual machine according to the present invention shown. Refer Figure 4 As shown, a method for creating a virtual machine disclosed in this embodiment includes the following steps S11 to S15.

[0040] The virtual machine creation method disclosed in this embodiment aims to create a virtual machine (VM) that can be subsequently subjected to live migration operations among multiple physical machines (or physical servers), and the virtual machine created through this embodiment can be deployed in multiple logically isolated physical machines. After the virtual machine is created, it is managed by a virtual machine monitor (Hypervisor). The creation process of the virtual machine can be implemented using existing technologies and will not be elaborated here. Generally, a virtual machine creation request can be initiated by a user (or administrator) by calling nova-api on a client (or in the background), and network resources, storage resources, memory, etc. required to support the virtual machine are gradually loaded. The Hypervisor maintains multiple efficient and isolated program environments, which support users to directly access real hardware, that is, one or several physical hardware components included in the physical machine. During the pre-creation stage, creation stage, running stage, and subsequent migration stage of the virtual machine, the virtual machines created or deployed on each physical machine are all managed by the Hypervisor. The virtual machine method disclosed in this embodiment focuses on creating a virtual machine corresponding to the register value intersection formed by the same registers of two or more physical machines at the source end and / or target end, so as to ignore the differences in register definitions of the same architecture hardware by different manufacturers in the heterogeneous scenario during the subsequent virtual machine migration process (for example, physical CPUs based on the x86 architecture but manufactured by AMD and INTEL respectively, or physical CPUs based on the ARM architecture but the FT-200 physical CPU manufactured by Phytium and the Kunpeng 920 physical CPU manufactured by Huawei respectively), to meet the subsequent live migration requirements and the virtual machine live migration scenario requirements between the same architecture but different manufacturers (hereinafter referred to as "heterogeneous scenario").

[0041] In this virtual machine creation method, first, step S11 is executed: obtain a virtual machine creation request. The virtual machine creation operation is performed by the Hypervisor that manages the source end and the target end. The Hypervisor includes Hyper-V (applicable to the Windows operating system), Xen (applicable to the Linux operating system), Linux OS (applicable to the Linux operating system), or EXSi (applicable to VMware). The source end and the target end are relative concepts. Refer Figure 2 to the following. If the virtual machine VM is migrated from physical machine 1 to physical machine 2 and the virtual machine VM2 is started, then physical machine 1 is the source end and physical machine 2 is the target end. Generally, virtual machines created in multiple nodes defined in each physical machine of a server cluster can perform live migration among the physical machines, and the live migration process will not be perceived by users to ensure that the business does not interrupt.

[0042] Step S12: Extract the register lists included in the physical hardware configured at the source end and the target end respectively. Specifically, the operation of extracting the register lists included in the physical hardware configured at the source end and the target end respectively is executed by the Hypervisor that manages the source end and the target end. The Hypervisor includes Hyper-V, Xen, Linux OS, or EXSi. The register lists are separately composed of multiple registers inherent in the physical hardware at the source end and the target end. Generally, in a heterogeneous scenario, although the physical hardware at the source end and the target end belongs to the same architecture of physical hardware (for example, both are physical CPUs of the ARMv8 architecture), due to the significant differences in the register descriptions (Register Descriptions) of the registers included in the physical CPUs of this architecture by different manufacturers, even for the same architecture of physical hardware, when creating a virtual machine and performing live migration on the virtual machine subsequently, due to the differences in the register descriptions (Register Descriptions), the live migration fails, or complex modifications are required for the instruction compilation of the acceleration instruction sets supported by the physical hardware (such as acceleration instructions like AES, SSE, MMX, AVX, etc.), and it will cause a certain degree of code intrusion to the virtualization platform, virtual machines, virtualization software, and applications. Since the execution of the live migration operation requires ensuring that the acceleration instruction sets supported by the physical hardware at the source end and the target end are the same to ensure the success rate of the live migration. Therefore, it is necessary to unify the same registers included in the register lists of the physical hardware configured at the source end and the target end respectively in a heterogeneous scenario to prevent the failure of performing live migration on the virtual machine, and thus execute the following step S13. In this embodiment, the physical hardware includes a physical CPU or a physical GPU, or includes both a physical CPU and a physical GPU, and may even be a physical server including a physical CPU and / or a physical GPU.

[0043] Step S13: Determine the same registers included in the register lists of the physical hardware configured at the source end and the target end respectively. Based on the characteristics of the possible sameness and differences in the register descriptions of the same register by the physical CPUs based on the ARMv8 architecture at the source end and the target end, the Hypervisor that manages the source end and the target end determines and obtains the register list including the same registers. Refer Figure 3 to Figure 6 the Figure 6 figure shown, in the physical machine 1 (such as the source end) deployed in the figure, CPU_A includes n registers (i.e., register_1 to register_n). Figure 6Deployed in physical machine 2 (e.g., the source end), CPU_B contains n registers (i.e., register_1 to register_n). Both CPU_A and CPU_B are physical CPUs and are subordinate concepts of the physical hardware in this embodiment. Similar to physical CPUs, the registers of physical GPUs are also the spaces with the fastest access speed. Therefore, in virtualization and virtual machine live migration scenarios, it is particularly important to determine the same registers with the same register value descriptions contained in the physical GPUs of two physical machines. Whether it is a physical CPU or a physical GPU, the register value is a kernel function, and the kernel function will be allocated to a specified register and perform operations such as data calculation, data writing, and storage instructions after being bound to a thread (Thread).

[0044] Step S14: Extract and save the intersection of the register values formed by the same registers possessed by the source end and the target end. Specifically, the intersection of the register values is determined by a binary AND operation on the register values respectively possessed by the source end and the target end. As Figure 6 shown, this embodiment discloses a typical example of determining the intersection of the register values formed by the same registers possessed by the source end and the target end through a binary AND operation.

[0045] As Figure 6 shown, CPU_A and CPU_B with the same architecture contain the same register, i.e., register_1. The register value of register_1 in CPU_A is 0x00000000701f6622, and the register value of register_1 in CPU_B is 0x00000000481fd010. The symbol "&" is the operator for the binary AND operation to calculate the virtual CPU, i.e., vCPU_C (virtual CPU), that can ultimately be formed by CPU_A and CPU_B (both physical CPUs) through virtualization technology. Then, a virtual machine is created through the virtual CPU in the subsequent process, and the virtual CPU is allocated to the virtual machine as a resource. Combining Figure 2As shown, in order to improve the efficiency of virtual machine creation in a server cluster and indirectly improve the efficiency and reliability of subsequent hot migration of virtual machines, as well as to support the need for high concurrency, the register value intersection can also be bypassed and saved to a storage device. The storage device can be a storage device provided by the physical hardware, such as the cache provided by the physical GPU, the local memory of the GPU, the shared cache in the GPU that can be accessed by blocks, the cache provided by the CPU, a memory directly connected to the physical CPU through a DMA controller and built into the DMA controller, thereby performing direct memory data transfer based on the core shared system data bus, and even a storage device (such as a disk) or distributed cache or database mounted through the system bus.

[0046] Step S15, write the intersection of register values into the simulation register of the virtual hardware, and call the intersection of register values through the virtualization hardware acceleration module to create a virtual machine in the source end and / or the target end. Specifically, in this embodiment, the register value is described by one or any several register values of the custom register, page table register, control register, status register, memory access register or cache register contained in the physical hardware. The register value also includes a bit that represents the acceleration instructions that are adapted to both the source end and the target end. If the physical hardware is a physical CPU, the virtual hardware is a vCPU, and the simulation register of the virtual hardware is a simulation register that supports the vCPU. Acceleration instructions such as AES, CRC32, SHA1, SHA2 in the physical CPU can be given a one-to-one correspondence by representing the bits that support the acceleration instructions that are adapted to both the source end and the target end (i.e., the bits that represent the acceleration instructions). For example, in the ARMv8 architecture, support for the AES acceleration instruction is indicated by bits 4 to 7 of the ID_AA64ISAR0_EL1 register. A value of 0b0001 indicates support for the acceleration instruction, while a value of 0b0000 indicates non-support. By introducing bits that indicate support for acceleration instructions adapted by both the source and target, the types of acceleration instructions supported by both the source and target are further clarified, thereby further improving the success rate and efficiency of virtual machine live migration.

[0047] Meanwhile, the aforementioned custom register refers to the functions filled in the same register by each manufacturer. The present invention aims to ensure that after the virtual hardware is modified, it can support the hot migration operation of virtual machines in a heterogeneous environment after being created. Specifically, if the manufacturer of the physical hardware as the source end configures the virtualization hardware acceleration module of Feiteng 200 (such as qemu-kvm) to create virtual machine A1 and specifies the vCPU model as C; the manufacturer of the physical hardware as the target end configures the virtualization hardware acceleration module of Kunpeng 920 (such as qemu-kvm) to create virtual machine B1. At this time, the intersection of the register values is called through the virtualization hardware acceleration module to create virtual machine B1 at the target end, and the virtual machine created at the target end has the same register and vCPUs with the same register values, that is, vCPUs of model C. At this time, the physical CPU at the target end is virtualized to form vCPU, which already includes virtual machine B1 with the same register values, thus meeting the subsequent requirement for hot migration of virtual machines A1 and B1 between the source end and the target end. So far, virtual machine VM1 has been created in physical machine 1 at the source end during the virtual machine creation stage, and the virtual machine running stage is entered. The creation of the virtual machine at the target end is the same as described above.

[0048] Example 2:

[0049] Based on the technical solution of a virtual machine migration method disclosed in Embodiment 1, the embodiment also discloses a specific implementation manner of a virtual machine migration method for performing a virtual machine hot migration operation between two physical machines (i.e., Figure 2 physical machine 1 and physical machine 2) with heterogeneous hardware in

[0050] Combined with Figures 1 to 3 、 Figure 5 and Figure 6 shown, in this embodiment, a virtual machine migration method is used to perform migration between the source end and the target end. The migration method includes the following steps S21 to step S25. Based on the virtual machine creation method disclosed in Embodiment 1, virtual machine VM1 has been created. This embodiment aims to realize the hot migration of virtual machine VM1 in physical machine 1 to physical machine 2 and start it in the form of virtual machine VM2. In this embodiment, Figure 2 virtual machines VM1\VM2 in

[0051] Step S21, extract the register lists included in the physical hardware respectively configured at the source end and the target end.

[0052] Step S22: Determine the identical registers included in the register lists of the physical hardware configured for the source end and the target end respectively. Specifically, the operation of extracting the register lists of the physical hardware configured for the source end and the target end respectively is performed by the Hypervisor that manages the source end and the target end. The Hypervisor includes Hyper-V, Xen, Linux OS, or EXSi.

[0053] Step S23: Extract and save the intersection of the register values formed by the identical registers of the source end and the target end. The intersection of the register values is determined by performing a binary AND operation on the register values respectively possessed by the source end and the target end through the Hypervisor. The applicant points out that the specific implementation processes of steps S21 to S23 in this embodiment can be referred to the steps S12 to S14 in Embodiment 1, which will not be elaborated here.

[0054] Step S24: Write the intersection of the register values into the simulated register of the virtual hardware, and call the intersection of the register values through the virtualization hardware acceleration module (such as qemu-kvm). The writing of the intersection of the register values into the simulated register of the virtual hardware is also performed by the Hypervisor.

[0055] The applicant takes the AIDR register included in the physical CPU with the ARMv8 architecture as an example and shows the following code to illustrate reading and writing the virtual machine and simulating the value of the AIDR register, specifically as follows:

[0056]

[0057] Thus, the register values of the virtual machine VM1 already created on the source end (such as physical machine 1) and the virtual machine VM1 adapted to the target end (i.e., physical machine 2) are predefined to avoid modifying the value of the AIDR register in the heterogeneous scenario after the virtual machine VM1 is live migrated to the target end. Therefore, after the virtual machine VM1 in the source end is live migrated to the target end, no instruction modification needs to be performed, thus ensuring the success rate of the live migration. Because, in the heterogeneous scenario, only the identical registers with the same register values contained in the source end and the target end can be recognized by the already created and running virtual machine VM and directly called by the virtual machine VM2 after being migrated to the target end. In addition, the operation of writing the intersection of the register values into the simulated register of the virtual hardware has been predefined before the live migration operation of the virtual machine VM1 is performed, thereby improving the mutual backup and high availability among physical machines in the heterogeneous scenario and not causing code intrusion to the target end, ensuring the stability of the cloud platform.

[0058] Step S25: Create a virtual machine to be migrated in the target end that is the same as the virtual machine being migrated in the source end. Write the intersection of register values into the simulated registers of the virtual hardware in the target end. After migrating and loading the data of the virtual machine being migrated in the source end to the virtual machine to be migrated that has been created in the target end through the virtual machine migration system, shut down the virtual machine being migrated in the source end. The register values are described by the values of one or any combination of custom registers, page table registers, control registers, status registers, memory access registers, or cache registers included in the physical hardware, where the physical hardware includes a physical CPU or a physical GPU. The register values also include bits indicating support for acceleration instructions adapted to both the source end and the target end.

[0059] Re-reference Figure 2 As shown, during the virtual machine running stage, directly create the virtual machine to be migrated, VM2, in the target end and write to the simulated registers of the vCPU. When the Hypervisor performs live migration on the virtual machine VM1, do not stop the virtual machine VM1 in the source end, and directly in the target end according to the simulated registers of the virtual hardware that have been written to the target end (such as the aforementioned simulated registers of the vCPU). Then, configure storage resources, network resources, computing resources, modify the permissions of the shared directory, modify the configuration file of Libvirtd, username, password, and other resources for the virtual machine VM2, and then start the virtual machine VM2. Then, directly copy the data in the memory occupied by the physical machine 1 of the virtual machine VM1 to the memory of the physical machine 2. Finally, after the virtual machine VM2 is pulled up and started, stop the virtual machine VM1 in the source end, thus completing the entire live migration operation of the virtual machine VM1 in the source end. The virtual machine migration method disclosed in this embodiment can implement live migration of virtual machines in heterogeneous scenarios and ensure that the services provided by the virtual machines are not interrupted, ensuring the high availability of the cloud platform and the continuity of the services.

[0060] Example 3:

[0061] Reference Figure 7 As shown, this embodiment discloses a specific implementation of a computer-readable medium 900. The computer-readable medium 900 stores computer program instructions 901. When the computer program instructions 901 are read and run by a processor 902, they execute the steps in the virtual machine migration method as described in Embodiment 1. For the technical solutions with the same parts in the virtual machine migration method in this embodiment and Embodiment 2, please refer to Embodiment 2 and will not be elaborated here.

[0062] In the embodiments of the present invention, the various illustrative logical blocks or units described can be implemented or operate the described functions through a general - purpose processor, a digital signal processor, an application - specific integrated circuit (ASIC), a field - programmable gate array or other programmable logic device, discrete gate or transistor logic, discrete hardware components, or any combination of the above designs. The general - purpose processor can be a microprocessor. Optionally, the general - purpose processor can also be any conventional processor, controller, microcontroller or state machine. The processor can also be implemented by a combination of computing devices, such as a digital signal processor and a microprocessor, multiple microprocessors, one or more microprocessors in conjunction with a digital signal processor core, or any other similar configuration.

[0063] The series of detailed descriptions listed above are only specific descriptions of the feasible implementation manners of the present invention, and they are not intended to limit the protection scope of the present invention. Any equivalent implementation manners or changes made without departing from the technical spirit of the present invention should be included within the protection scope of the present invention.

[0064] In addition, it should be understood that although this specification is described according to embodiments, not every embodiment only contains an independent technical solution. This narrative manner of the specification is only for clarity. Those skilled in the art should regard the specification as a whole, and the technical solutions in each embodiment can also be appropriately combined to form other embodiments that can be understood by those skilled in the art.

Claims

1. A method for creating a virtual machine, characterized in that, including: Obtaining a virtual machine creation request; Extracting the register lists included in the physical hardware respectively configured at the source end and the target end; Determining the identical registers included in the register lists of the physical hardware respectively configured at the source end and the target end; Extracting and saving the intersection of the register values formed by the identical registers of the source end and the target end; Writing the intersection of the register values into the simulated registers of the virtual hardware, and invoking the intersection of the register values through the virtualized hardware acceleration module to create a virtual machine at the source end and / or the target end, and the register values further include bits representing acceleration instructions that are simultaneously supported by the source end and the target end; The physical hardware respectively configured at the source end and the target end is physical hardware of the same architecture but different manufacturers.

2. The method according to claim 1, characterized in that The intersection of the register values is determined by performing a binary AND operation on the register values respectively possessed by the source end and the target end.

3. The method according to claim 1, wherein The register values are described by the values of one or any combination of custom registers, page table registers, control registers, status registers, memory access registers or cache registers included in the physical hardware, where the physical hardware includes a physical CPU or a physical GPU.

4. A method for migrating a virtual machine, which is used to perform migration of the virtual machine between a source end and a target end, characterized in that, The migration method includes: Extracting the register lists included in the physical hardware respectively configured at the source end and the target end; Determining the identical registers included in the register lists of the physical hardware respectively configured at the source end and the target end; Extracting and saving the intersection of the register values formed by the identical registers of the source end and the target end; Writing the intersection of the register values into the simulated registers of the virtual hardware, and invoking the intersection of the register values through the virtualized hardware acceleration module; Creating a virtual machine to be migrated identical to the virtual machine being migrated at the source end at the target end, writing the intersection of the register values into the simulated registers of the virtual hardware at the target end, migrating and loading the data of the virtual machine being migrated at the source end to the virtual machine to be migrated that has been created at the target end through the virtual machine migration system, and then shutting down the virtual machine being migrated at the source end, and the register values further include bits representing acceleration instructions that are simultaneously supported by the source end and the target end; The physical hardware respectively configured at the source end and the target end is physical hardware of the same architecture but different manufacturers.

5. The migration method according to claim 4, characterized in that The operation of extracting the register lists included in the physical hardware respectively configured at the source end and the target end is performed by the Hypervisor that manages the source end and the target end, and the Hypervisor includes Hyper-V, Xen, Linux OS or EXSi.

6. The migration method according to claim 5, characterized in that The intersection of the register values is determined by performing a binary AND operation on the register values respectively possessed by the source end and the target end by the Hypervisor.

7. The migration method according to claim 4, wherein The register values are described by the values of one or any combination of custom registers, page table registers, control registers, status registers, memory access registers or cache registers included in the physical hardware, where the physical hardware includes a physical CPU or a physical GPU.

8. A computer-readable medium, characterized in that Computer program instructions are stored in the computer-readable medium. When the computer program instructions are read and run by a processor, the steps in the virtual machine migration method according to any one of claims 4 to 7 are executed.

Images