CN114518933A - Method and system for realizing hot migration of virtual machine across CPUs (central processing units) - Google Patents

Abstract

The invention discloses a cross-CPU virtual machine hot migration implementation method and system, belonging to the field of cloud computing. The specific steps of the method are as follows: S1 configures the added computing node set that supports cross-CPU model hot migration; S2 according to The specified software and version automatically deploy the hypervisor Libvirt and other basic dependent software to the computing nodes in the cluster; S3 obtains the node CPU configuration information and performs adaptive calculation analysis; S4 automatically deploys the computing nodes in the cluster to initialize nova‑ compute service; for the method of hot migration of virtual machines between computing nodes of different CPU models, the hot migration function of virtual machines between computing nodes of different CPU models in the cloud management platform is realized in two scenarios: new deployment and new computing nodes in the existing cloud management platform .

Description

A method and system for implementing cross-CPU virtual machine hot migration

technical field

The invention discloses a cross-CPU virtual machine hot migration realization method and system, and relates to the technical field of cloud computing.

Background technique

At present, most cloud computing and cloud service providers rely on the open source project OpenStack as the basic cloud management platform to realize the deployment and management of public and private clouds. The OpenStack Nova component, as the core component of the OpenStack project, is used to provide cloud platform computing capabilities. A conventional cloud computing cluster generally consists of management nodes, computing nodes and storage nodes. Compute nodes deploy OpenStack Nova-Compute service-related services based on physical machines to provide upper-layer computing management services for virtual machines. At the bottom layer of Nova-Compute service, different virtual machine management tools are called to manage kernel KVM, Xen, VMware ESX, QEMU and other virtualization technologies. This article takes Libvirt as an example to call the kernel KVM to manage virtual machines in the cloud platform.

As the scale of the cluster continues to expand and the complexity of the business increases, the cluster may contain computing node physical machines with different CPU models. In this case, it is generally possible to implement mutual hot migration between virtual machines in the same host aggregation by dividing physical machines of the same type into the same host aggregation. However, the host aggregation contains not only the attribute information of the CPU model. With the continuous refinement of the host aggregation information, a large number of host aggregations must be planned, which increases the maintenance cost. If the cluster scale is small, the refined host aggregation will As a result, the number of hosts in each aggregate is small, and the role of classification is lost. Therefore, in actual production, CPU information is generally not added to the host aggregation as an attribute, which leads to the possibility of computing nodes with different CPU models in the same host aggregation. When performing live migration of a virtual machine, the Nova-Compute service will call the Libvirt compareCPU API to verify whether the features of the virtual machine can be migrated to the target computing node. As a result, two computing nodes with different CPU models may fail to live migrate.

The virtual machine live migration function is affected by the configuration of the virtual machine startup file. Libvirt mainly supports three CPU modes: host-passthrough, host-model and custom. Theoretically speaking, host-passthrough mode requires that the instruction sets of the source node and destination node are exactly the same; host-model mode allows slight differences in the instruction sets of the source node and destination node; custom mode allows the source node and destination node to have larger instruction sets. Difference (subject to the actual configuration of the virtual machine startup xml file). When there is no live migration scenario, it is recommended to select the host-passthrough mode; for the host-model mode, if different models of CPUs can be divided by host aggregation, the host aggregation filter can be used during migration to match the physical machines of the same model; when When there are too many CPU models and it is inconvenient to divide by host aggregation, it is recommended to use the custom mode. When using the custom mode, the specified CPU model and required/disabled CPU features need to be displayed. However, the model types and physical machine CPU features supported by different host CPU models are different. How to automatically and accurately select and configure the CPU model and CPU features become. increasingly important.

The cpu_mode, cpu_models, and cpu_model_extra_flags parameters in the OpenStack computing service Nova-Compute configuration file libvirt group can be configured, corresponding to the mode attribute, domain/cpu/model and domain/cpu/model/feature configuration in domain/cpu in the virtual machine configuration xml configuration file. By adding the above three configurations, specify the CPU-related configuration when the virtual machine starts.

