CN114090171A

CN114090171A - Virtual machine creation method, migration method and computer readable medium

Info

Publication number: CN114090171A
Application number: CN202111313597.1A
Authority: CN
Inventors: 周晓; 仇大玉
Original assignee: Huayun Data Holding Group Co ltd; Orient Securities Co ltd
Current assignee: Huayun Data Holding Group Co ltd; Orient Securities Co ltd
Priority date: 2021-11-08
Filing date: 2021-11-08
Publication date: 2022-02-25

Abstract

The invention provides a virtual machine creating method, a virtual machine migrating method and a computer readable medium, wherein the virtual machine creating method comprises the steps of extracting a register list, and determining the same registers contained in the register list contained in physical hardware respectively configured by a source end and a target end; extracting and storing the register value intersection formed by the same registers of the source end and the target end; writing the register value intersection into a simulation register of the virtual hardware, and calling the register value intersection through a virtualized hardware acceleration module; creating a virtual machine to be migrated which is the same as the virtual machine to be migrated in the source end in the target end, writing the intersection of the register values into a simulation register of virtual hardware of the target end, migrating the data of the virtual machine to be migrated in the source end, and loading the data to the virtual machine to be migrated which is created in the target end. According to the invention, the creation operation and the hot migration operation of the virtual machine are executed between the physical machines constructed by the heterogeneous hardware provided by the same architecture and different manufacturers.

Description

Virtual machine creation method, migration method and computer readable medium

Technical Field

The present invention relates to the field of virtual machine migration technologies, and in particular, to a virtual machine creation method, a virtual machine migration method, and a computer readable medium.

Background

Executing live migration on a virtual machine created in a cloud platform means that the running state of the virtual machine is completely stored, and meanwhile, the running state can be quickly restored to an original hardware platform or even different hardware platforms. After recovery, the virtual machine is still running smoothly and the user does not perceive any differences. The live migration plays an important role in the scenes of double-click fault tolerance, database backup, environment reproduction, computer sharing and the like. The live migration generally 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 storage data of the virtual machine after the live migration is completed.

Referring to fig. 1, when performing a virtual machine live migration operation between a physical machine 1 (i.e., a source end) and a physical machine 2 (i.e., a target end), a virtual machine VM2 to be migrated may be first created at the target end, and in a virtual machine migration phase, virtual machine data included in a virtual machine VM1 that has been deployed and run in the source end is migrated online to a virtual machine VM2 of the target end under the control of a virtual machine migration system (e.g., Hypervisor), so as to implement the live migration operation; meanwhile, after the live migration operation is finished, the virtual machine VM1 stops running, and the virtual machine VM2 runs formally. The virtual machine data is the following data included in the virtual machine executing migration: the virtual machine configuration information comprises memory data of the virtual machine, virtual machine description information (comprising configuration and equipment information of the virtual machine), and state data of the virtual machine.

Typically, virtual machine implementations include stack-based virtual machines (e.g., JVM, CPython, and. Net CLR) and register-based virtual machines (e.g., Dalvik and Lua 5.0). The operand stack layout of the stack-based virtual machine is in memory, although it may be regardless of the specific physical architecture, particularly the registers. However, any operation of the stack-based virtual machine is performed through an operand stack (operand stack) structure, so that the stack-based virtual machine is slow in operation speed and is not suitable for an ARM architecture-based open source system. There is no concept of operand stack in the register-based virtual machine, but there are many virtual registers, and these registers (operands) are alias names in general, and it is necessary for the execution engine to parse these registers (operands), find out the specific positions of the operands, and then fetch the operands for operation. A block of contiguous memory area in the current stack frame. During operation, the data are directly sent to a physical CPU for calculation, and are not required to be sent to an operand stack for operation. Register-based virtual machines can provide a more powerful instruction set. Register-based virtual machines require registers to hold intermediate results, variables, and the like. Although the code size of the register-based virtual machine is smaller than that of the register-based virtual machine, in an actual deployment and running environment, the performance of the register-based virtual machine is obviously superior to that of the stack-based virtual machine, and the register-based virtual machine can better optimize instructions.

