Libvirt-based hyper-aggregated host management method and apparatus

Abstract

Provided in the present application are a libvirt-based hyper-aggregated host management method and apparatus. The method comprises: receiving a resource request of a virtual machine, wherein the resource request is a hardware resource identifier; on the basis of a preset virtual processor, configuring an underlying virtual operating system command corresponding to the hardware resource identifier; on the basis of the underlying virtual operating system command, determining a host corresponding to the virtual machine; and on the basis of the host, allocating resources to a plurality of virtual machines corresponding to the host, and implementing unified management and scheduling of distributed CPU resources by means of libvirt. Therefore, the utilization rate and scheduling efficiency of computing resources are improved. The management method changes an original single-node management mode to a one-to-many mode, such that a plurality of virtualized hosts can share one CPU resource pool, thereby realizing the efficient aggregation and allocation of resources.

Description

A method and apparatus for managing a super-aggregator host based on LIBVIRT

[0001] Cross-reference to related applications

[0002] This application claims priority to Chinese Patent Application No. 202411782520.2, filed on December 5, 2024, entitled "A Method and Apparatus for Managing Super Aggregator Hosts Based on LIBVIRT", the entire contents of which are incorporated herein by reference. Technical Field

[0003] This application relates to the field of cloud computing virtualization technology, and in particular to a method and apparatus for managing a super-aggregated host based on LIBVIRT (open source virtualization management software). Background Technology

[0004] In the current field of cloud computing and virtualization, traditional technologies primarily focus on resource management and virtualization on a single physical server. By abstracting the physical resources of computing nodes into virtual resources, cloud hosts can run on these virtual resources, providing an efficient and isolated computing environment. However, this technology has limitations in resource utilization and struggles to meet the high-performance computing demands of modern big data mining, AI model training, and chip simulation, especially the resource requirements of CPU (CENTRAL PROCESSING UNIT) intensive and memory-intensive applications, which exceed the capacity of a single physical node. Therefore, distributed virtualization technology has become an important trend in addressing these issues.

[0005] Existing distributed virtualization technologies require data transmission between nodes to achieve data synchronization and resource utilization, but this approach leads to high data transmission latency and faces issues of cache consistency and memory consistency. Summary of the Invention

[0006] This application discloses a method and apparatus for managing a super-aggregator host based on libvirt.

[0007] In a first aspect, this application discloses a method for managing a super-aggregator host based on libvirt, the method comprising:

[0008] Receive resource requests from virtual machines; the resource requests are hardware resource identifiers.

[0009] Based on the pre-set virtual processor configuration and the underlying virtual operating system commands corresponding to the hardware resource identifier;

[0010] Determine the host corresponding to the virtual machine based on the underlying virtual operating system commands;

[0011] Based on the host, resources are allocated to multiple virtual machines corresponding to the host, and libvirt is used to achieve unified management and scheduling of distributed CPU (CENTRAL PROCESSING UNIT) resources.

[0012] Optionally, the method further includes:

[0013] The host's memory is allocated according to the pre-set memory block name, and multiple virtual machines use the same CXL (Compute Express Link) memory block.

[0014] Optionally, the method further includes:

[0015] The lifecycle of the aggregated host is managed using libvirt;

[0016] Specifically, it includes:

[0017] The virtual machine XML (Extensible Markup Language) file is modified using libvirt. The XML file includes at least the IP address information of multiple hosts, as well as the CPU (CENTRAL PROCESSING UNIT) information actually used by each host.

[0018] The host's libvirt is initialized with a connection, and then connected to each slave device through the libvirt API (Application Programming Interface) protocol interface.

[0019] Based on the host, the virtual machine XML file is parsed and processed to obtain the processed virtual machine XML file;

[0020] Start the virtual machine based on the processed virtual machine XML file and the processed disk information.

[0021] Optionally, the virtual machine XML file can be modified using libvirt. This XML file must include at least the IP address information of multiple hosts, and the actual CPU (CENTRAL PROCESSING UNIT) used by each host, including:

[0022] Based on the virtual machine XML file, add a host identification tag to identify the configuration information used to describe the host; the configuration information includes at least the IP (Internet Protocol) address of each node, the number of virtual machines corresponding to each IP address, whether the current IP address is the master node, the CXL memory block name and memory size.

[0023] Optionally, the host's libvirt is initialized with a connection, connecting to each slave device via libvirt's API (Application Programming Interface), including:

[0024] Use the virConnectOpen (open virtualization connection) function to connect the host node and each slave node;

[0025] Once all connections are successfully established, the master node will hold connection handles for all slave nodes, which are used for virtual machine management operations.

[0026] Optionally, based on the host, the virtual machine XML file is parsed and processed to obtain a processed virtual machine XML file, including:

[0027] Determine if the current compute node is a host node;

[0028] If it is the master node, it remotely calls the slave nodes through the virtual machine monitor; it calls the virDomainDefineXML (defining virtual domains via XML) function to define virtual machines on each node, so that the definition process of all slave nodes is consistent;

[0029] If it is not the master node, then save the virtual machine XML file parsed by the virtual machine monitor function.

[0030] Optionally, the virtual machine's disk information is processed based on the host to obtain processed disk information, including:

[0031] If the host's identification label exists and the current node is a host node, then the disk information is retained and parsed, and the disk information is saved on the host.

[0032] If the current node is not the host node, the parsing and processing of disk information is skipped, and only the computing resources of that node are processed.

[0033] Secondly, this application discloses a libvirt-based device for managing super-aggregator hosts, the device comprising:

[0034] The receiving module is used to receive resource requests from virtual machines, where the resource request is a hardware resource identifier.

[0035] The calling module is used to execute underlying virtual operating system commands corresponding to the pre-set virtual processor configuration and hardware resource identifiers.

[0036] The determination module is used to determine the host corresponding to the virtual machine based on the underlying virtual operating system commands;

[0037] The allocation module is used to allocate resources to multiple virtual machines corresponding to the host based on the host, and to achieve unified management and scheduling of distributed CPU (CENTRAL PROCESSING UNIT) resources through libvirt.

[0038] Optionally, an allocation module is used for:

[0039] The host's memory is allocated based on the pre-defined memory block name, where multiple virtual machines use the same CXL memory block.

[0040] Optionally, an allocation module is used for:

[0041] The lifecycle of the aggregated host is managed using libvirt;

[0042] Specifically, it includes:

[0043] The virtual machine XML file is modified using libvirt. The XML file includes at least the IP address information of multiple hosts, as well as the CPU (CENTRAL PROCESSING UNIT) information actually used by each host.

[0044] The host's libvirt is initialized with a connection, and then connected to each slave device through the libvirt API (Application Programming Interface) protocol interface.

[0045] Based on the host, the virtual machine XML file is parsed and processed to obtain the processed virtual machine XML file;

[0046] Start the virtual machine based on the processed virtual machine XML file and the processed disk information.

[0047] Optionally, an allocation module is used for:

[0048] Based on the virtual machine XML file, add a host identifier tag to identify the configuration information used to describe the host; the configuration information includes at least the IP address of each node, the number of virtual machines corresponding to each IP address, whether the current IP address is the master node, the CXL memory block name and memory size.

[0049] Optionally, an allocation module is used for:

[0050] Use the virConnectOpen function to connect the master node and each slave node;

[0051] Once all connections are successfully established, the master node will hold connection handles for all slave nodes, which are used for virtual machine management operations.

[0052] Optionally, an allocation module is used for:

[0053] Determine if the current compute node is a host node;

[0054] If it is the master node, it remotely calls the slave nodes through the virtual machine monitor; it calls the virDomainDefineXML function to define the virtual machine on each node so that the definition process of all slave nodes is consistent;

[0055] If it is not the master node, then save the virtual machine XML file parsed by the virtual machine monitor function.

[0056] Optionally, an allocation module is used for:

[0057] If the host's identification label exists and the current node is a host node, then the disk information is retained and parsed, and the disk information is saved on the host.

[0058] If the current node is not the host node, the parsing and processing of disk information is skipped, and only the computing resources of that node are processed.

[0059] Thirdly, this application discloses an electronic device comprising: a processor; and a memory for storing processor-executable instructions; wherein the processor is configured to perform the method as described in any of the foregoing aspects.

[0060] Fourthly, this application discloses a non-transitory computer-readable storage medium that, when the instructions in the storage medium are executed by a processor of an electronic device, enables the electronic device to perform the methods described in any of the above aspects.

[0061] Fifthly, this application discloses a computer program product in which, when the instructions in the computer program product are executed by a processor of an electronic device, the electronic device is enabled to perform the methods described in any of the above aspects.

[0062] The technical solution provided in this application may include the following beneficial effects:

[0063] Unified management: Eliminates the need for manual operation of multiple virtualized hosts. Provides comprehensive management of the virtualization environment through the integrated system offered by libvirt.

[0064] Simplified operation: The operation process is simplified, and users do not need to understand the underlying command line parameters. Advanced management functions are implemented through the libvirt interface, reducing the complexity of operation.

[0065] Increase flexibility: Maintain the existing single-host operation mode, support diverse virtualization management needs, and enhance system adaptability and scalability.

[0066] Reduce system coupling: The client is decoupled from the libvirt instance and only needs to interact with the master node, reducing dependencies between components. When the system is expanded, only the master node needs to be adjusted, and the client does not need to be modified, reducing the complexity of expansion and upgrade.

[0067] Simplify the learning curve: Improvements have been made to the existing libvirt interface, so users can use the advanced functions they need without having to learn a new API (Application Programming Interface). Attached Figure Description

[0068] Figure 1 is a flowchart of the steps of a method for managing a super aggregation host based on libvirt according to this application;

[0069] Figure 2 is a schematic diagram of the overall structure of a super aggregation host according to this application;

[0070] Figure 3 illustrates a method for managing a super aggregation host using libvirt according to this application;

[0071] Figure 4 is a schematic diagram showing the results of comparing the method of this application with the method of libvirt for managing super-aggregated hosts;

[0072] Figure 5 is a logical diagram illustrating the processing details of libvirt managing a super aggregation host according to this application, specifically the processing of adding tags and disk information;

[0073] Figure 6 is a flowchart illustrating the lifecycle of a libvirt-managed super-aggregator host according to this application;

[0074] Figure 7 is a structural block diagram of a libvirt-based management super aggregation host device according to this application;

[0075] Figure 8 is a block diagram of an electronic device according to this application;

[0076] Figure 9 is a block diagram of a computer-readable storage medium according to this application. Detailed Implementation

[0077] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0078] This application proposes a method for aggregating the physical resources of multiple computing nodes, constructing a shared memory pool for multiple nodes as the hardware foundation of a super-aggregator host, thereby breaking down resource isolation between computing nodes. Figure 1 illustrates the overall structure and usage of this super-aggregator host.

[0079] Based on this, this application describes a management method for distributed virtualization on the libvirt side. By integrating libvirt to build a management layer tool, this solution not only retains the advantages of resource aggregation but also achieves centralized and unified management of aggregated hosts. This integration aims to simplify management processes and expand management capabilities, thereby significantly improving the management efficiency and ease of use of the virtualization environment.

[0080] Referring to Figure 1, a flowchart of a method for managing a super-aggregator host based on libvirt according to this application is shown. This method can be applied to electronic devices, and specifically includes the following steps:

[0081] S101. Receive resource requests from virtual machines. The resource requests are hardware resource identifiers.

[0082] Currently, the super-aggregator host has achieved resource separation of the CPU (CENTRAL PROCESSING UNIT) pool, memory pool, and storage pool in terms of hardware. In terms of distributed virtualization technology, it has also completed the aggregation development of the KVM (KEYBOARDVIDEO MOUSE, multi-computer switch) port and QEMU (Quick Emulator) emulator software. Among multiple aggregation hosts, one is designated as the master node, and the others are slave nodes (child nodes). The master node manages all aggregation machines, and the client scheduling platform can only operate on the master node machine.

[0083] In a distributed computing system, the master node is the primary node, while slave nodes play a crucial role. They are computing nodes managed by the master node, responsible for receiving and executing tasks assigned by the master, and then returning the results to the master. Slave nodes provide functions such as load balancing, parallel computing, high reliability, and elastic scaling.

