Virtual resource pool construction method and management method of cross-instruction-set architecture

Abstract

The invention provides a virtual resource pool construction method and management method of a cross-instruction-set architecture. According to the method, an OpenStack component is reconstructed to adapt to an ARM architecture, a security environment is constructed by utilizing TrustZone, and unified integration, security isolation and automatic operation and maintenance of X86 / ARM heterogeneous resources are realized based on an Overlay network and an intelligent scheduling algorithm, so that the problems of heterogeneous compatibility, resource scheduling and security management are solved, and the resource utilization rate and the operation and maintenance efficiency are improved.

Description

Technical Field

[0001] The embodiments disclosed herein belong to the field of virtualization resource pools, specifically relating to a method for constructing and managing a virtualization resource pool across instruction set architectures. Background Technology

[0002] A virtualized resource pool is a logically manageable pool of resources abstracted and integrated from physical hardware to achieve on-demand allocation and efficient utilization of computing, storage, and network resources. With the rapid development of cloud computing and big data technologies, resource pools based on a single instruction set architecture (such as x86) are no longer sufficient to meet the computing power demands of diverse application scenarios. The ARM (Advanced RISC Machine) architecture has gained widespread application due to its low power consumption, high performance, and the need for domestic production. Therefore, building hybrid virtualized resource pools that integrate heterogeneous instruction set architectures such as x86 and ARM has become a trend.

[0003] Existing technical solutions are mainly designed for homogeneous hardware environments. When applied to heterogeneous architectures, they face the following challenges: there are instruction set compatibility barriers between computing nodes of different architectures, making it difficult to achieve unified virtualization management and scheduling; communication efficiency between heterogeneous resources is low, and there is a lack of efficient and load-balanced resource allocation strategies, which severely restricts the dynamic expansion capability of hybrid resource pools.

[0004] Therefore, developing a method for constructing and managing virtualization resource pools across instruction set architectures has become a critical issue that urgently needs to be addressed in the field of virtualization technology. Summary of the Invention

[0005] The embodiments disclosed herein aim to at least solve one of the technical problems existing in the prior art, and provide a method and system for optimizing the cost of high-temperature thermal storage materials.

[0006] One aspect of the embodiments of this disclosure provides a method for constructing a virtualized resource pool across instruction set architectures, comprising: Utilize OpenStack cloud management software to build a hybrid virtualization resource pool that integrates x86 and ARM architectures; The Nova computing module was restructured to adapt its performance to ARM architecture nodes; this performance adaptation for ARM architecture nodes includes improvements to CPU virtualization, memory virtualization, and I / O device virtualization. A secure environment is built based on the ARM TrustZone hardware security features, providing a hardware-level trusted execution environment and sensitive information storage for computing nodes; Utilize OpenStack Neutron network components to build a unified overlay virtual network, shielding the differences between the underlying x86 and ARM architectures, and enabling cross-architecture virtual machine communication; The resource mapping and allocation module enables unified information exchange and intelligent scheduling of heterogeneous resources.

[0007] Furthermore, the performance adaptation for ARM architecture nodes includes: A lightweight Hypervisor is used in the EL2 privilege layer, and ARM-assisted virtualization extensions are used to perform hierarchical control of virtual machine permissions. The system uses ARM's system memory management unit and Stage-2 hardware address translation function to manage memory mapping, and introduces KSM memory page sharing and dynamic compression technology; Improve network and storage I / O performance by using VFIO passthrough or optimizing the virtio backend driver.

[0008] Furthermore, the construction of the secure environment based on the ARM TrustZone hardware security features includes: The ARM TrustZone is used to divide the processor into a normal world and a secure world. A trusted execution environment is run in the secure world through the OP-TEE framework. The secure memory area is independently managed by hardware protection, and all operations on sensitive information are restricted in the secure world.

[0009] Furthermore, the construction of the unified overlay virtual network includes: By decoupling network traffic from the underlying hardware architecture through VXLAN technology and forwarding packets based on standard network identifiers, X86 and ARM virtual machines located in the same virtual network can communicate directly.

[0010] Furthermore, the resource mapping and allocation module includes a dynamic resource mapping mechanism and an efficient resource allocation mechanism; The dynamic resource mapping mechanism includes: tagging the operating system image in the Glance image service with an architecture tag, and having the Nova scheduler automatically match it to the computing node of the corresponding architecture based on the tag; The efficient resource allocation mechanism includes: using an LSTM-based load prediction algorithm for resource collaborative scheduling, and using a NUMA distance-based load balancing algorithm to optimize task placement.