However, in the heterogeneous scenario, different manufacturers define the physical hardware with the same architecture, and since instruction Specifications (SPECs) of the same hardware are defined separately by different manufacturers, the meaning of some optional registers defined by the same architecture but different manufacturers is different. Therefore, after a service, an application, a function module, or a cloud platform is deployed to a virtual machine, if a physical machine that deploys (or creates) the virtual machine is in an heterogeneous scenario due to the fact that a hardware architecture of the physical machine is the same as the hardware architecture (for example, both are x86 architectures) but different from the hardware architecture (for example, AMD and INTEL), there is a hidden danger of an addressing failure, so that there is a technical problem that a hot migration effect on the virtual machine is not good, and further there is a problem of service interruption due to the hot migration failure of the virtual machine. Therefore, it is very important to perform analog simulation on different registers of a hardware architecture in an isomerization scenario, and especially, a corresponding solution is urgently needed to solve the problem of failure of live migration of a virtual machine in the isomerization scenario caused by customization of a plurality of registers deployed in an instruction set supported by physical hardware in a called isomerization scenario.

In view of the above, there is a need to improve the migration method for a virtual machine in a hardware isomerization scenario in the prior art to solve the above problems.

Disclosure of Invention

The invention aims to disclose a virtual machine creating method, a virtual machine migrating method and a computer readable medium, which are used for implementing creating operation and live migration operation on a virtual machine between physical machines constructed by heterogeneous hardware provided by different manufacturers with the same architecture, improving the success rate of live migration of the virtual machine, effectively preventing the failure probability caused by live migration of the virtual machine, reducing the computational overhead of simulating the heterogeneous hardware of the heterogeneous manufacturers, and improving the simulation efficiency so as to ensure the continuity and stability of services.

In order to achieve one of the above objects, the present invention first discloses a virtual machine creating method, including:

acquiring a virtual machine creation request;

extracting register lists contained in physical hardware respectively configured by a source end and a target end;

determining the same registers contained in a register list contained in physical hardware respectively configured by a source end and a target end;

extracting and storing the register value intersection formed by the same registers of the source end and the target end;

and writing the register value intersection into a simulation register of virtual hardware, and calling the register value intersection through a virtualization hardware acceleration module so as to create a virtual machine in a source end and/or a target end.

As a further improvement of the invention, the intersection of the register values is determined by binary AND operation of the register values respectively possessed by the source terminal and the target terminal.

As a further improvement of the present invention, the register value is described by one or any several register values of a custom register, a page table register, a control register, a state register, a memory access register, or a Cache register included in physical hardware, where the physical hardware includes a physical CPU or a physical GPU.

As a further improvement of the present invention, the register value further includes a bit characterizing an acceleration instruction adapted for both the source side and the target side.

Based on the same invention idea, the invention also discloses a migration method of the virtual machine, which is used for executing migration of the virtual machine between the source end and the target end, and the migration method comprises the following steps:

writing the register value intersection into a simulation register of virtual hardware, and calling the register value intersection through a virtualization hardware acceleration module;

creating a virtual machine to be migrated which is the same as the virtual machine to be migrated in the source end in the target end, writing the intersection of the register values into a simulation register of virtual hardware of the target end, migrating and loading the data of the virtual machine to be migrated in the source end to the virtual machine to be migrated which is already created in the target end through a virtual machine migration system, and then closing the virtual machine to be migrated in the source end.

As a further improvement of the present invention, the operation of extracting the register lists contained in the physical hardware configured respectively by the source end and the target end is performed by hypervisors of the nanotube source end and the target end, where the hypervisors include Hyper-V, Xen, Linux OS, or EXSi.

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

Finally, based on the same inventive concept, the present invention also discloses a computer readable medium, in which computer program instructions are stored, and the computer program instructions are read and executed by a processor to perform the steps of the virtual machine migration method according to any of the above inventions.

Compared with the prior art, the invention has the beneficial effects that:

in the application, the register value intersection is written into the simulation register of the virtual hardware, and the register value intersection is called through the virtualized hardware acceleration module, so that the virtual machines established in the source end and the target end have a live migration function, and particularly, when the live migration needs to be executed on the virtual machines, the difference of different manufacturers on hardware with the same architecture based on register definition in an isomerization scene can be ignored, so that the efficient and reliable live migration operation of the virtual machines is realized, and the continuity and stability of services are ensured.

Drawings

FIG. 1 is a diagram illustrating a prior art virtual machine live migration between two physical machines;

FIG. 2 is a schematic diagram of a virtual machine live migration between two physical machines with heterogeneous hardware using a virtual machine migration method according to the present invention;

FIG. 3 is an exemplary diagram of the physical machines 1 and 2 managed by the Hypervisor nanotube;

FIG. 4is a flowchart of a virtual machine creation method of the present invention;

FIG. 5 is a flowchart illustrating a migration method of a virtual machine according to the present invention;