[0084] QEMU is a processor emulation software written by Fabrice Bellard and distributed under the GPL (General Public License). It is widely used on the GNU / Linux (GNU's Not Unix / Linux Is Not UniX, an operating system combining GNU and Linux) platform.

[0085] Libvirt is an open-source API (Application Programming Interface) protocol, daemon, and management tool for managing virtualization platforms. It supports various virtualization technologies and provides a unified interface for managing these virtualization platforms.

[0086] Libvirt's main functions include:

[0087] Managing virtualization platforms: Libvirt supports multiple virtualization platforms and manages them through a unified API (Application Programming Interface) protocol.

[0088] Manage the virtual machine lifecycle, including operations such as starting, stopping, pausing, saving, resuming, and dynamic migration.

[0089] Manage virtual networks and storage: Provides management functions for virtual networks and storage, supporting multiple storage formats and remote management.

[0090] An API (Application Programming Interface) is a set of predefined functions or protocols designed to provide applications and developers with access to a set of routines without requiring access to the source code or understanding the details of the internal workings. The primary purpose of an API is to facilitate communication and data exchange between different software systems.

[0091] S102. According to the pre-set virtual processor configuration and the underlying virtual operating system command corresponding to the hardware resource identifier;

[0092] In the XML documentation, libvirt uses two parameters to manage the CPU (CENTRAL PROCESSING UNIT): the CPU and the VCPU (Virtual CPU virtualization technology). The CPU is primarily used to prevent multiple virtual machines on a single host from competing for resources. However, when a virtual machine starts, libvirt actually calls the underlying QEMU emulation software commands based on the VCPU configuration information. Since the aggregated host incorporated a local-CPU (local central processing unit) parameter during QEMU development, the vCPU and local-CPU need to be bound during libvirt development.

[0093] XML stands for Extensible Markup Language, which is a subset of Standard Generalized Markup Language. It can be used to mark up data and define data types. It is a source language that allows users to define their own markup language.

[0094] S103. Determine the host corresponding to the virtual machine based on the underlying virtual operating system commands;

[0095] S104. Based on the host, allocate resources to multiple virtual machines corresponding to the host, and use libvirt to achieve unified management and scheduling of distributed CPU (CENTRAL PROCESSING UNIT) resources.

[0096] On the QEMU emulation processor software side, the aggregation host allocates VCPU (CPU virtualization technology) resources through the local-CPU. Therefore, on the libvirt side, VCPU (CPU virtualization technology) needs to be bound to the local-CPU to ensure the effective and reasonable use of resources.

[0097] In this application, one host is selected as the master and the rest are slaves. Then, libvirt is used to remotely manage the single host (i.e., the selected host). Thus, data synchronization and resource utilization are performed with the host through libvirt. This is different from the background technology mentioned that "existing distributed virtualization technology requires data transmission between various nodes to achieve data synchronization and resource utilization, but this method will lead to high data transmission latency".

[0098] This application provides a method for managing super-aggregated hosts based on libvirt, enabling unified and centralized management of multiple virtualized hosts across computing nodes while maintaining the existing single-host operation mode on existing computing nodes. This method aims to address the lack of a unified management approach after resource aggregation in current distributed virtualization technologies, while overcoming libvirt's limitations in managing multi-host resources across computing nodes. It provides more elastic and efficient computing resources in cloud environments, further simplifying management processes and improving system flexibility. This meets the needs of modern big data processing, high-performance computing, and AI model training applications, promoting the further development of cloud computing and virtualization technologies.

[0099] The aggregate computing technology proposed in this application includes a super aggregate host architecture comprising four main parts, as shown in Figure 2: (1) Hardware layer: CPU (CENTRAL PROCESSING UNIT) pool, memory pool, and storage pool; (2) Kernel and operating system layer: CXL memory adaptation is implemented; (3) Distributed virtualization layer: consisting of KVM (KEYBOARDVIDEO MOUSE) port, QEMU emulation processor software, and libvirt; (4) Unified platform scheduling; This application focuses on the implementation of the distributed virtualization technology libvirt on the side, with the following specific objectives:

[0100] CXL (Compute Express Link) is a new type of high-speed interconnect technology designed to provide higher data throughput and lower latency to meet the needs of modern computing and storage systems.

[0101] Libvirt is an open-source API (Application Programming Interface) protocol, daemon, and management tool for managing virtualization platforms. It can be used to manage KVM (Keyboard Video Mouse) ports, Xen (Virtual Machine Monitor), VMware ESX (VMware ESX Server), QEMU processor emulation software, and other virtualization technologies.

[0102] CPU (Central Processing Unit) resource pool management: Utilizing libvirt, this approach enables unified management and scheduling of distributed CPU (Central Processing Unit) resources, improving resource utilization and scheduling efficiency. This management method transforms the original single-node management model into a one-to-many model, allowing multiple virtualized hosts to share a single CPU (Central Processing Unit) resource pool, thereby achieving efficient resource aggregation and allocation.

[0103] Based on independently developed distributed virtualization technology: the current super-aggregated host has achieved resource separation of CPU (CENTRAL PROCESSING UNIT) pool, memory pool, and storage pool in terms of hardware, and has also completed the aggregation development of KVM (KEYBOARDVIDEO MOUSE) port and QEMU emulated processor software in terms of distributed virtualization technology.

[0104] Leveraging libvirt's remote management capabilities: Although libvirt is currently primarily used for managing single hosts, it offers powerful remote management capabilities, allowing connection to virtual machine monitors on remote machines. Based on this feature of libvirt, a solution can be designed to achieve unified management of multiple cloud hosts using libvirt.

[0105] This application provides a method and apparatus for managing super-aggregated hosts based on libvirt, comprising: receiving resource requests from virtual machines, wherein the resource requests are hardware resource identifiers; configuring underlying virtual operating system commands corresponding to the hardware resource identifiers according to pre-set virtual processor configurations; determining the host corresponding to the virtual machine according to the underlying virtual operating system commands; and allocating resources to multiple virtual machines corresponding to the host according to the host. By using libvirt, unified management and scheduling of distributed CPU (CENTRAL PROCESSING UNIT) resources are achieved, improving the utilization and scheduling efficiency of computing resources. This management method changes the original single-node management mode to a one-to-many mode, enabling multiple virtualized hosts to share a single CPU (CENTRAL PROCESSING UNIT) resource pool, thereby achieving efficient aggregation and allocation of resources.

[0106] Another embodiment of this application further supplements the description of the libvirt-based method for managing super-aggregated hosts provided in the above embodiments.

[0107] In some embodiments of this application, the method may further include: allocating host memory according to a pre-set memory block name, wherein multiple virtual machines use the same CXL memory block.

[0108] Specifically, the underlying aggregation computing uses CXL shared memory, so device adaptation is required in libvirt, and the memory size of the super aggregation host can be specified as needed. To be compatible with libvirt's management of a single host, memory needs to come from multiple memory backends. Therefore, it is necessary to set an identifier and use the memory-backend parameter on the QEMU emulator processor software side and the original memory in the XML to jointly manage memory resources.

[0109] In QEMU, memory-backend is mainly used to support hot-swapping of memory. It can refer to different backend technologies used for memory management, including basic RAM (Random Access Memory) hot-swapping and using files as memory backends; memory means storage.

[0110] The specific steps are as follows:

[0111] The current test and development environment uses a CXL device emulated by QEMU processor emulation software.

[0112] The required region and namespace are created in the simulated CXL device, which manages the size of the memory and the names of the memory blocks.

[0113] Specify the name of the memory block to be used in the XML, which will serve as the memory backend for the hyper-aggregator host. Parameters in the memory storage that are larger than the CXL memory limit can still utilize native memory.

[0114] This allows the memory backend to be passed as a parameter to the QEMU emulation processor software for further use.

[0115] This application's embodiments can also be used for CXL memory pool resource management. By using libvirt, CXL memory is designated as a memory backend, and memory size is allocated as needed. Through the unified libvirt interface, the CXL memory pool is managed and allocated, ensuring consistency and efficient utilization of memory resources across nodes. In this way, multiple virtualization hosts can share a single memory pool, achieving flexible scheduling and efficient management of memory resources, breaking through the limitations of traditional single-node memory.

[0116] Furthermore, the method also includes managing the lifecycle of the aggregated hosts through libvirt. Specifically, libvirt can be used to modify the virtual machine XML file, which includes at least the IP address information of multiple hosts and the CPU (CENTRAL PROCESSING UNIT) information actually used by each host; the libvirt connection of the host is initialized, and the virtual machine is connected to each slave through the libvirt API (APPLICATION PROGRAMMING INTERFACE) protocol interface; based on the host, the virtual machine XML file is parsed and processed to obtain the processed virtual machine XML file; and the virtual machine is started according to the processed virtual machine XML file and the processed disk information.

[0117] Lifecycle management provides a unified interface for aggregated hosts, enabling virtual machine lifecycle management. This includes operations such as creation, startup, pause, resumption, and destruction, simplifying management processes and improving efficiency. Through unified lifecycle management, multiple virtualized hosts can be centrally controlled and managed, enhancing system flexibility and reliability.

[0118] Furthermore, the virtual machine XML file can be modified using libvirt. This XML file must include at least the IP address information of multiple hosts, and the actual CPU (CENTRAL PROCESSING UNIT) used by each host, including:

[0119] Based on the virtual machine XML file, add a host identifier tag to identify the configuration information used to describe the host; the configuration information includes at least the IP address of each node, the number of virtual machines corresponding to each IP address, whether the current IP address is the master node, the CXL memory block name and memory size.

[0120] In some embodiments of this application, the host's libvirt is initialized with a connection, and the host connects to each slave device through the libvirt API (Application Programming Interface) protocol, including:

[0121] Use the virConnectOpen function to connect the master node and each slave node;

[0122] Once all connections are successfully established, the master node will hold connection handles for all slave nodes, which are used for virtual machine management operations.

[0123] Specifically, the libvirt connection on the master node is initialized. On the master node, the libvirt API (Application Programming Interface) protocol is used to connect to each slave node. The steps are as follows:

[0124] Use the virConnectOpen function to connect to the master node and each slave node, ensuring that all connections are successfully established.

[0125] After the connection is established, the master node will hold the connection handles of all slave nodes, which will be used for subsequent virtual machine management operations.

[0126] This approach ensures that the master node can uniformly manage and schedule virtual machine resources on all slave nodes.

[0127] Furthermore, based on the host, the virtual machine XML file is parsed and processed to obtain the processed virtual machine XML file, including:

[0128] Determine if the current compute node is a host node;

[0129] If it is the master node, it remotely calls the slave nodes through the virtual machine monitor; it calls the virDomainDefineXML function to define the virtual machine on each node so that the definition process of all slave nodes is consistent;

[0130] `virDomainDefineXML` is a function in the libvirt library used to define a virtual machine's configuration file. Its main function is to pass an XML-formatted virtual machine definition file to libvirt for creating or updating a virtual machine's configuration.

[0131] If it is not the master node, then save the virtual machine XML file parsed by the virtual machine monitor function.

[0132] In this application, on the master node, the virtual machine's XML file is parsed and processed, and the following steps are performed:

[0133] Determine if the current compute node is the master node;

[0134] If it is the master node, then a call is made to the remote slave node. After the call is successful, the Hypervisor of the slave node is used for the call.

[0135] The virDomainDefineXML function is called to define virtual machines on each node, ensuring that the definition process is consistent across all nodes.

[0136] If it is not the master node, the function will be parsed into XML and saved directly. This approach will not disrupt the original definition method.

[0137] In some further embodiments of this application, the disk information of the virtual machine is processed based on the host to obtain processed disk information, specifically including:

[0138] If the host's identification label exists and the current node is a host node, then the disk information is retained and parsed, and the disk information is saved on the host.

[0139] If the current node is not the host node, the parsing and processing of disk information is skipped, and only the computing resources of that node are processed.

[0140] To achieve the above objectives, this application provides a method for managing a super-aggregator host based on libvirt, specifically including the following steps:

[0141] The overall framework design for libvirt to manage the super-aggregator host.

[0142] Comparing Figure 3 and Figure 4, the design structure selected in this application is that of Figure 3, in which one of the multiple aggregation hosts is designated as the master node and the others are slave nodes. The master node manages all the aggregation machines, and the client scheduling platform can only operate the master node machine.

[0143] libvirt manages the hardware resources of the aggregation host:

[0144] To manage CPU (Central Processing Unit) resources, libvirt uses two parameters in its XML documentation: the CPU itself and the VCPU (Virtual CPU). The CPU is primarily used to prevent multiple virtual machines on a single host from competing for resources; however, when a virtual machine starts, libvirt uses the VCPU configuration information to call commands from the underlying virtual operating system. On the aggregated host, the local-CPU allocates VCPU resources on the QEMU emulation software side. Therefore, on the libvirt side, the VCPU needs to be bound to the local-CPU to ensure effective and efficient resource utilization.

[0145] Adapting to CXL Memory Backends: The underlying aggregation computing uses CXL shared memory, therefore device adaptation is required in libvirt, and the memory size of the super-aggregator host can be specified as needed. To ensure compatibility with libvirt's single-host management approach, memory needs to be able to come from multiple memory backends. Therefore, it's necessary to set an identifier and use the memory-backend parameters from the QEMU emulator software side and the original memory storage in the XML to jointly manage memory resources. CXL (Compute Express Link) technology is a new high-speed interconnect technology designed to provide higher data throughput and lower latency to meet the needs of modern computing and storage systems. The specific steps are as follows:

[0146] The current test and development environment uses a CXL device emulated by QEMU processor emulation software.

[0147] The required region and namespace are created in the simulated CXL device, which manages the size of the memory and the names of the memory blocks.

[0148] Specify the name of the memory block to be used in the XML, which will serve as the memory backend for the hyper-aggregator host. For memory parameters larger than the CXL memory limit, native memory can still be used.

[0149] This allows the memory backend to be passed as a parameter to the QEMU emulation processor software for further use.

[0150] libvirt manages the lifecycle of aggregated hosts

[0151] XML file modification: libvirt manages resources via XML, therefore, when adapting aggregated host hardware resources, the XML design needs to be modified. First, the master node's XML needs to contain the IP address information of multiple hosts, as well as the CPU (CENTRAL PROCESSING UNIT) information actually used by each host. The specific modified XML design is as follows:

[0152] Figure 5 illustrates the processing details of libvirt managing the super-aggregator host, including handling new tags. <aggregate>The logic for disk information includes reading the IP address information of hosts within multiple compute nodes, reading local-CPU information, and reading CXL memory block names and sizes.

[0153] Add a super-aggregator host identifier tag to the XML file. <aggregate>This is used to describe information related to the aggregated host.

[0154] <ip>The : tag is used to identify the IP address of each node.

[0155] CPUnums: is <ip>The node's attributes identify the number of VCPUs used by each IP address.

[0156] mark: for <ip>The node's attributes indicate whether the current IP address is the master node.

[0157] <cxl>: Identifies the name of the CXL memory block, and the internal size attribute indicates its size.

[0158] (2) Initialize the libvirt connection on the master node. On the master node, connect to each slave node using the libvirtAPI (APPLICATION PROGRAMMING INTERFACE) protocol. The specific steps are as follows:

[0159] Use the virConnectOpen function to connect to the master node and each slave node, ensuring that all connections are successfully established.

[0160] After the connection is established, the master node will hold the connection handles of all slave nodes, which will be used for subsequent virtual machine management operations.

[0161] This approach ensures that the master node can uniformly manage and schedule virtual machine resources on all slave nodes.

[0162] (3) Define the virtual machine. On the master node, parse and process the virtual machine's XML file, performing the following steps:

[0163] Determine if the current compute node is the master node.

[0164] If it is the master node, then a remote call to the slave node is made. After the call is successful, the virtual machine monitor of the slave node is used for the call.

[0165] The virDomainDefineXML function is called to define virtual machines on each node, ensuring that the definition process is consistent across all nodes.

[0166] If it is not the master node, the function will be parsed into XML and saved directly. This approach will not disrupt the original definition method.

[0167] (4) Disk information processing: When processing disk information in virtual machine definitions, the design of the current aggregated host should be considered.

[0168] If the aggregate host's identifier exists and the current node is the master node, then the disk information is retained and resolved to ensure that disk resources are managed on the master node.

[0169] If the current node is not the master node, the parsing and processing of disk information is skipped, and only the computing resources of the node (such as VCPU (CPU virtualization technology)) are processed.

[0170] This method ensures that disk resources are centrally managed on the master node, while computing resources are distributed and managed on each node.

[0171] (5) Start the virtual machine. This function is closely connected to the parameter local-CPU required by the underlying QEMU simulated processor software. The specific steps are as follows:

[0172] Local-CPU refers to each independent CPU core in a multi-core processor. In a multi-core processor, each CPU core has its own processing power and can execute tasks independently without sharing resources with other cores. This design enables the multi-core processor to handle multiple tasks simultaneously and improve the overall processing efficiency.

[0173] If the number of local-CPUs of the current computing node is the same as that of VCPU (CPU virtualization technology).

[0174] If they are the same, the machine can be directly powered on at this node without enabling the aggregation function.

[0175] If they are not the same, a remote connection is made according to the <IP address>, and QEMU simulated processor software parameters are constructed on each node according to the nums attribute of the CPU (Central Processing Unit) central processor, and the virtual machine is started to ensure that the startup process of all nodes is consistent and coordinated.

[0176] (6) Undefine, destroy, and shut down the virtual machine. Figure 6 shows how libvirt manages the life cycle of the super-aggregation host, mainly reflected in the part of constructing QEMU simulated processor software parameters according to xml and the information of error feedback in the RPC protocol mechanism.

[0177] The RPC protocol is a protocol that requests services from a remote computer program over a network without the need to understand the underlying network technology.

[0178] Determine whether the current computing node is the master node

[0179] If it is the master node, a call to the remote slave node is made. After the call is successful, the virtual machine monitor of the slave node is used for the call.

[0180] Call the native interfaces of libvirt, the virDomainUndefine (undefine virtual machine) function, virDomainDestroy (destroy virtual machine) function, and virDomainShutdown (shut down virtual machine domain) function to parse the XML file on each node and perform virtual machine-related operations to ensure that the definition process of all nodes is consistent.

[0181] Other extended function interfaces

[0182] (1) Query virtual machine status

[0183] Users can use the `virsh list` (Virtualization Shell List) interface to query the status of the current virtual machines and determine whether the current machine is an aggregation host or a regular host. This method ensures that users can intuitively understand the running status of each virtual machine and its aggregation status.

[0184] The `virsh list` command is used to display a list of currently running virtual machines.

[0185] The specific details are as follows:

[0186] Add the `isaggregate` property to the list (whether it is an aggregate object).

[0187] If an identifier label exists, further determine whether it is a master node or a slave node and display it.

[0188] If no identifier label exists, leave it blank.

[0189] The operation results and error information are transmitted back using the RPC (Remote Procedure Call) protocol and displayed on the master node. The specific implementation steps are as follows:

[0190] Define the RPC communication protocol: Define a communication protocol between the master node and the slave node to transmit operation results and error information. The communication protocol can use JSON (JavaScript Object Notation) format, which includes the operation type, operation status, and detailed error information.

[0191] Implement RPC protocol client and server: Implement the RPC protocol server on the master node to receive messages from slave nodes; implement the RPC protocol client on each slave node to send operation results and error information to the master node.

[0192] The RPC protocol is used in virtual machine management operations: In each virtual machine management operation, the RPC protocol interface is called to transmit the operation results and error information to the master node. On the master node, the received message is parsed and the operation results and error information are displayed.

[0193] Extended functionality. This work includes, but is not limited to, the above interfaces, but the underlying concept is the same: for aggregated cloud servers, users can only operate the master node; users cannot directly operate the slave nodes.

[0194] This application implements a super-aggregator host management method by implementing the relevant working principles at the code level. Through actual programming and system configuration, the feasibility and effectiveness of this method in practical operation have been verified.

[0195] This breaks away from the existing libvirt management model that relies on a single host on a current compute node, enabling unified and centralized management of multiple virtualized hosts across compute nodes.

[0196] This paper provides a super-aggregated host management method based on libvirt, including but not limited to CPU (CENTRAL PROCESSING UNIT) resource pool management, CXL memory pool resource management, and virtual machine lifecycle management. By improving the cross-node resource management and scheduling methods implemented with the original libvirt interface, resource consistency and efficient utilization are ensured.

[0197] The embodiments of this application have the following technical effects:

[0198] Unified management: Eliminates the need for manual operation of multiple virtualized hosts. Provides comprehensive management of the virtualization environment through the integrated system offered by libvirt.

[0199] Simplified operation: The operation process is simplified, and users do not need to understand the underlying command line parameters. Advanced management functions are implemented through the libvirt interface, reducing the complexity of operation.

[0200] Increase flexibility: Maintain the existing single-host operation mode, support diverse virtualization management needs, and enhance system adaptability and scalability.

[0201] Reduce system coupling: The client is decoupled from the libvirt instance and only needs to interact with the master node, reducing dependencies between components. When the system is expanded, only the master node needs to be adjusted, and the client does not need to be modified, reducing the complexity of expansion and upgrade.

[0202] Simplify the learning curve: Improvements have been made to the existing libvirt interface, so users can use the advanced functions they need without having to learn a new API (Application Programming Interface).

[0203] It should be noted that each of the implementable methods in this embodiment can be implemented individually or in any combination without conflict. This application does not limit this.

[0204] This application provides a method for managing super-aggregated hosts based on libvirt, comprising: receiving resource requests from virtual machines, wherein the resource requests are hardware resource identifiers; configuring the underlying virtual operating system commands corresponding to the hardware resource identifiers according to pre-set virtual processor configurations; determining the host corresponding to the virtual machine according to the underlying virtual operating system commands; and allocating resources to multiple virtual machines corresponding to the host according to the host. By using libvirt, unified management and scheduling of distributed CPU (CENTRAL PROCESSING UNIT) resources are achieved, improving the utilization and scheduling efficiency of computing resources. This management method changes the original single-node management mode to a one-to-many mode, allowing multiple virtualized hosts to share a single CPU (CENTRAL PROCESSING UNIT) resource pool, thereby achieving efficient resource aggregation and allocation.

[0205] Another embodiment of this application provides a libvirt-based super-aggregator host management device for executing the libvirt-based super-aggregator host management method provided in the above embodiments.

[0206] Figure 7 shows a schematic diagram of the libvirt-based management super-aggregator host device provided in an embodiment of this application. The libvirt-based management super-aggregator host device includes, wherein:

[0207] The receiving module 701 is used to receive resource requests from virtual machines, where the resource request is a hardware resource identifier;

[0208] The calling module 702 is used to call the underlying virtual operating system commands corresponding to the pre-set virtual processor configuration and hardware resource identifier;

[0209] The determination module 703 is used to determine the host corresponding to the virtual machine based on the underlying virtual operating system commands;

[0210] The allocation module 704 is used to allocate resources to multiple virtual machines corresponding to the host based on the host, and to achieve unified management and scheduling of distributed CPU (CENTRAL PROCESSING UNIT) resources through libvirt.

[0211] Regarding the apparatus in this embodiment, the specific manner in which each module performs its operations has been described in detail in the embodiments related to the method, and will not be elaborated upon here.

[0212] This application provides a libvirt-based management super-aggregated host device, comprising: receiving resource requests from virtual machines, wherein the resource requests are hardware resource identifiers; configuring underlying virtual operating system commands corresponding to the hardware resource identifiers according to pre-set virtual processor configurations; determining the host corresponding to the virtual machine according to the underlying virtual operating system commands; and allocating resources to multiple virtual machines corresponding to the host according to the host. By using libvirt, unified management and scheduling of distributed CPU (CENTRAL PROCESSING UNIT) resources are achieved, improving the utilization and scheduling efficiency of computing resources. This management method changes the original single-node management mode to a one-to-many mode, allowing multiple virtualized hosts to share a single CPU (CENTRAL PROCESSING UNIT) resource pool, thereby achieving efficient resource aggregation and allocation. Another embodiment of this application further supplements the libvirt-based management super-aggregated host device provided in the above embodiments.

[0213] In some embodiments of this application, the allocation module is used for:

[0214] The host's memory is allocated based on the pre-defined memory block name, where multiple virtual machines use the same CXL memory block.

[0215] In some embodiments of this application, the allocation module is used for:

[0216] The lifecycle of the aggregated host is managed using libvirt;

[0217] Specifically, it includes:

[0218] The virtual machine XML file is modified using libvirt. The XML file includes at least the IP address information of multiple hosts, as well as the CPU (CENTRAL PROCESSING UNIT) information actually used by each host.

[0219] The host's libvirt is initialized with a connection, and then connected to each slave device through the libvirt API (Application Programming Interface) protocol interface.

[0220] Based on the host, the virtual machine XML file is parsed and processed to obtain the processed virtual machine XML file;

[0221] Start the virtual machine based on the processed virtual machine XML file and the processed disk information.

[0222] In some embodiments of this application, the allocation module is used for:

[0223] Based on the virtual machine XML file, add a host identifier tag to identify the configuration information used to describe the host; the configuration information includes at least the IP address of each node, the number of virtual machines corresponding to each IP address, whether the current IP address is the master node, the CXL memory block name and memory size.

[0224] In some embodiments of this application, the allocation module is used for:

[0225] Use the virConnectOpen function to connect the master node and each slave node;

[0226] Once all connections are successfully established, the master node will hold connection handles for all slave nodes, which are used for virtual machine management operations.

[0227] In some embodiments of this application, the allocation module is used for:

[0228] Determine if the current compute node is a host node;

[0229] If it is the master node, it remotely calls the slave nodes through the virtual machine monitor; it calls the virDomainDefineXML function to define the virtual machine on each node so that the definition process of all slave nodes is consistent;

[0230] If it is not the master node, then save the virtual machine XML file parsed by the virtual machine monitor function.

[0231] In some embodiments of this application, the allocation module is used for:

[0232] If the host's identification label exists and the current node is a host node, then the disk information is retained and parsed, and the disk information is saved on the host.

[0233] If the current node is not the host node, the parsing and processing of disk information is skipped, and only the computing resources of that node are processed.

[0234] As the device embodiment is basically similar to the method embodiment, the description is relatively simple, and relevant parts can be found in the description of the method embodiment.

[0235] This application provides a LIBVIRT-based management device for super-aggregated hosts, comprising: receiving resource requests from virtual machines, wherein the resource requests are hardware resource identifiers; configuring the underlying virtual operating system commands corresponding to the hardware resource identifiers according to pre-set virtual processor configurations; determining the host corresponding to the virtual machine according to the underlying virtual operating system commands; and allocating resources to multiple virtual machines corresponding to the host according to the host. Through libvirt, unified management and scheduling of distributed CPU (CENTRAL PROCESSING UNIT) resources are achieved, improving the utilization and scheduling efficiency of computing resources. This management method changes the original single-node management mode to a one-to-many mode, allowing multiple virtualized hosts to share a single CPU (CENTRAL PROCESSING UNIT) resource pool, thereby achieving efficient aggregation and allocation of resources.

[0236] Optionally, this application also provides an electronic device, including: a processor, a memory, and a computer program stored in the memory and executable on the processor. When the computer program is executed by the processor, it implements the various processes of the above method embodiments and achieves the same technical effect. To avoid repetition, it will not be described again here.

[0237] This application also provides a computer-readable storage medium storing a computer program. When the computer program is executed by a processor, it implements the various processes of the above-described method embodiments and achieves the same technical effects. To avoid repetition, it will not be described again here. The computer-readable storage medium may include read-only memory (ROM), random access memory (RAM), magnetic disk, or optical disk.

[0238] Figure 8 is a block diagram of an electronic device 800 according to this application. For example, the electronic device 800 may be a mobile phone, a computer, a digital broadcasting terminal, a messaging device, a game console, a tablet device, a medical device, a fitness device, a personal digital assistant, etc.

[0239] Referring to FIG8, the electronic device 800 may include one or more of the following components: processing component 802, memory 804, power supply component 806, multimedia component 808, audio component 810, input / output (I / O) interface 812, sensor component 814, and communication component 816.

[0240] Processing component 802 typically controls the overall operation of electronic device 800, such as operations associated with display, telephone calls, data communication, camera operation, and recording operations. Processing component 802 may include one or more processors 820 to execute instructions to complete all or part of the steps of the methods described above. Furthermore, processing component 802 may include one or more modules to facilitate interaction between processing component 802 and other components. For example, processing component 802 may include a multimedia module to facilitate interaction between multimedia component 808 and processing component 802.

[0241] Memory 804 is configured to store various types of data to support the operation of device 800. Examples of such data include instructions for any application or method operating on electronic device 800, contact data, phonebook data, messages, images, videos, etc. Memory 804 can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as Static Random-Access Memory (SRAM), Electrically Erasable Programmable Read-Only Memory (EEPROM), Erasable Programmable Read-Only Memory (EPROM), Programmable Read-Only Memory (PROM), Read-Only Memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk.

[0242] Power supply component 806 provides power to various components of electronic device 800. Power supply component 806 may include a power management system, one or more power supplies, and other components associated with generating, managing, and distributing power to electronic device 800.

[0243] Multimedia component 808 includes a screen that provides an output interface between electronic device 800 and the user. In some embodiments, the screen may include a Liquid Crystal Display (LCD) and a Touch Panel (TP). If the screen includes a Touch Panel, the screen may be implemented as a touchscreen to receive input signals from the user. The Touch Panel includes one or more touch sensors to sense touches, swipes, and gestures on the Touch Panel. The touch sensors may sense not only the boundaries of touch or swipe actions but also the duration and pressure associated with the touch or swipe operation. In some embodiments, multimedia component 808 includes a front-facing camera and / or a rear-facing camera. When device 800 is in an operating mode, such as a shooting mode or video mode, the front-facing camera and / or rear-facing camera may receive external multimedia data. Each front-facing camera and rear-facing camera may be a fixed optical lens system or have focal length and optical zoom capabilities.

[0244] Audio component 810 is configured to output and / or input audio signals. For example, audio component 810 includes a microphone (MIC) configured to receive external audio signals when electronic device 800 is in an operating mode, such as call mode, recording mode, and voice recognition mode. The received audio signals may be further stored in memory 804 or transmitted via communication component 816. In some embodiments, audio component 810 also includes a speaker for outputting audio signals.

[0245] I / O interface 812 provides an interface between processing component 802 and peripheral interface modules, such as keyboards, click wheels, buttons, etc. These buttons may include, but are not limited to, home buttons, volume buttons, power buttons, and lock buttons.

[0246] Sensor assembly 814 includes one or more sensors for providing state assessments of various aspects of electronic device 800. For example, sensor assembly 814 may detect the on / off state of device 800, the relative positioning of components such as the display and keypad of electronic device 800, changes in position of electronic device 800 or a component of electronic device 800, the presence or absence of user contact with electronic device 800, orientation or acceleration / deceleration of electronic device 800, and temperature changes of electronic device 800. Sensor assembly 814 may include a proximity sensor configured to detect the presence of nearby objects without any physical contact. Sensor assembly 814 may also include an optical sensor, such as a CMOS (Complementary Metal-Oxide-Semiconductor) or CCD (Charge-Coupled Device) image sensor, for use in imaging applications. In some embodiments, sensor assembly 814 may also include an accelerometer, gyroscope, magnetometer, pressure sensor, or temperature sensor.

[0247] Communication component 816 is configured to facilitate wired or wireless communication between electronic device 800 and other devices. Electronic device 800 can access wireless networks based on communication standards, such as WiFi, carrier networks (such as 2G, 3G, 4G, or 5G), or combinations thereof. In one exemplary embodiment, communication component 816 receives broadcast signals or broadcast operation information from an external broadcast management system via a broadcast channel. In one exemplary embodiment, communication component 816 also includes a Near Field Communication (NFC) module to facilitate short-range communication. For example, the NFC module may be based on Radio Frequency Identification (RFID), Infrared Data Association (IrDA), Ultra-Wideband (UWB), Bluetooth, and other technologies.

[0248] In an exemplary embodiment, the electronic device 800 may be implemented by one or more application-specific integrated circuits (ASICs), digital signal processors (DSPs), digital signal processing devices (DSPDs), programmable logic devices (PLDs), field-programmable gate arrays (FPGAs), controllers, microcontrollers, microprocessors, or other electronic components to perform the methods described above.

[0249] In an exemplary embodiment, a non-transitory computer-readable storage medium including instructions is also provided, such as a memory 804 including instructions, which can be executed by a processor 820 of an electronic device 800 to perform the above-described method. For example, the non-transitory computer-readable storage medium may be a ROM, random access memory (RAM), CD-ROM (Compact Disc-Read-Only Memory), magnetic tape, floppy disk, and optical data storage device, etc.

[0250] Figure 9 is a block diagram illustrating a computer-readable storage medium 1900 according to this application. For example, the computer-readable storage medium 1900 may be provided as a server.

[0251] Referring to FIG9, the computer-readable storage medium 1900 includes a processing component 1922, which further includes one or more processors, and a memory resource represented by memory 1932 for storing instructions executable by the processing component 1922, such as application programs. The application programs stored in memory 1932 may include one or more modules, each corresponding to a set of instructions. Furthermore, the processing component 1922 is configured to execute instructions to perform the methods described above.

[0252] The computer-readable storage medium 1900 may also include a power supply component 1926 configured to perform power management of the computer-readable storage medium 1900, a wired or wireless network interface 1950 configured to connect the computer-readable storage medium 1900 to a network, and an input / output (I / O) interface 1958. The computer-readable storage medium 1900 may operate on an operating system stored in memory 1932, such as Windows Server™ (Microsoft Windows Server System), Mac OS X™ (Macintosh Operating System), Unix™ (Uniplexed Information and Computing System), Linux™ (Linux Operating System), FreeBSD™ (Berkeley Software Distribution), or similar.

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

[0254] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods of the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk) and includes several instructions to cause a terminal (which may be a mobile phone, computer, server, air conditioner, or network device, etc.) to execute the methods of the various embodiments of this application.