The present invention mainly aims at the above problems, and provides a method and system for realizing cross-CPU virtual machine hot migration.

SUMMARY OF THE INVENTION

Aiming at the problems in the prior art, the present invention provides a method and system for implementing cross-CPU virtual machine hot migration. :

S1 configures the added set of computing nodes that support hot migration across CPU models;

S2 automatically deploys the hypervisor Libvirt and other basic dependent software to the computing nodes in the cluster according to the specified software and version;

S3 obtains node CPU configuration information, and performs adaptive calculation analysis;

S4 automatically deploys and initializes the nova-compute service on the computing nodes in the cluster.

The specific steps for configuring the added computing node set that supports cross-CPU model hot migration by the S1 are as follows:

S101 is connected to the cloud management platform deployed by OpenStack by configuring the computing node ip;

S102 connects to the computing node libvirt client and invokes the Libvirt command line to obtain node configuration information.

The specific steps of S3 acquiring the node CPU configuration information and performing adaptive calculation analysis are as follows:

S301 executes libvirt-qemu related APIs on the computing nodes in the set to obtain the node CPU configuration information;

The S301 configuration initialization program automatically obtains the relevant configuration xml files of the CPUs of all computing nodes in the cluster;

S302 parses the CPU xml file collected by the node and calculates the available CPU model and CPU features information adapted to the computing node set;

S303 synchronizes the parsed configuration to the Nova-Compute configuration file of each node in the set.

The S301 configuration initialization program calls virsh-c<compute-node-ip>domcapabilities or Libvirt API:getDomainCapabilities to obtain mod node information with name='host-model' under domainCapabilities/cpu of the target computing node and save it as an xml file.

Described S302 parses the CPU xml file collected by the node and calculates the specific steps of the available CPU model and CPU features information of the set of adaptive computing nodes as follows:

S3021 selects a minimum supported CPU model by combining the model name in the mode with name='host-model' in the xml file of each computing node in the cluster and the ordered CPU model list;

S3022, according to the features list in the xml file, calculates the set of public CPU features that can be supported by the computing nodes, and renders it into the corresponding CPU xml file;

S3023 checks whether the name of the model is within the minimum available model set selected by the computing node.

The S3023 checks whether the name of the model is in the minimum available model set selected by the computing node. If it is in the set, then by executing Libvirt API: CompareHypervisorCPU in each calculation, verify whether the constructed CPUxml file is suitable for each computing node. , to ensure that the configured model meets the requirements of each computing node.

The specific steps in S303 to synchronize the parsed configuration to the Nova-Compute configuration file of each node in the set are as follows:

S3031 verifies again whether the selected CPU model and features are available at each node in the set;

S3032 adds the selected CPU model and features configuration to the nova.conf configuration file and converts it into the cpu_mode, cpu_models and cpu_model_extra_flags configuration available for the nova-compute service.

The specific steps for S4 to automatically deploy and initialize the nova-compute service to the computing nodes in the cluster are as follows:

S401 converts the model and features in the XML file into the corresponding parameters in the nova-compute configuration file: cpu_mode, cpu_models and cpu_model_extra_flags configurations are added to the nova.conf configuration file;

S402 is overwritten by the configuration distributor to /etc/nova/nova.conf and /etc/nova/nova-compute.conf in each computing node in the set to complete the initialization of the nova-compute configuration file.

A method for implementing cross-CPU virtual machine hot migration, the system specifically includes a node configuration module, a node deployment module, a data processing module and a service deployment module:

Node configuration module: configure the added set of computing nodes that support hot migration across CPU models;

Node deployment module: Automatically deploy the hypervisor Libvirt and other basic dependent software to the computing nodes in the cluster according to the specified software and version;

Data processing module: Obtain node CPU configuration information, and perform adaptive calculation analysis;

Service deployment module: Automatically deploy and initialize the nova-compute service for computing nodes in the cluster.