fig. 6 is a diagram illustrating an example of register value intersection formed by extracting and storing the same registers of the source end and the target end in the heterogeneous physical CPU scenarios in the physical machine 1 and the physical machine 2;

FIG. 7 is a topology diagram of a computer readable medium of the present invention.

Detailed Description

The present invention is described in detail with reference to the embodiments shown in the drawings, but it should be understood that these embodiments are not intended to limit the present invention, and those skilled in the art should understand that functional, methodological, or structural equivalents or substitutions made by these embodiments are within the scope of the present invention.

The first embodiment is as follows:

fig. 1 to fig. 4 and fig. 6 show a specific embodiment of a virtual machine creation method according to the present invention. Referring to fig. 4, the virtual machine creating method disclosed in the present embodiment includes the following steps S11 to S15.

The virtual machine creation method disclosed by the embodiment aims to create a Virtual Machine (VM) which can be subsequently used for executing a live migration operation in a plurality of physical machines (or physical servers), and the virtual machine created by the embodiment can be deployed in a plurality of logically isolated physical machines. After being created, the virtual machine is managed by a virtual machine monitor (Hypervisor), and the creation process of the virtual machine can be implemented by adopting the prior art, which is not described herein again. Generally, a virtual machine creation request can be initiated by a user (or an administrator) calling nova-api at a client (or a background), gradually loading network resources, storage resources, memories and the like required by supporting a virtual machine, and maintaining a plurality of efficient and isolated program environments through Hypervisor, wherein the environments support the user to directly access real hardware, namely one or more types of physical hardware contained in a physical machine. In the pre-virtual machine creation phase, the virtual machine operation phase and the subsequent virtual machine migration phase, the virtual machines created or deployed by the physical machines are managed by the Hypervisor. The virtual machine method disclosed in this embodiment focuses on creating a virtual machine for a register corresponding to an intersection of register values formed based on the same registers of two or more physical machines in a source end and/or a target end, so that in a subsequent virtual machine migration process, a difference, defined by different manufacturers, of hardware with the same architecture (for example, physical CPUs based on an x86 architecture and manufactured by AMD and INTEL, respectively, or a physical CPU of a pentium 200 type manufactured by an ARM architecture and manufactured by a watsman company and a physical CPU of a kurper 920 type manufactured by a watsman company) based on the register in an isomerization scenario can be ignored, so as to meet a subsequent hot migration requirement, and to meet a requirement of the virtual machine hot migration scenario between the same architecture and different manufacturers (hereinafter referred to as an "isomerization scenario").

In the virtual machine creation method, first, step S11 is executed to obtain a virtual machine creation request. The virtual machine creating operation is executed by hypervisors of the nanotube source end and the target end, and the hypervisors comprise Hyper-V (applicable to Windows operating system), Xen (applicable to Linux operating system), Linux OS (applicable to Linux operating system) or EXSi (applicable to VMware). Source and target are relative concepts. Referring to fig. 2, if virtual machine VM is migrated from physical machine 1 to physical machine 2 and virtual machine VM2 is started, physical machine 1 is the source peer and physical machine 2 is the target peer. Generally, virtual machines created in a plurality of nodes defined by physical machines of a server cluster can perform live migration between the physical machines, and the live migration process is not perceived by a user, so as to ensure that service is not interrupted.

Step S12, extracting register lists included in the physical hardware respectively configured by the source end and the target end. Specifically, the operation of extracting the register lists contained in the physical hardware respectively configured by the source end and the target end is executed by hypervisors of the nanotube source end and the target end, where the hypervisors include Hyper-V, Xen, Linux OS, or EXSi. The register list is composed of a plurality of registers that are inherent to the physical hardware in the source and destination, individually. Generally, in an isomerization scenario, although a source end and a target end belong to physical hardware of the same architecture (for example, physical CPUs of the ARMv8 architecture), since different manufacturers have great differences in Register Descriptions (Register Descriptions) of registers included in the physical CPUs of the architecture, even when a virtual machine is created and a subsequent hot migration process is performed on the virtual machine for the physical hardware of the same architecture, due to the difference in Register Descriptions, a hot migration failure is caused or complicated modifications are required to perform instruction compilation on an acceleration instruction set (for example, acceleration instructions such as AES, SSE, MMX, AVX, and the like) supported by the physical hardware, and certain code intrusion is caused on a virtualization platform, the virtual machine, virtualization software, and applications. The success rate of the live migration can be ensured only by ensuring that the acceleration instruction sets supported by the physical hardware supported by the source end and the target end are the same when the live migration operation is executed. Therefore, it is necessary to unify the same registers included in the register lists included in the physical hardware configured by the source and the destination in the heterogeneous scenario to prevent the failure of performing the live migration on the virtual machine, and thus perform 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, or even a physical server including a physical CPU and/or a physical GPU.