[0011] Another aspect of the embodiments of this disclosure provides a method for managing virtualization resource pools across instruction set architectures, for managing virtualization resource pools constructed by the construction method described above, including: The simulation management module enables simulation and rapid deployment of nodes, links, and topology. The security management module enables secure isolation, access control, and unified lifecycle management of sensitive data and services. The hardware network resources are integrated through the network and access management module, and virtual network configuration and traffic control are performed. The resource management module enables unified orchestration and full lifecycle management of computing, network, and storage resources based on resource requirements, historical load, and NUMA distance factors.

[0012] Furthermore, the simulation management module is configured as follows: By using a unified topology description language and adaptation layer, node and link requirements are transformed into configuration instructions for the underlying virtual network and computing resources, thus shielding the differences in the underlying instruction set architecture.

[0013] Furthermore, the security management module is configured as follows: Customize Neutron security group policies and use iptables or Open vSwitch flow table rules to isolate tenant networks; Combine TrustZone with OP-TEE to deploy security-sensitive tasks in a secure world.

[0014] Furthermore, the network and access management module is configured as follows: Provides an entry point for topology creation and management through a graphical interface; The integrated SDN controller automatically configures the overlay virtual network using VLAN / VXLAN technology.

[0015] Furthermore, the resource management module is configured as follows: By tagging computing resources with X86 or ARM architecture labels and configuring scheduling rules, we ensure that virtual machines are accurately created on physical machines with the corresponding instruction sets. Share CPU architecture and memory topology metadata through the OpenStack Placement API to perform unified cataloging of cross-pool resources.

[0016] This disclosure discloses a method for constructing and managing a virtualized resource pool across instruction set architectures. It achieves deep adaptation to the ARM architecture and unified abstraction of heterogeneous resources by reconstructing OpenStack core components. A hardware-level secure symbiotic environment is built based on TrustZone. Software-defined networking technology is used to shield underlying architectural differences and achieve unified network access. Combined with an intelligent dynamic scheduling algorithm based on LSTM prediction and NUMA awareness, and through the collaborative autonomy of four management modules—simulation, security, network, and resources—it achieves full-stack integrated and efficient management of heterogeneous computing power from the bottom layer (integration), middle layer (scheduling), to the top layer (operation and maintenance). This significantly improves the utilization rate, security, elastic scalability, and automated operation and maintenance level of the resource pool, laying a solid foundation for building an efficient, secure, and autonomous next-generation cloud data center. Attached Figure Description

[0017] Figure 1 This is a flowchart illustrating a method for constructing a virtualized resource pool across instruction set architectures according to an embodiment of this disclosure. Figure 2 This is a flowchart illustrating a virtualization resource pool management method across instruction set architectures, which is another embodiment of this disclosure. Detailed Implementation

[0018] To enable those skilled in the art to better understand the technical solutions of this disclosure, the disclosure will be further described in detail below with reference to the accompanying drawings and specific embodiments.

[0019] like Figure 1 As shown, one embodiment of this disclosure provides a method for constructing a virtualization resource pool across instruction set architectures, the method comprising: Step S11: Use OpenStack cloud management software to build a hybrid virtualization resource pool that integrates X86 and ARM architectures.

[0020] Specifically, a unified OpenStack cloud platform framework capable of managing heterogeneous computing nodes is constructed. First, core OpenStack services are deployed and configured on the control node, including Keystone (authentication), Nova (compute), Neutron (networking), Glance (images), and Placement (resource placement). A key configuration is the Nova service; in the nova.conf configuration file, the compute_driver option specifies the driver used to manage virtualization for different architectures. For x86 nodes, libvirt.LibvirtDriver is configured, and virt_type=kvm is set to leverage KVM (Kernel-based Virtual Machine) full virtualization and VT-x (Virtualization Technology for x86) hardware acceleration. For ARM nodes, libvirt.LibvirtDriver is also configured, but specific settings are required for the ARM architecture.