The beneficial effects of the present invention are as follows: the method of the present invention is aimed at the method of hot migration of virtual machines between computing nodes of different CPU models, and realizes the computing of different CPU models in the cloud management platform under two scenarios of new deployment and new computing nodes of the existing cloud management platform. Virtual machine live migration function between nodes. On the one hand, it can simplify the host aggregation attributes (without adding CPU model information to the host aggregation method, that is, the same CPU model is assigned to the same host aggregation method to avoid the problem of hot migration failure due to different CPU models), and at the same time, it improves the flexibility of virtual machine hot migration. sex.

Description of drawings

In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the following briefly introduces the accompanying drawings that need to be used in the description of the embodiments or the prior art. Obviously, the accompanying drawings in the following description These are some embodiments of the present invention. For those of ordinary skill in the art, other drawings can also be obtained based on these drawings without any creative effort.

FIG. 1 is a schematic diagram of a call chain flow in a cloud management platform scenario in an embodiment; FIG. 2 is a schematic diagram of an implementation mechanism of configuration initialization in an embodiment; and FIG. 3 is a flowchart of the method of the present invention.

Detailed ways

The present invention will be further described below with reference to the accompanying drawings and specific embodiments, so that those skilled in the art can better understand the present invention and implement it, but the embodiments are not intended to limit the present invention.

Example 1:

A cross-CPU virtual machine hot migration implementation method, the specific steps of the method are as follows:

S1 configures the added set of computing nodes that support hot migration across CPU models;

S2 automatically deploys the hypervisor Libvirt and other basic dependent software to the computing nodes in the cluster according to the specified software and version;

S3 obtains node CPU configuration information, and performs adaptive calculation analysis;

S4 automatically deploys and initializes the nova-compute service to the computing nodes in the cluster;

First, according to the S1 configuration, you need to join the computing node set that supports cross-CPU model hot migration, and you can add computing nodes with different CPU attributes (suitable for new cloud management platforms or expansion of existing cloud management platforms). The computing node automatically deploys the hypervisor Libvirt and other basic dependent software (kvm, qemu, openvswitch, etc.) according to the specified software source and version;

Then, obtain the node CPU configuration information according to S3, and perform adaptive calculation analysis; finally, initialize the nova-compute service according to the automatic deployment of computing nodes in the cluster, use the CPU configuration parsed by S3 to start the nova-compute service, and complete the initialization of the computing node nova service ;

As shown in Figure 1, for the new cloud management platform, first initialize the Libvirt service of each computing node; after the Libvirt service is successfully started, call the configuration initialization system to initialize the Nova-Compute service configuration file of each computing node; finally complete the Nova-Compute service startup . For the expansion of existing computing nodes, first initialize the Libvirt service of the new expansion computing node; after the Libvirt service is successfully started, call the configuration initialization system to initialize the computing nodes to be merged into the host aggregation related computing nodes and the new expansion computing node Nova-Compute service configuration file; finally Complete the above-mentioned computing node Nova-Compute service startup;

Further, the specific steps of configuring the added computing node set that supports cross-CPU model hot migration by the S1 are as follows:

S101 is connected to the cloud management platform deployed by OpenStack by configuring the computing node ip;

S102 connects to the computing node libvirt client and calls the Libvirt command line to obtain node configuration information;

In the cloud management platform deployed by OpenStack, by configuring the computing node ip, it can connect to the computing node libvirt client and call the Libvirt command line to obtain the node configuration information;

The specific steps of S3 acquiring the node CPU configuration information and performing adaptive calculation analysis are as follows:

S301 executes libvirt-qemu related APIs on the computing nodes in the set to obtain the node CPU configuration information;

The S301 configuration initialization program automatically obtains the relevant configuration xml files of the CPUs of all computing nodes in the cluster;

S302 parses the CPU xml file collected by the node and calculates the available CPU model and CPU features information adapted to the computing node set;

S303 synchronizes the parsed configuration to the Nova-Compute configuration file of each node in the collection;