Step S13, determining the same register included in the register list included in the physical hardware configured by the source end and the target end respectively. Based on the characteristics that the same register and the difference possibly exist in the register description of the same register by the physical CPU based on the ARMv8 architecture in the source end and the target end, the register list containing the same register is determined and obtained through the Hypervisor of the nanotube source end and the target end. Referring to fig. 3 and fig. 6, in fig. 6, a CPU _ a disposed in a physical machine 1 (e.g., a source end) includes n registers (i.e., register _1 to register _ n), in fig. 6, a CPU _ B disposed in a physical machine 2 (e.g., a source end) includes n registers (i.e., register _1 to register _ n), and both CPU _ a and CPU _ B are physical CPUs and are a lower concept of physical hardware in this embodiment. Similar to the physical CPU, the registers of the physical GPU are also the space with the fastest access speed, and therefore, in the virtualization and virtual machine live-migration scenarios, it is particularly important to determine the same registers of the descriptions with the same register values contained in the physical GPUs contained in the two physical machines. The register value is a kernel function regardless of a physical CPU or a physical GPU, and the kernel function is allocated to a specified register, and is bound to a Thread (Thread) to perform operations such as data operation, data writing, and instruction storage.

And step S14, extracting and storing the register value intersection formed by the same registers of the source end and the target end. Specifically, the intersection of the register values is determined by binary and operations of the register values respectively possessed by the source terminal and the target terminal. Referring to fig. 6, this embodiment discloses an example of determining the intersection of register values formed by identical registers of the source and the target by binary and operation.

Referring to fig. 6, the CPU _ a and the CPU _ B of the same architecture include the same register, i.e., register _1, the register value of register _1 in the CPU _ a is 0x00000000701f6622, the register value of register _1 in the CPU _ B is 0x00000000481fd010, and the symbol "&" is an operator of a binary and operation, so as to calculate, through the binary and operation, a virtualized CPU, i.e., vCPU _ C (virtual CPU), which can be finally formed through the virtualization technique through the CPU _ a and the CPU _ B (both physical CPUs), than in the subsequent process, create a virtual machine through the virtual CPU, and allocate the virtual CPU as a resource to the virtual machine. As shown in fig. 2, in order to improve the virtual machine creation efficiency and indirectly improve the efficiency and reliability of the subsequent live migration performed on the virtual machine in a Server Cluster (Server Cluster), and support the requirement of high concurrency, the register value intersection may also be saved to the storage device by-pass. The storage device may be a storage device of the physical hardware itself, such as a cache of the physical GPU itself, a Local Memory (Local Memory) of the GPU, a Shared cache (Shared Memory) in the GPU that can be accessed by a Block, a cache of the CPU itself, a Memory that is directly connected with the physical CPU through a DMA controller and is built in a DAM controller, so as to perform direct Memory data transmission based on a core Shared system data bus, and even, the storage device may be a storage device (e.g., a disk) or a distributed cache or a database that is mounted through a system bus.

And step S15, writing the register value intersection into the simulation register of the virtual hardware, and calling the register value intersection through the virtualization hardware acceleration module so as 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 a custom register, a page table register, a control register, a status register, a memory access register, or a Cache register included in the physical hardware. The register value also includes bits that characterize the acceleration instructions that support both source and target adaptation. 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 supporting the vCPU. The acceleration instructions such as AES, CRC32, SHA1, SHA2 in the physical CPU can be mapped one-to-one by bits characterizing the acceleration instructions that support both source and destination adaptation (i.e., bits characterizing the acceleration instructions). For example, whether the AES instruction supports 4-7 bits of the ID _ AA64ISAR0_ EL1 register in the ARMv8 architecture, a 4-7 bit value of 0b0001 indicates that the AES instruction is supported, and a 4-7 bit value of 0b0000 indicates that the AES instruction is not supported. Therefore, by introducing the bits representing the acceleration instructions which simultaneously support the adaptation of the source end and the target end, the types of the acceleration instructions which are commonly supported by the source end and the target end are further met, and the success rate and the migration efficiency of the virtual machine in the process of executing the live migration are further improved.