[0021] Secondly, deploy the Nova-Compute component and its dependent hypervisor (such as QEMU-KVM) on each physical server (compute node) of both x86 and ARM architectures. By modifying the nova.conf file on the compute node, different types of nodes are marked with architecture identifiers. For example, on x86 compute nodes, set [libvirt]cpu_mode=host-passthrough to fully utilize the x86_64 architecture; on ARM compute nodes, in addition to setting the corresponding CPU mode, [DEFAULT]compute_driver and related [libvirt] options are needed to ensure that an ARM-optimized virtualization backend is used. After each compute node starts the Nova-Compute service, it automatically registers with the Nova-Conductor service on the control node and reports its hardware information, including CPU architecture (such as x86_64 or aarch64), CPU topology, memory size, local storage, etc. The Placement service collects this information and forms a global resource inventory.

[0022] Next, users need to upload operating system images suitable for different instruction set architectures to the Glance service. For example, upload the CentOS image for x86 architecture and the Ubuntu ARM image for ARM architecture separately. When uploading the images or through subsequent operations, add specific metadata attributes (such as hw_architecture=x86_64 or hw_architecture=aarch64) to each image to identify the CPU architecture supported by that image. This metadata is crucial for the Nova scheduler to perform correct matching.

[0023] Finally, after deployment, verify the changes via the OpenStack command line or the Horizon console. Execute resource query commands (such as `openstack hypervisor list` and `openstack hypervisor show`). <id>The system should be able to correctly list all registered compute nodes and display their architecture information. A virtual machine creation test is then performed: A virtual machine is created using an image tagged with `hw_architecture=aarch64`. The Nova scheduler should automatically schedule it to an ARM architecture compute node; conversely, a virtual machine created using an x86 image should be scheduled to an x86 node. This process verifies that the hybrid resource pool has been successfully built and possesses basic architecture-aware scheduling capabilities.

[0024] Through the above step S11, a virtualized resource pool with heterogeneous underlying physical hardware and unified abstraction and management through OpenStack is constructed, providing a basic platform for subsequent architecture adaptation, security construction, network interconnection and resource scheduling.

[0025] Step S12: Reconstruct the Nova computing module and adapt it to the performance of the ARM architecture node.

[0026] Specifically, performance adaptation for ARM architecture nodes includes improvements to CPU virtualization, memory virtualization, and I / O device virtualization. This step aims to customize standard OpenStack Nova compute components to address the differences in virtualization implementation between ARM and x86 architectures, thereby improving the performance and efficiency of virtual machines on ARM nodes. It will focus on three core virtualization layers: CPU, memory, and I / O. 1. CPU virtualization architecture design utilizes virtualization extensions provided by ARMv8-A and higher architectures (such as the EL2 exception level). A customized lightweight hypervisor runs in the EL2 privileged layer and is responsible for managing hardware resources. The virtual machine kernel runs in EL1, and user-space applications run in EL0, thereby achieving strict permission hierarchy and isolation.

[0027] First, a lightweight KVM transformation is carried out. The standard KVM was originally designed for x86, so it needs to be trimmed and optimized. Unnecessary functional modules on the ARM platform (such as hardware emulation components unique to x86) are removed, and the virtualization code of the interrupt controller (GICv3 / GICv4) is rewritten to reduce system complexity and context switching latency.

[0028] Secondly, in the nova.conf configuration file of the Nova-Compute service, for ARM compute nodes, configure the Libvirt driver to use virt_type=kvm and cpu_mode=host-passthrough. This configuration allows virtual machines to directly use the host machine's ARM CPU features, avoiding unnecessary instruction translation and achieving near-native performance.

[0029] Finally, when launching QEMU via Libvirt, pass parameters optimized for the ARM architecture, such as enabling -enable-kvm to use KVM acceleration, and specifying machine types suitable for ARM virtualization, such as -machine virt.

[0030] 2. The memory virtualization technology solution utilizes the Stage-2 Translation hardware function of the ARM architecture. The hypervisor controls the Stage-2 page table, maintaining an independent mapping from the physical address space to the machine's physical address for each virtual machine, thus achieving memory isolation.

[0031] First, hardware address translation management is performed, with the underlying KVM for ARM and Libvirt driver automatically managing the Stage-2 page table without direct intervention at the Nova level, but it is necessary to ensure that the kernel and Hypervisor support this function.

[0032] Secondly, enable and optimize the KSM (Kernel Samepage Merging) service in the host kernel. This service periodically scans the memory pages of all virtual machines and merges pages with identical content into a shared "copy-on-write" page. This can significantly save memory in scenarios where multiple virtual machines are running the same operating system or application. When memory is tight, use kernel mechanisms such as zswap or zram to compress and store infrequently used memory pages in memory instead of directly swapping them out to the slow disk swap area, thereby quickly releasing memory while reducing I / O latency.