As shown in Figure 2, this method can automatically obtain the CPU-related configurations of all computing nodes in the cluster through the configuration initialization program after the hypervisor is successfully initialized, and parse the CPU configurations applicable to all computing nodes in the cluster, and adapt to each In the Nova-Compute configuration file of the computing node; when adding a computing node to an existing cloud management platform, you can configure the name of the new computing node and the corresponding host aggregation or the mapping of the existing computing node set to collect and map the computing node set in the map. Parse the CPU configuration and distribute it to the computing nodes in the set by the configuration distributor, so as to realize the mutual hot migration of the virtual machines of the computing nodes in the mapping set;

The S301 configuration initialization program calls virsh-c<compute-node-ip>domcapabilities or Libvirt API:getDomainCapabilities to obtain the mod node information of name='host-model' under the target computing node domainCapabilities/cpu and save it as an xml file;

By calling the Libvirt API: Libvirt API:getDomainCapabilities to obtain the mode of name='custom' under domainCapabilities/cpu in the domcapabilities of each computing node in the collection, and get the model of the node usable='yes', that is, example 1; at the same time, obtain the mode under domainCapabilities/cpu The name of the model and the information in the mode in the mode node with name='host-model' are example 2; while processing xml and adding the schema information and saving it as an xml file, that is example 3;

Example one:

<mode name='custom'supported='yes'>

<model usable='no'>qemu64</model>

<model usable='yes'>qemu32</model>

<model usable='no'>phenom</model>

<model usable='yes'>pentium3</model>

<model usable='yes'>pentium2</model>

<model usable='yes'>pentium</model>

<model usable='yes'>n270</model>

<model usable='yes'>kvm64</model>

<model usable='yes'>kvm32</model>

<model usable='yes'>coreduo</model>

<model usable='yes'>core2duo</model>

<model usable='no'>athlon</model>

<model usable='yes'>Westmere-IBRS</model>

<model usable='yes'>Westmere</model>

<model usable='yes'>Skylake-Server-noTSX-IBRS</model>

<model usable='yes'>Skylake-Server-IBRS</model>

<model usable='yes'>Skylake-Server</model>

<model usable='yes'>Skylake-Client-noTSX-IBRS</model>

<model usable='yes'>Skylake-Client-IBRS</model>

<model usable='yes'>Skylake-Client</model>

<model usable='yes'>SandyBridge-IBRS</model>

<model usable='yes'>SandyBridge</model>

<model usable='yes'>Penryn</model>

<model usable='no'>Opteron_G5</model>

<model usable='no'>Opteron_G4</model>

<model usable='no'>Opteron_G3</model>

<model usable='no'>Opteron_G2</model>

<model usable='yes'>Opteron_G1</model>

<model usable='yes'>Nehalem-IBRS</model>

<model usable='yes'>Nehalem</model>

<model usable='yes'>IvyBridge-IBRS</model>

<model usable='yes'>IvyBridge</model>

<model usable='no'>Icelake-Server-noTSX</model>

<model usable='no'>Icelake-Server</model>

<model usable='no'>Icelake-Client-noTSX</model>

<model usable='no'>Icelake-Client</model>

<model usable='yes'>Haswell-noTSX-IBRS</model>

<model usable='yes'>Haswell-noTSX</model>

<model usable='yes'>Haswell-IBRS</model>

<model usable='yes'>Haswell</model>

<model usable='no'>EPYC-Rome</model>

<model usable='no'>EPYC-IBPB</model>

<model usable='no'>EPYC</model>

<model usable='no'>Dhyana</model>

<model usable='yes'>Conroe</model>

<model usable='no'>Cascadelake-Server-noTSX</model>

<model usable='no'>Cascadelake-Server</model>

<model usable='yes'>Broadwell-noTSX-IBRS</model>

<model usable='yes'>Broadwell-noTSX</model>

<model usable='yes'>Broadwell-IBRS</model>

<model usable='yes'>Broadwell</model>

<model usable='yes'>486</model>

</mode>

Example two:

<mode name='host-model' supported='yes'>

<model fallback='forbid'>Cascadelake-Server</model>