Meanwhile, the self-defined register refers to a function filled in the same register by each manufacturer, and the invention aims to ensure that the modified virtual hardware can simultaneously support the hot migration operation of the virtual machine in the heterogeneous environment after being created. Specifically, if the manufacturer of the physical hardware as the source configures a virtualized hardware acceleration module (e.g., qemu-kvm) of the flyover 200 to create a virtual machine a1, and specifies a vCPU model as C; the virtualized hardware acceleration module (e.g., qemu-kvm) of the spread pen 920 configured by the physical hardware manufacturer as the target creates a virtual machine B1, and at this time, the register value intersection is called by the virtualized hardware acceleration module to create a virtual machine B1 in the target, and thus the virtual machines created in the target have the same kind of registers, and each register value is the same vCPU, that is, the vCPU with the model number C. At this time, the physical CPU in the target is virtualized to form virtual machine B1 whose vCPU already contains the same register value, thereby satisfying the subsequent requirement of performing live migration on virtual machine a1 and virtual machine B1 by the source and target. To this end, the creation of the virtual machine VM1 in the source physical machine 1 is completed in the virtual machine creation phase, and the virtual machine execution phase is entered. The virtual machine is created in the target end similarly.

Example two:

based on the technical solution of the migration method of the virtual machine disclosed in the first embodiment, the first embodiment further discloses a specific implementation manner of the migration method of the virtual machine, where the virtual machine executes a virtual machine live migration operation between two physical machines (i.e., physical machine 1 and physical machine 2 in fig. 2) with heterogeneous hardware.

With reference to fig. 1 to 3, 5 and 6, in this embodiment, a migration method of a virtual machine is used to perform migration between a source end and a target end for the virtual machine, and the migration method includes the following steps S21 to S25. The virtual machine VM1 has been created based on the virtual machine creation method disclosed in embodiment one, and this embodiment is intended to implement migration of the virtual machine VM1 in the physical machine 1 to the physical machine 2 through live migration and start up in the form of the virtual machine VM 2. In this embodiment, the virtual machines VM1\ VM2 in fig. 2 are understood as corresponding virtual machines before and after the live migration operation is performed.

Step S21, extracting register lists included in the physical hardware respectively configured by the source end and the target end.

Step S22, determining the same register included in the register list included in the physical hardware configured by the source end and the target end respectively. Specifically, the operation of extracting the register lists contained in the physical hardware respectively configured by the source end and the target end is executed by hypervisors of the nanotube source end and the target end, where the hypervisors include Hyper-V, Xen, Linux OS, or EXSi.

And step S23, extracting and storing the register value intersection formed by the same registers of the source end and the target end. The intersection of the register values is determined by the register values respectively possessed by the source terminal and the target terminal through Hypervisor execution binary AND operation. The applicant indicates that the specific implementation processes of step S21 to step S23 in this embodiment are shown in step S12 to step S14 in the first embodiment, and are not described herein again.

And step S24, writing the register value intersection into a simulation register of the virtual hardware, and calling the register value intersection through a virtualization hardware acceleration module (for example, qemu-kvm). The aforementioned writing of the register value intersection into the emulated register of the virtual hardware is also performed by Hypervisor.

The applicant takes an AIDR register included in a physical CPU of an ARMv8 architecture as an example, and shows the following codes to show that reading and writing the virtual machine and simulating the value of the AIDR register, specifically as follows:

therefore, register values of the virtual machine VM1 already created by the source end (e.g. physical machine 1) and the target end (i.e. physical machine 2) adapted virtual machine VM1 are predefined to meet the requirement that the value of the AIDR register in the isomerization scene is prevented from being modified after the virtual machine VM1 is subjected to the live migration to the target end, so that instruction modification does not need to be performed after the virtual machine VM1 in the source end is subjected to the live migration to the target end, and the success rate of the live migration is ensured. Because, in the heterogeneous scenario, only the same register and the same register value contained in the source end and the target end can be identified by the virtual machine VM that has been created and run, and is directly called by the virtual machine VM2 after being migrated to the target end. In addition, the operation of writing the register value intersection into the simulation register of the virtual hardware is predefined before the virtual machine VM1 is executed by the hot migration operation, so that the interoperability and high availability of each physical machine in an isomerization scene are improved, the target end is not invaded by codes, and the stability of the cloud platform is ensured.