[0255] The embodiments of this application have been described above with reference to the accompanying drawings. However, this application is not limited to the specific embodiments described above. The specific embodiments described above are merely illustrative and not restrictive. Those skilled in the art can make many other forms under the guidance of this application without departing from the spirit and scope of the claims, and all of these forms are within the protection scope of this application.

[0256] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed in this application can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0257] Those skilled in the art will understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0258] In the embodiments provided in this application, it should be understood that the disclosed apparatus and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or units may be electrical, mechanical, or other forms.

[0259] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0260] In addition, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0261] If a function is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, ROM, RAM, magnetic disks, or optical disks.

[0262] The above are merely specific embodiments of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.< / cxl> < / ip> < / ip> < / ip> < / aggregate> < / aggregate>

Claims

1. A method for managing a super-aggregation host based on libvirt, characterized in that, The method includes: Receive resource requests from virtual machines, wherein the resource requests are hardware resource identifiers; Configure the underlying virtual operating system commands corresponding to the hardware resource identifiers based on the pre-configured virtual processors; Based on the underlying virtual operating system commands, determine the host corresponding to the virtual machine; Based on the host, resources are allocated to multiple virtual machines corresponding to the host, and unified management and scheduling of distributed CPUs are achieved through libvirt.

2. The method for managing a super-aggregate host based on libvirt according to claim 1, wherein, The method further includes: The host's memory is allocated based on the pre-defined memory block name, where multiple virtual machines use the same CXL memory block.