<vendor>Intel</vendor>

<feature policy='require'name='ss'/>

<feature policy='require'name='hypervisor'/>

<feature policy='require'name='tsc_adjust'/>

<feature policy='require'name='pku'/>

<feature policy='require'name='md-clear'/>

<feature policy='require'name='stibp'/>

<feature policy='require'name='xsaves'/>

<feature policy='require'name='invtsc'/>

<feature policy='disable'name='avx512vnni'/>

</mode>

Example three:

<cpu>

<arch>x86_64</arch>

<model fallback='forbid'>Cascadelake-Server</model>

<vendor>Intel</vendor>

<feature policy='require'name='ss'/>

<feature policy='require'name='hypervisor'/>

<feature policy='require'name='tsc_adjust'/>

<feature policy='require'name='pku'/>

<feature policy='require'name='md-clear'/>

<feature policy='require'name='stibp'/>

<feature policy='require'name='xsaves'/>

<feature policy='require'name='invtsc'/>

<feature policy='disable'name='avx512vnni'/>

</cpu>

Described S302 parses the CPU xml file collected by the node and calculates the specific steps of the available CPU model and CPU features information of the set of adaptive computing nodes as follows:

S3021 selects a minimum supported CPU model by combining the model name in the mode with name='host-model' in the xml file of each computing node in the cluster and the ordered CPU model list;

S3022, according to the features list in the xml file, calculates the set of common CPU features that can be supported by the computing nodes, and renders it into the corresponding CPU xml file;

S3023 checks whether the name of the model is in the minimum available model set selected by the computing node;

According to the model information of each computing node usable='yes' in the set reported by the data collector, calculate the minimum available model set that can be matched by the computing nodes in the set;

At the same time, the data analyzer will maintain an ordered list of CPU models (representing CPU release time and performance) according to different CPU appearance years;

The data analyzer executes the Libvirt API on the corresponding computing node according to the CPU xml file of each computing node reported by the data collector: All features supported by the BaselineHypervisor CPU extension node, that is, Example 4;

Example four:

<cpu mode='custom' match='exact'>

<model fallback='forbid'>Cascadelake-Server</model>

<vendor>Intel</vendor>

<feature policy='require'name='3dnowprefetch'/>

<feature policy='require'name='abm'/>

<feature policy='require'name='adx'/>

<feature policy='require'name='aes'/>

<feature policy='require'name='apic'/>

<feature policy='require'name='arat'/>

<feature policy='require'name='avx'/>

<feature policy='require'name='avx2'/>

<feature policy='require'name='avx512bw'/>

<feature policy='require'name='avx512cd'/>

<feature policy='require'name='avx512dq'/>

<feature policy='require'name='avx512f'/>

<feature policy='require'name='avx512vl'/>

<feature policy='disable'name='avx512vnni'/>

<feature policy='require'name='bmi1'/>

<feature policy='require'name='bmi2'/>

<feature policy='require'name='clflush'/>

<feature policy='require'name='clflushopt'/>

<feature policy='require'name='clwb'/>

<feature policy='require'name='cmov'/>

<feature policy='require'name='cx16'/>

<feature policy='require'name='cx8'/>

<feature policy='require'name='de'/>

<feature policy='require'name='erms'/>

<feature policy='require'name='f16c'/>

<feature policy='require'name='fma'/>

<feature policy='require'name='fpu'/>

<feature policy='require'name='fsgsbase'/>

<feature policy='require'name='fxsr'/>

<feature policy='require'name='hle'/>

<feature policy='require'name='hypervisor'/>

<feature policy='require'name='invpcid'/>

<feature policy='require'name='invtsc'/>

<feature policy='require'name='lahf_lm'/>

<feature policy='require'name='lm'/>

<feature policy='require'name='mca'/>

<feature policy='require'name='mce'/>

<feature policy='require'name='md-clear'/>

<feature policy='require'name='mmx'/>

<feature policy='require'name='movbe'/>

<feature policy='require'name='mpx'/>