Step S25, creating a virtual machine to be migrated that is the same as the virtual machine to be migrated in the source end in the target end, writing the intersection of the register values into the simulation register of the virtual hardware of the target end, migrating and loading the virtual machine data to be migrated in the source end to the virtual machine to be migrated that has been created in the target end by the virtual machine migration system, and then closing the virtual machine to be migrated in the source end. The register value is described by one or any register value of a custom register, a page table register, a control register, a state register, a memory access register or a Cache register contained in physical hardware, wherein the physical hardware comprises a physical CPU or a physical GPU. The register value also includes bits that characterize the acceleration instructions that support both source and target adaptation.

Referring back to fig. 2, in the virtual machine running phase, the virtual machine VM2 to be migrated is created directly in the target and written to the emulated registers of the vCPU. When the Hypervisor performs the live migration on the virtual machine VM1, the virtual machine VM1 in the source side is not stopped, and the target side is directly operated from the emulated registers (e.g., emulated registers of the aforementioned vCPU) that have been written to the virtual hardware of the target side. Then, the virtual machine VM2 is started after resources such as storage resources, network resources, computing resources, rights to modify the shared directory, configuration files of the libvirtual, user names, passwords, and the like are configured for the virtual machine VM 2. The data in virtual machine VM1 is then copied directly to the memory of physical machine 2 in the memory occupied by physical machine 1. Finally, after the VM2 is pulled up and started, the VM1 in the source end is stopped, so that the whole live migration operation of the VM1 in the source end is completed. The migration method of the virtual machine disclosed by the embodiment can realize the execution of the live migration operation on the virtual machine in the heterogeneous scene, ensure that the service provided by the virtual machine to the outside is not interrupted, and ensure the high availability of the cloud platform and the continuity of the service.

Example three:

referring to FIG. 7, the present example discloses one embodiment of a computer readable medium 900. The computer-readable medium 900 has stored therein computer program instructions 901, and when the computer program instructions 901 are read and executed by a processor 902, the steps in the migration method of the virtual machine according to the first embodiment are performed. The migration method of the virtual machine in this embodiment has the same technical solutions as those in the second embodiment, please refer to the description of the second embodiment, which is not repeated herein.

The various illustrative logical blocks, or elements, described in connection with the embodiments disclosed herein may be implemented or performed with 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 thereof designed to perform the functions described herein. A general-purpose processor may be a microprocessor, but in the alternative, the processor may be any conventional processor, controller, microcontroller, or state machine. A processor may also be implemented as a combination of computing devices, e.g., a digital signal processor and a microprocessor, a plurality of microprocessors, one or more microprocessors in conjunction with a digital signal processor core, or any other similar configuration.

The above-listed detailed description is only a specific description of a possible embodiment of the present invention, and they are not intended to limit the scope of the present invention, and equivalent embodiments or modifications made without departing from the technical spirit of the present invention should be included in the scope of the present invention.

Furthermore, it should be understood that although the present description refers to embodiments, not every embodiment may contain only a single embodiment, and such description is for clarity only, and those skilled in the art should integrate the description, and the embodiments may be combined as appropriate to form other embodiments understood by those skilled in the art.

Claims

1. A virtual machine creation method, comprising:

acquiring a virtual machine creation request;

2. The method of claim 1, wherein the intersection of register values is determined by binary and operations of register values respectively owned by the source and target.

3. The method according to claim 1, wherein the register value is described by one or any several register values of a custom register, a page table register, a control register, a status register, a memory access register, or a Cache register included in physical hardware, wherein the physical hardware includes a physical CPU or a physical GPU.

4. The method of claim 1, wherein the register value further comprises a bit characterizing simultaneous support of source and target adapted acceleration instructions.

5. A migration method of a virtual machine, configured to perform migration on the virtual machine between a source end and a target end, the migration method comprising:

6. The migration method according to claim 5, wherein the operation of extracting the register lists contained in the physical hardware configured by the source end and the target end respectively is performed by hypervisors of the nanotube source end and the target end, and the hypervisors include Hyper-V, Xen, Linux OS, or EXSi.

7. The migration method according to claim 5, wherein the register value intersection is determined by binary AND operation performed by the Hypervisor from the register values respectively owned by the source and the target.

8. The migration method according to claim 5, wherein the register value is described by one or any several register values of a custom register, a page table register, a control register, a status register, a memory access register, or a Cache register included in physical hardware, wherein the physical hardware includes a physical CPU or a physical GPU.

9. The migration method of claim 5, wherein said register value further includes a bit characterizing simultaneous support of source and target adapted acceleration instructions.

10. A computer-readable medium comprising, in combination,

the computer-readable medium has stored therein computer program instructions which, when read and executed by a processor, perform the steps in the migration method of a virtual machine according to any one of claims 5 to 9.