[0033] 3. Implement I / O device virtualization, providing two main I / O virtualization paths to adapt to application scenarios with different performance requirements.

[0034] Option 1: VFIO (Virtual Function I / O) passthrough, suitable for high-performance scenarios. Physical devices (such as high-performance network cards and GPUs) are directly allocated to the virtual machine for exclusive use. The `pci_passthrough:alias` attribute is set in the virtual machine's Flavor metadata. In the Nova-Compute node configuration, devices allowed for passthrough are specified via `pci_passthrough_whitelist`. Libvirt generates corresponding QEMU command-line arguments based on the configuration and uses the VFIO driver to directly map the devices to the virtual machine. This option relies on the IOMMU (Input / Output Memory Management Unit) to achieve safe DMA and interrupt remapping.

[0035] Option 2: Virtio semi-virtualization, suitable for general scenarios. An optimized Virtio front-end driver is installed in the virtual machine, while a high-efficiency back-end driver is implemented in the host machine (QEMU). This is an I / O protocol for collaboration between the hypervisor and the virtual machine, with lower performance overhead than full virtualization. The interrupt handling and data path of the Virtio back-end driver are customized and optimized for the ARM platform. The latest Virtio-net (network) and Virtio-blk (block storage) front-end drivers are pre-installed on the ARM virtual machine image or ensured to be compatible to provide stable and low-latency network and storage I / O performance.

[0036] By performing deep adaptation and optimization of the virtualization stack (KVM, QEMU, Libvirt) on which Nova relies for the ARM architecture through the above step S12, the computing efficiency, memory utilization and I / O throughput of virtual machines on ARM computing nodes are significantly improved, enabling them to meet the requirements of production-level workloads.

[0037] Step S13: Build a secure environment based on the ARM TrustZone hardware security features to provide a hardware-level trusted execution environment and sensitive information storage for computing nodes.

[0038] Specifically, leveraging the TrustZone security extension technology built into the ARM architecture, a hardware-enforced, isolated trusted execution environment is built for the ARM compute nodes in the hybrid resource pool. This environment protects the secure storage of sensitive information such as keys and ensures the isolated operation of critical security services. The specific implementation method is as follows: 1. The hardware resources of the ARM processor (including CPU cores, memory, interrupt controllers, etc.) are divided into two isolated worlds at the hardware level: the Normal World and the Secure World. The Normal World runs a general-purpose host operating system (such as Linux) and a hypervisor (such as KVM), responsible for hosting regular virtualization workloads; the Secure World runs a lightweight, highly secure trusted operating system, forming the foundation of the trusted execution environment.

[0039] First, during the bootloader (such as U-Boot) startup phase of the ARM compute node, the TrustZone hardware is configured and initialized, dividing the memory space between the secure world and the normal world (e.g., defining a secure memory region via a TZASC / TZMA controller). Second, an open-source trusted operating system, OP-TEE (Open Portable Trusted Execution Environment), is deployed in the secure world. OP-TEE is a TEE implementation designed specifically for ARM TrustZone and conforming to the GlobalPlatform standard. Finally, within the OP-TEE framework, specific trusted applications (TAs) are developed or deployed. These trusted applications run independently in the secure world, their code and data protected by hardware, and cannot be directly accessed by software in the normal world (including the host operating system or virtual machine).

[0040] 2. Utilize the Secure Storage feature provided by OP-TEE. This feature encrypts sensitive data (such as virtual machine encryption keys, digital certificates, access tokens, etc.) using a key derived from a hardware-unique key before storing it in the file system of the ordinary world or in the RPMB (Replay Protected Block) partition of eMMC. All decryption and operations on the encrypted data (such as signing and verifying signatures) are completed within the secure world. Applications in the ordinary world can only see a meaningless block of ciphertext data and cannot access the plaintext information, thus achieving confidentiality and integrity protection for sensitive information.

[0041] 3. Critical security logic such as identity authentication, key negotiation, and secure boot verification is encapsulated into independent Trusted Applications (TAs) and deployed within the OP-TEE in the secure world. When an application in the normal world (such as a component of OpenStack Nova or an application within a virtual machine) needs to perform sensitive operations, it cannot directly handle the keys. Instead, it must send the request to the secure world via a predefined Security Monitor Call (SMC) instruction. The monitor mode in the secure world captures this SMC instruction, performs a world context switch, and transfers control to the OP-TEE kernel. The OP-TEE kernel schedules the appropriate trusted application to handle the request; the entire process is completely transparent to the normal world.