3. The method of claim 1, wherein the libvirt-based management super- aggregation host is configured to, The method further includes: The lifecycle of the aggregated host is managed using libvirt; Specifically, it includes: The virtual machine XML file is modified using libvirt, wherein the XML file includes at least the IP address information of multiple hosts, as well as the actual CPU usage of each host; Initialize the connection of libvirt on the host and connect to each slave device through the libvirt API protocol interface; Based on the host, the virtual machine XML file is parsed and processed to obtain the processed virtual machine XML file; The virtual machine is started based on the processed virtual machine XML file and the processed disk information.

4. The method of claim 3, wherein, The modification of the virtual machine XML file via libvirt, wherein the XML file includes at least IP address information of multiple hosts, and the actual CPU usage of each host, including: Based on the virtual machine XML file, a host identifier tag is added. The identifier is used to describe the host's configuration information. The configuration information includes at least the IP address of each node, the number of virtual machines corresponding to each IP address, whether the current IP address is a host node, the CXL memory block name, and the memory size.

5. The method of claim 3, wherein, The initialization connection to the host's libvirt, and the connection to each slave device via the libvirt API protocol interface, includes: Use the virConnectOpen function to connect the master node and each slave node; Once all connections are successfully established, the master node will hold connection handles for all slave nodes, which are used for virtual machine management operations.