<feature policy='require'name='msr'/>

<feature policy='require'name='mtrr'/>

<feature policy='require'name='nx'/>

<feature policy='require'name='pae'/>

<feature policy='require'name='pat'/>

<feature policy='require'name='pcid'/>

<feature policy='require'name='pclmuldq'/>

<feature policy='require'name='pdpe1gb'/>

<feature policy='require'name='pge'/>

<feature policy='require'name='pku'/>

<feature policy='require'name='pni'/>

<feature policy='require'name='popcnt'/>

<feature policy='require'name='pse'/>

<feature policy='require'name='pse36'/>

<feature policy='require'name='rdrand'/>

<feature policy='require'name='rdseed'/>

<feature policy='require'name='rdtscp'/>

<feature policy='require'name='rtm'/>

<feature policy='require'name='sep'/>

<feature policy='require'name='smap'/>

<feature policy='require'name='smep'/>

<feature policy='require'name='spec-ctrl'/><feature policy='require'name='ss'/>

<feature policy='require'name='ssbd'/>

<feature policy='require'name='sse'/>

<feature policy='require'name='sse2'/>

<feature policy='require'name='sse4.1'/>

<feature policy='require'name='sse4.2'/>

<feature policy='require'name='ssse3'/>

<feature policy='require'name='stibp'/>

<feature policy='require'name='syscall'/>

<feature policy='require'name='tsc'/>

<feature policy='require'name='tsc-deadline'/>

<feature policy='require'name='tsc_adjust'/>

<feature policy='require'name='vme'/>

<feature policy='require'name='x2apic'/>

<feature policy='require'name='xgetbv1'/>

<feature policy='require'name='xsave'/>

<feature policy='require'name='xsavec'/>

<feature policy='require'name='xsaveopt'/>

<feature policy='require'name='xsaves'/>

</cpu>

Further, the S3023 checks whether the name of the model is in the minimum available model set selected by the computing node, if in the set, then by executing Libvirt API: CompareHypervisorCPU in each calculation, verify whether the constructed CPU xml file is suitable. For each computing node, ensure that the configured model meets the requirements of each computing node;

Further, the specific steps in S303 to synchronize the parsed configuration to the Nova-Compute configuration file of each node in the set are as follows:

S3031 verifies again whether the selected CPU model and features are available at each node in the set;

S3032 adds the selected CPU model and features configuration and converts the available nova-compute service into cpu_mode, cpu_models and cpu_model_extra_flags configuration file to the nova.conf configuration file;

Still further, the specific steps for the S4 to automatically deploy and initialize the nova-compute service to the computing nodes in the cluster are as follows:

S401 converts the model and features in the XML file into the corresponding parameters in the nova-compute configuration file: cpu_mode, cpu_models and cpu_model_extra_flags configurations are added to the nova.conf configuration file;

S402 is overwritten by the configuration distributor to /etc/nova/nova.conf and /etc/nova/nova-compute.conf in each computing node in the set to complete the initialization of the nova-compute configuration file.

Embodiment 2:

A method for implementing cross-CPU virtual machine hot migration, the system specifically includes a node configuration module, a node deployment module, a data processing module and a service deployment module:

Node configuration module: configure the added set of computing nodes that support hot migration across CPU models;

Node deployment module: According to the specified software and version, the virtual machine management program Libvirt and other basic dependent software are automatically deployed to the computing nodes in the cluster;

Data processing module: Obtain node CPU configuration information, and perform adaptive calculation analysis;

Service deployment module: Automatically deploy and initialize the nova-compute service for computing nodes in the cluster.

Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, but not to limit them; although the present invention has been described in detail with reference to the foregoing embodiments, those of ordinary skill in the art should understand that it can still be The technical solutions described in the foregoing embodiments are modified, or some technical features thereof are equivalently replaced; and these modifications or replacements do not make the essence of the corresponding technical solutions deviate from the spirit and scope of the technical solutions of the embodiments of the present invention.

Claims (9)

1. A method for realizing the hot migration of a virtual machine across CPUs is characterized by comprising the following steps:

s1, configuring the added computing node set supporting the cross-CPU model thermal migration;

s2, automatically deploying a virtual machine management program Libvirt and other basic dependent software for the computing nodes in the cluster according to the specified software and version;

s3, acquiring the configuration information of the node CPU, and performing adaptive calculation analysis;

s4 initializes the nova-computer service for automated deployment of computing nodes within the cluster.

2. The method as claimed in claim 1, wherein said step S1 of configuring the joined set of compute nodes supporting cross-CPU model hot migration comprises the following steps:

s101, the IP docking is carried out on a cloud management platform deployed by OpenStack through a configuration computing node;

s102 is connected with a Libvirt client of the computing node and calls a Libvirt command line to acquire node configuration information.

3. The method as claimed in claim 2, wherein the step of S3 obtaining node CPU configuration information and performing adaptive computation analysis comprises the following steps:

s301, executing Libvirt-qemu related APIs on the computing nodes in the set to acquire node CPU configuration information;

s301, configuring an initialization program to automatically acquire related configuration xml files of all the computing node CPUs of the cluster;

s302, analyzing the CPU xml file collected by the node and calculating available CPU models and CPU features information of the adaptive computing node set;

s303, synchronizing the parsed configuration to the Nova-computer configuration file of each node in the set.

4. The method as claimed in claim 3, wherein the S301 configuration initialization program calls a virsh-c < computer-node-ip > domcapabilities or Libvirt API, getDomainCapabilities obtains mod node information of name-host-model' under target computing node domainCapabilities/cpu and saves as xml file.

5. The method as claimed in claim 5, wherein the step of S302 parsing the CPU xml file collected by the node and calculating the available CPU models and CPU features information of the adapted computing node set comprises the following steps:

s3021 selecting a supportable lowest-configuration CPU model by combining the model name in the model of 'host-model' in the xml file of each computing node in the cluster with the ordered CPU model list;

s3022, calculating a public CPU features set which can be supported by the computing nodes according to the features list in the xml file, and rendering the common CPU features set to a corresponding CPU xml file;

s3023 checks whether the name of the model is within the smallest available set of models selected by the compute node.

6. The method as claimed in claim 5, wherein said S3023 checks whether the name of the model is in the minimum available model set selected by the compute node, and if so, by performing Libvirt API at each compute: and the CompareHypervisor CPU verifies whether the constructed CPU xml file is matched with each computing node or not, and ensures that the configured model meets the requirements of each computing node.

7. The method as claimed in claim 6, wherein the step of S303 synchronizing the parsed configuration to the Nova-computer configuration files of the nodes in the set comprises:

s3031, verifying whether the selected CPU model and features are available again at each node in the set;

s3032 adds the selected CPU model and features configuration and converts the CPU _ models, CPU _ models and CPU _ model _ extra _ flags configurations available for the nova-computer service into the nova.

8. The method as claimed in claim 7, wherein the step of S4 automatically deploying the initialization nova-computer service to the computing nodes in the cluster comprises:

s401, converting the model and features in the XML file into corresponding parameters in the nova-computer configuration file: the cpu _ mode, cpu _ models and cpu _ model _ extra _ flags configuration are added to the nova.conf configuration file;

s402, the configuration distributor covers/etc/nova/nova.conf and/etc/nova/nova-computer.conf in each computing node in the set, and the initialization of the nova-computer configuration file is completed.

9. A method for realizing the hot migration of a virtual machine across CPUs is characterized in that the system specifically comprises a node configuration module, a node deployment module, a data processing module and a service deployment module:

a node configuration module: configuring a set of added computing nodes supporting cross-CPU model thermal migration;

a node deployment module: automatically deploying a virtual machine management program Libvirt and other basic dependent software for the computing nodes in the cluster according to the specified software and version;

a data processing module: acquiring node CPU configuration information, and performing adaptive calculation analysis;

a service deployment module: and automatically deploying and initializing nova-computer service for the computing nodes in the cluster.

Images