[0042] 4. Integrate with the virtualization resource pool: Ensure that the entire boot process, from the bootloader to the host operating system kernel and then to the OP-TEE, is digitally signed and verified, building a complete trusted boot chain from the hardware root of trust to the secure world, preventing malware from being implanted during the boot phase; through the transfer mechanism of the hypervisor (such as KVM supporting ARM virtualization extensions), the TrustZone security state of the physical CPU can be mapped to a specific privileged virtual machine. This allows the virtual machine to directly interact with the OP-TEE in the secure world, providing a higher level of security services for its internal workloads, realizing a "virtual machine-level trusted execution environment".

[0043] Through step S13 above, a hardware-enforced security boundary is established on the ARM computing node. Even if the host operating system or hypervisor in the ordinary world is compromised, attackers cannot read or tamper with the protected keys and sensitive data in the secure world, nor can they interfere with the execution of security services. This greatly enhances the security baseline of the entire hybrid virtualization resource pool and provides a solid foundation for running security-sensitive workloads.

[0044] Step S14: Utilize the OpenStack Neutron network component to build a unified overlay virtual network, shielding the differences between the underlying x86 and ARM architectures, and enabling cross-architecture virtual machine communication.

[0045] Specifically, by leveraging OpenStack Neutron's network virtualization capabilities, a logically unified virtual network plane is built on top of heterogeneous x86 and ARM physical networks, thereby completely shielding the differences in the underlying hardware architecture and ensuring that virtual machines of different architectures can communicate seamlessly as if they were on the same physical network.

[0046] Deploy and configure Neutron Server and its related components (such as the ML2 plugin) on the OpenStack control node. On all compute nodes (regardless of x86 or ARM architecture), deploy a unified version and configuration of virtual switch software, such as Open vSwitch (OVS). OVS, as the executor of the data plane, is responsible for creating virtual switches on physical hosts and handling network traffic for virtual machines. In the Neutron ML2 plugin configuration, set VXLAN as the primary tunnel type (tenant_network_types = vxlan) and configure the range of the VXLAN network identifier (VNI). Simultaneously, specify OVS as the underlying mechanism driver (mechanism_drivers = openvswitch).

[0047] Virtual networks, subnets, and routers can be created using the Neutron API (Application Programming Interface) or the Horizon dashboard. These operations are logically abstracted, and users do not need to care whether the underlying system is an x86 or ARM server. For example, when creating a VXLAN type network named net-01, Neutron will assign it a unique VNI (such as 1001).

[0048] When a user selects to connect to the net-01 network when creating a virtual machine, Neutron will issue flow table rules through the Neutron Agent (such as ovs-agent) on the compute node. At virtual machine startup, Nova-Compute calls Libvirt and OVS to perform the following operations on the corresponding compute node: create a virtual network interface (such as a tap device) and connect it to the virtual machine's virtual network card; create a port on the OVS bridge (such as br-int) and associate it with the tap device.

[0049] In this way, the network traffic of the virtual machine will be connected to the virtual switching network constructed by OVS. This process is completely consistent on x86 and ARM nodes, shielding the differences in underlying virtualization technology and network card drivers.

[0050] In some embodiments, the specific communication process includes: 1. Suppose a virtual machine VM-A (IP: 10.0.0.10) running on an x86 node needs to communicate with a virtual machine VM-B (IP: 10.0.0.20) running on an ARM node. VM-A sends a data packet with a destination address of 10.0.0.20.

[0051] 2. The OVS bridge br-int on the x86 node receives this data packet and, according to the flow table rules issued by Neutron, identifies that the data packet needs to be sent to the VXLAN tunnel with VNI=1001.

[0052] 3. OVS encapsulates the raw Ethernet frame into a VXLAN / UDP / IP packet. The destination address of the outer IP header is the physical IP address of the ARM compute node. This encapsulation process is completely transparent to the virtual machine operating system.

[0053] 4. Data packets are routed to the target ARM computing node through the underlying physical network.

[0054] 5. After receiving the VXLAN packet, the OVS on the ARM node decapsulates it and extracts the original Ethernet frame inside.

[0055] 6. OVS queries the flow table based on the destination MAC address or IP address of the internal frame, forwards it to the virtual port connected to VM-B, and finally delivers it to VM-B.