6. The method of claim 3, wherein, The process of parsing and processing the virtual machine XML file based on the host to obtain the processed virtual machine XML file includes: Determine if the current compute node is a host node; If it is a master node, the slave node is remotely invoked through the virtual machine monitor; the virDomainDefineXML function is called to define the virtual machine on each node so that the definition process of all slave nodes is consistent; If it is not the host node, the virtual machine XML file parsed by the virtual machine monitor function will be saved.

7. The method of claim 1, wherein the libvirt-based management super- aggregation host is further configured to: The step of allocating resources to the virtual machine corresponding to the host based on the host includes: If the host's identification label exists and the current node is a host node, then the disk information is retained and parsed, and the disk information is saved on the host. If the current node is not the host node, the parsing and processing of disk information is skipped, and only the computing resources of the current node are processed.

8. A super-aggregation host device based on libvirt management, characterized in that, The device includes: A receiving module is used to receive resource requests from virtual machines, wherein the resource request is a hardware resource identifier; The calling module is used to execute underlying virtual operating system commands corresponding to the pre-set virtual processor configuration and hardware resource identifiers. The determination module is used to determine the host corresponding to the virtual machine based on the underlying virtual operating system commands; The allocation module is used to allocate resources to multiple virtual machines corresponding to the host based on the host, and to achieve unified management and scheduling of distributed CPU resources through libvirt.

9. An electronic device, comprising: include: A processor, a memory, and a computer program stored in the memory and executable on the processor, wherein the computer program, when executed by the processor, implements the method as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, implements the method as described in any one of claims 1 to 7.