[0056] Throughout the communication path, OVS and Neutron only care about standard network metadata, such as VNI, IP address, and MAC address, and are completely unaware of whether the data packets come from an x86 virtual machine or an ARM virtual machine. The VXLAN tunnel directly connects the virtual switch ports on servers with different physical architectures, thus perfectly realizing transparent communication across architectures.

[0057] Neutron also provides a unified Security Group feature, which filters inbound and outbound traffic to virtual machines by configuring IP- and port-based firewall rules. These security policies are managed centrally by Neutron and enforced on their respective compute nodes through OVS flow tables or iptables rules, providing consistent security isolation for x86 and ARM virtual machines.

[0058] Through step S14 above, OpenStack Neutron successfully built a unified, software-defined network overlay on top of heterogeneous hardware pools. This not only enables seamless communication between virtual machines across architectures, but also provides flexible network orchestration capabilities and consistent security policies, allowing users to manage and use hybrid architecture resource pools in a completely homogeneous manner.

[0059] Step S15: Through the resource mapping and allocation module, perform unified information exchange and intelligent scheduling of heterogeneous resources.

[0060] Specifically, the resource mapping and allocation module includes a dynamic resource mapping mechanism and an efficient resource allocation mechanism.

[0061] 1. The dynamic resource mapping mechanism ensures that virtual machines can be created on the correct architecture nodes and understand the subtle differences between heterogeneous resources.

[0062] When users upload images to Glance, they must explicitly mark their required architecture using metadata such as hw_architecture=x86_64 or aarch64. Simultaneously, each Nova-Compute node automatically reports its CPU architecture attributes (such as CPU_ARCH=x86_64) when registering with the Placement service. When a user initiates a virtual machine creation request, the Nova-Scheduler first performs a "filtering" operation. It extracts the image's architecture tag and compares it with the architecture attributes of all compute nodes, automatically filtering out all nodes with mismatched architectures. For example, if an ARM image is requested, all x86 nodes will be immediately excluded, ensuring that the virtual machine will only be scheduled onto ARM nodes.

[0063] Within the Nova-Compute component, a lightweight "cross-architecture resource mapping middleware" is developed. This middleware obtains detailed topology information of the underlying hardware through the Libvirt API. For example, on x86 nodes, it obtains the distribution of NUMA (Non-Uniform Memory Access) nodes and CPU cache levels (L1 / L2 / L3); on ARM nodes, it similarly obtains their specific NUMA topology and cache structure. The middleware then converts the obtained heterogeneous hardware information into a unified standard resource descriptor. This descriptor includes not only the general number of vCPUs (Virtual CPUs) and memory size, but also the architecture type, NUMA affinity recommendations, and a computational equivalence coefficient derived from performance benchmarks (for finer-grained scheduling). This allows the scheduler to understand and compare the resource capabilities from nodes with different architectures using a consistent "language."

[0064] 2. The intelligent resource scheduling and allocation mechanism optimizes the efficiency and quality of resource allocation through algorithms, based on ensuring the correctness of resource mapping.

[0065] a. Resource Cooperative Scheduling Based on LSTM (Long Short-Term Memory) Load Prediction: Continuously collect historical load time-series data (such as CPU utilization) of vCPUs on each physical machine; train the historical data using an LSTM model, and utilize the forget gate, input gate, and output gate structure of LSTM to effectively capture the long-term periodicity and short-term fluctuation patterns of the load. The model outputs a prediction of the vCPU load in the next short term (e.g., a few minutes); when Nova-Scheduler selects a host for a new virtual machine, it not only considers the current idle resources but also combines the prediction results of LSTM. For example, it avoids scheduling new vCPUs to physical cores that are predicted to enter a high load phase, and instead prioritizes nodes with lower predicted load and that are idle, thereby achieving proactive resource avoidance and effectively reducing resource contention.

[0066] b. NUMA Distance-Based Load Balancing Algorithm: The algorithm first ensures that memory allocated to virtual machines comes from the same NUMA node as much as possible, guaranteeing optimal memory access performance. When multiple NUMA nodes meet the locality condition, the algorithm further considers NUMA topology distance, selecting nodes that are "closer" to the NUMA nodes of other active loads in the current system (e.g., within the same CPU socket, rather than across sockets or PCIe domains). This ensures both the performance of individual virtual machines (memory locality) and optimizes the potential communication efficiency between virtual machines (because communication latency between closer NUMA nodes is lower), thus achieving a balance between load balancing and low latency overall.

[0067] Step S15 above ensures the "correctness" of the matching between virtual machines and physical node architectures through a dynamic resource mapping mechanism; and achieves "efficiency" and "high quality" in resource allocation by integrating LSTM load prediction and NUMA distance-aware intelligent scheduling algorithms. These two aspects together constitute a unified and intelligent scheduling core for the heterogeneous resource pool, significantly improving resource utilization and application performance.

[0068] This disclosure discloses a method for constructing a virtualized resource pool across instruction set architectures. By reconstructing OpenStack core components to deeply adapt to the ARM architecture and building a hardware-level security environment based on TrustZone, it utilizes the Neutron Overlay network to unify and abstract the underlying heterogeneous network. Combined with dynamic resource mapping and intelligent scheduling algorithms, it achieves seamless integration and unified management of heterogeneous computing power between X86 and ARM.

[0069] like Figure 2 As shown, another embodiment of this disclosure provides a method for managing virtualization resource pools across instruction set architectures, used to manage virtualization resource pools constructed by the construction method described above. The management method includes: Step S21: Simulate and quickly deploy nodes, links, and topology using the simulation management module.

[0070] Specifically, the virtual network's required nodes, links, and overall topology are defined based on a unified topology description language (such as YAML or JSON format templates). The simulation management module automatically converts the abstract topology template into specific API call instructions for the underlying OpenStack Neutron and Nova services through a built-in adaptation layer, thereby achieving a unified network view simulation of heterogeneous hardware resources. This process shields the differences between the underlying X86 and ARM architectures, enabling rapid deployment and dynamic adjustment of complex topologies according to business needs, and persistently storing the simulation status and parameter values ​​in the simulation database.

[0071] Step S22: Perform security isolation, access control and unified lifecycle management of sensitive data and services through the security management module.

[0072] Specifically, leveraging the hardware security features of ARM TrustZone, security-sensitive tasks such as key management and identity authentication core logic are deployed in the secure OP-TEE trusted execution environment to achieve strong hardware-level isolation. In the ordinary world, by customizing the OpenStack Neutron security group policy distribution mechanism and utilizing iptables or Open vSwitch flow table rules, strict Layer 2 isolation and access control are provided for tenant networks with different security levels. The security management module performs unified configuration, deployment, monitoring, and lifecycle management of the above security policies, and audits the security status and access logs of the isolated zone in real time, dynamically responding to abnormal behavior.

[0073] Step S23: Integrate hardware network resources through the network and access management module, and perform virtual network configuration and traffic control.

[0074] Specifically, it integrates underlying physical network resources and utilizes Software-Defined Networking (SDN) technology. Through overlay networks such as VLAN (Virtual Local Area Network) and VXLAN (Virtual Extensible LAN) or SDN controllers, it enables flexible and programmable virtual network configuration and unified traffic policy management. This module provides two access methods: one is a user interface, which provides users with a unified entry point for virtual network creation and management through a self-developed graphical interface; the other is a device interface, which supports the flexible connection of physical devices or external nodes such as external subnets to the virtualization resource pool, realizing the convergence of virtual and physical networks.

[0075] Step S24: Through the resource management module, based on resource requirements, historical load and NUMA distance factors, perform unified orchestration and full lifecycle management of computing, network and storage resources.

[0076] Specifically, the resource management module shares resource metadata such as CPU architecture and memory topology from x86 and ARM nodes through the OpenStack Placement API to achieve unified cataloging of cross-pool resources. When allocating resources, the global scheduler comprehensively considers user resource needs, historical load trends based on LSTM network prediction, and NUMA topology distance to achieve intelligent placement and load balancing of virtual machines on heterogeneous nodes. During the virtual machine runtime, the module calls the underlying Hypervisor (KVM, etc.) through the Libvirt interface to perform the entire lifecycle operations of virtual machines, such as startup, migration, and shutdown, and tracks and optimizes the release of computing, storage, and network resources in real time through integrated monitoring agents (such as Prometheus Node Exporter).

[0077] This disclosure discloses a method for managing virtualized resource pools across instruction set architectures. Through a simulation management module, it achieves unified simulation and rapid deployment of heterogeneous topologies. The security management module achieves strong isolation and unified policy control of sensitive data based on hardware trust roots. The network and access management module achieves flexible networking and traffic control for virtual and physical integration. Through a resource management module, it achieves fine-grained orchestration and full lifecycle management of resources based on intelligent prediction and NUMA awareness. This enables automated, intelligent, and integrated operation and maintenance of large-scale heterogeneous resource pools.

[0078] It is understood that the above embodiments are merely exemplary embodiments used to illustrate the principles of this disclosure, and this disclosure is not limited thereto. For those skilled in the art, various modifications and improvements can be made without departing from the spirit and substance of this disclosure, and these modifications and improvements are also considered to be within the scope of protection of this disclosure.< / id>

Claims

1. A method for constructing a virtualized resource pool across instruction set architectures, characterized in that, The construction method includes: Utilize OpenStack cloud management software to build a hybrid virtualization resource pool that integrates x86 and ARM architectures; The Nova computing module was restructured to adapt its performance to ARM architecture nodes; this performance adaptation for ARM architecture nodes includes improvements to CPU virtualization, memory virtualization, and I / O device virtualization. A secure environment is built based on the ARM TrustZone hardware security features, providing a hardware-level trusted execution environment and sensitive information storage for computing nodes; Utilize OpenStack Neutron network components to build a unified overlay virtual network, shielding the differences between the underlying x86 and ARM architectures, and enabling cross-architecture virtual machine communication; The resource mapping and allocation module enables unified information exchange and intelligent scheduling of heterogeneous resources.

2. The construction method according to claim 1, characterized in that, The performance adaptation of ARM architecture nodes includes: A lightweight Hypervisor is used in the EL2 privilege layer, and ARM-assisted virtualization extensions are used to perform hierarchical control of virtual machine permissions. The system uses ARM's system memory management unit and Stage-2 hardware address translation function to manage memory mapping, and introduces KSM memory page sharing and dynamic compression technology; Improve network and storage I / O performance by using VFIO passthrough or optimizing the virtio backend driver.

3. The construction method according to claim 1, characterized in that, The security environment built based on the ARM TrustZone hardware security features includes: The ARM TrustZone is used to divide the processor into a normal world and a secure world. A trusted execution environment is run in the secure world through the OP-TEE framework. The secure memory area is independently managed by hardware protection, and all operations on sensitive information are restricted within the secure world.

4. The construction method according to claim 1, characterized in that, The construction of a unified overlay virtual network includes: By decoupling network traffic from the underlying hardware architecture through VXLAN technology and forwarding packets based on standard network identifiers, X86 and ARM virtual machines located in the same virtual network can communicate directly.

5. The construction method according to claim 1, characterized in that, The resource mapping and allocation module includes a dynamic resource mapping mechanism and an efficient resource allocation mechanism; The dynamic resource mapping mechanism includes: tagging the operating system image in the Glance image service with an architecture tag, and having the Nova scheduler automatically match it to the computing node of the corresponding architecture based on the tag; The efficient resource allocation mechanism includes: using an LSTM-based load prediction algorithm for resource collaborative scheduling, and using a NUMA distance-based load balancing algorithm to optimize task placement.

6. A method for managing a virtualization resource pool across instruction set architectures, used to manage a virtualization resource pool constructed by the construction method according to any one of claims 1 to 5, characterized in that, The management method includes: The simulation management module enables simulation and rapid deployment of nodes, links, and topology. The security management module enables secure isolation, access control, and unified lifecycle management of sensitive data and services. The hardware network resources are integrated through the network and access management module, and virtual network configuration and traffic control are performed. The resource management module enables unified orchestration and full lifecycle management of computing, network, and storage resources based on resource requirements, historical load, and NUMA distance factors.

7. The management method according to claim 6, characterized in that, The simulation management module is configured as follows: By using a unified topology description language and adaptation layer, node and link requirements are transformed into configuration instructions for the underlying virtual network and computing resources, thus shielding the differences in the underlying instruction set architecture.

8. The management method according to claim 6, characterized in that, The security management module is configured as follows: Customize Neutron security group policies and use iptables or Open vSwitch flow table rules to isolate tenant networks; Combine TrustZone with OP-TEE to deploy security-sensitive tasks in a secure world.

9. The management method according to claim 6, characterized in that, The network and access management module is configured as follows: Provides an entry point for topology creation and management through a graphical interface; The integrated SDN controller automatically configures the overlay virtual network using VLAN / VXLAN technology.

10. The management method according to claim 6, characterized in that, The resource management module is configured as follows: By tagging computing resources with X86 or ARM architecture labels and configuring scheduling rules, we ensure that virtual machines are accurately created on physical machines with the corresponding instruction sets. Share CPU architecture and memory topology metadata through the OpenStack Placement API to perform unified cataloging of cross-pool resources.

Images