Virtual machine asynchronous memory allocation method and apparatus, and computer device and storage medium

Abstract

The present application relates to a virtual machine asynchronous memory allocation method and apparatus, and a computer device and a storage medium. The method comprises: detecting whether a Qemu software version of a virtual machine satisfies an asynchronous memory pre-allocation condition (S11); if the asynchronous memory pre-allocation condition is satisfied, generating a corresponding object-add command by means of a preset memory management protocol of the virtual machine (S12); on the basis of a parameter of the object-add command, creating a corresponding asynchronous memory allocation task in iothread of qemu, and setting the allocation state of a memory object to a running state (S13); and controlling the virtual machine to execute the asynchronous memory allocation task in iothread to obtain an execution result, and adjusting the allocation state of the memory object on the basis of the execution result (S14).

Description

Methods, devices, computer equipment, and storage media for allocating asynchronous memory in virtual machines.

[0001] Related applications

[0002] This application claims priority to Chinese patent application filed on November 29, 2024, with application number 2024117474579, entitled "Method, Apparatus, Computer Equipment and Medium for Allocating Asynchronous Memory for Virtual Machines", the entire contents of which are incorporated herein by reference. Technical Field

[0003] This application relates to the field of virtual machine technology, specifically to methods, apparatus, computer devices, and media for allocating asynchronous memory in virtual machines. Background Technology

[0004] With the rapid development of cloud computing technology, virtualization technology plays a crucial role. In Linux's native open-source full virtualization solution, kernel virtualization, which is based on hardware-assisted virtualization, emulators and libvirt, among others, jointly construct a complete virtualization management system. In this architecture, the main thread handles the main loop tasks, continuously monitoring two specific event sources and timers. When an event source detects an event to be processed, the corresponding callback function is called sequentially, and a specific lock is acquired. Numerous operations, such as I / O read / write operations on certain block devices, virtio-net event handling, and specific command processing (including hot-adding memory), are executed within the main loop.

[0005] Because open-source emulators typically use synchronous memory pre-allocation, when a virtual machine uses passthrough devices or specific protocols and requires a large amount of pre-allocated memory, the memory pre-allocation task can occupy the main thread until completion. This causes the main loop to be occupied for a long time, making it difficult to process other tasks or events in a timely manner, thus leading to virtual machine malfunctions. For example, if block device read / write tasks are blocked, all read / write operations within the virtual machine will stop; if virtio-net event handling tasks are blocked, network interruptions may occur for a long time when network traffic is high; the virtual network computing and console may also fail to refresh because the main thread is occupied, greatly affecting the normal operation of virtual machine services. Summary of the Invention

[0006] According to various embodiments of this application, a method, apparatus, computer device, and storage medium for allocating asynchronous memory for virtual machines are provided.

[0007] In a first aspect, embodiments of this application provide a method for allocating asynchronous memory in a virtual machine, executed by a computer device, the method comprising:

[0008] Check whether the Qemu software version of the virtual machine meets the asynchronous memory pre-allocation conditions;

[0009] If the asynchronous memory pre-allocation conditions are met, the corresponding object-add command is generated through the virtual machine's preset memory management protocol;

[0010] Based on the parameters of the `object-add` command, a corresponding asynchronous memory allocation task is created in the virtual machine's iothread, and the allocation status of the memory object is set to running; and,

[0011] The virtual machine is controlled to execute the asynchronous memory allocation task in the iothread, the execution result is obtained, and the allocation state of the memory object is adjusted according to the execution result.

[0012] Furthermore, detecting whether the Qemu software version of the virtual machine meets the asynchronous memory pre-allocation conditions includes:

[0013] Detect whether the virtual machine has a pre-allocation requirement for memory;

[0014] If the pre-allocation requirement exists, then query whether the Qemu software version has an asynchronous memory pre-allocation attribute. If it does, set the attribute value of the asynchronous memory pre-allocation attribute to a first preset value, thus determining that the Qemu software version meets the asynchronous memory pre-allocation condition; and...

[0015] If the pre-allocation requirement does not exist, or if the asynchronous memory pre-allocation function is not available, then the Qemu software version is determined to not meet the asynchronous memory pre-allocation conditions.

[0016] Furthermore, adjusting the allocation state of the memory object based on the execution result includes:

[0017] If the execution result is successful, then the allocation status of the memory object is adjusted to the completed state; and,

[0018] If the execution result is a failure, a corresponding rollback operation is performed on the asynchronous memory allocation task, and the allocation status of the memory object is adjusted to the terminated state.

[0019] Furthermore, after creating the corresponding asynchronous memory allocation task in the virtual machine's iothread based on the parameters of the object-add command, the method further includes:

[0020] Send the main thread release signal to the libvirt;

[0021] The main thread release signal is received through libvirt, and the attribute value of the asynchronous memory pre-allocation attribute is obtained.

[0022] If the attribute value is a first preset value, then the allocation status of the memory object is queried. If the allocation status is in the running state, the allocation status monitoring operation continues; and,

[0023] If the attribute value is a second preset value, and / or the allocation status of the memory object is a completed state or a terminated state, then the memory device consolidation mechanism is triggered, and corresponding control operations are performed on the virtual machine based on the memory device consolidation mechanism.

[0024] Furthermore, the triggering of the memory device consolidation mechanism and the execution of corresponding control operations based on the memory device consolidation mechanism include:

[0025] The virtual dual in-line memory module is added as a memory device to the virtual machine's configuration environment using the virtual machine's preset memory management protocol; and,

[0026] In the configuration environment, an association is established between the virtual dual in-line memory module and the Qemu software version of the virtual machine.

[0027] Furthermore, the method also includes:

[0028] Retrieve memory devices added within a preset time period;

[0029] The memory device is matched with the Qemu software version in the virtual machine to obtain the matching result; and,

[0030] The corresponding processing operation is performed on the memory device based on the matching result.

[0031] Furthermore, performing corresponding processing operations on the memory device based on the matching result includes:

[0032] When the matching result indicates that the memory device and the Qemu software version do not match, the allocation status of the memory object is obtained; if the allocation status is a completed or terminated state, a deletion operation is performed on the memory device; or, if the allocation status is a running state, the currently running asynchronous memory allocation task is terminated, and a deletion operation is performed on the memory device after the task is completed; and,

[0033] When the matching result is that the memory device matches the Qemu software version, the usage requirements for the memory device are monitored, the allocation status of the memory object is obtained according to the usage requirements, and the usage operation is performed on the memory device when the allocation status is a completed state or a terminated state.

[0034] Secondly, embodiments of this application provide a virtual machine asynchronous memory allocation apparatus, the apparatus comprising:

[0035] The detection module is used to detect whether the Qemu software version of the virtual machine meets the asynchronous memory pre-allocation conditions;

[0036] The generation module is used to generate the corresponding object-add command according to the virtual machine's preset memory management protocol if the asynchronous memory pre-allocation conditions are met.

[0037] A module is created to create a corresponding asynchronous memory allocation task in the virtual machine's iothread based on the object-add command, and to set the allocation status of the Qemu software version to the running state; and,

[0038] The control module is used to control the virtual machine to execute the asynchronous memory allocation task in the iothread, obtain the execution result, and adjust the allocation status of the Qemu software version according to the execution result.

[0039] Thirdly, embodiments of this application provide a computer device, including: a memory and a processor, the memory and the processor being communicatively connected to each other, the memory storing computer-readable instructions, and the processor executing the computer-readable instructions to perform the method described in the first aspect or any corresponding embodiment.

[0040] Fourthly, embodiments of this application provide a computer-readable storage medium storing computer-readable instructions, which are used to cause a computer to perform the method described in the first aspect or any corresponding embodiment.

[0041] Details of one or more embodiments of this application are set forth in the following drawings and description. Other features and advantages of this application will become apparent from the specification, drawings, and claims. Attached Figure Description

[0042] To more clearly illustrate the technical solutions in the embodiments of this application or the conventional technology, the drawings used in the description of the embodiments or the conventional technology will be briefly introduced below. Obviously, the drawings described below are only embodiments of this application. For those skilled in the art, other drawings can be obtained based on the disclosed drawings without creative effort.

[0043] Figure 1 is a flowchart illustrating a virtual machine asynchronous memory allocation method according to an embodiment of this application;

[0044] Figure 2 is a flowchart illustrating the cyclic scheduling mechanism in a software system according to an embodiment of this application;

[0045] Figure 3 is a flowchart illustrating the operation based on pre-allocated asynchronous attributes according to an embodiment of this application;

[0046] Figure 4 is a flowchart illustrating the virtual machine memory management interaction process according to an embodiment of this application;

[0047] Figure 5 is a flowchart illustrating a test method for virtual machine memory management technology according to an embodiment of this application;

[0048] Figure 6 is a structural block diagram of a virtual machine asynchronous memory allocation device according to an embodiment of this application;

[0049] Figure 7 is a schematic diagram of the hardware structure of a computer device according to an embodiment of this application. Detailed Implementation

[0050] 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, and 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.

[0051] According to embodiments of this application, a method, apparatus, computer device, and medium for allocating asynchronous memory for a virtual machine are provided. It should be noted that the steps shown in the flowcharts in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. Furthermore, although a logical order is shown in the flowcharts, in some cases, the steps shown or described may be executed in a different order than that shown here.

[0052] This embodiment provides a method for allocating asynchronous memory in a virtual machine. Figure 1 is a flowchart of the method for allocating asynchronous memory in a virtual machine according to an embodiment of this application. As shown in Figure 1, the process includes the following steps:

[0053] Step S11: Check whether the Qemu software version of the virtual machine meets the asynchronous memory pre-allocation conditions.

[0054] In this embodiment of the application, step S11 includes the following steps A1-A3:

[0055] Step A1: Check if there is a pre-allocation requirement for the virtual machine's memory.

[0056] It should be noted that a virtual machine is a computer system simulated by software, possessing complete hardware system functionality and running in a completely isolated environment. Pre-allocation requirements refer to the need to allocate more memory resources to the virtual machine in advance during its operation, due to factors such as business growth and increased load, to ensure the virtual machine's normal operation.

[0057] Specifically, the pre-allocation requirement of virtual machine memory can be detected in several ways. For example, continuously monitoring the virtual machine's memory usage and considering a pre-allocation requirement when the usage reaches a specific threshold. Alternatively, based on the type of business the virtual machine is running and load forecasts, it can be determined whether future memory shortages are likely; if future memory shortages are anticipated, then a pre-allocation requirement is confirmed.

[0058] Step A2: If there is a pre-allocation requirement, check whether the Qemu software version has the asynchronous memory pre-allocation attribute. If it does, set the attribute value of the asynchronous memory pre-allocation attribute to the first preset value to determine that the Qemu software version meets the asynchronous memory pre-allocation condition.

[0059] It's important to note that the Qemu software version refers to the specific release version number of the Qemu software used by the virtual machine. It serves as a distinguishing identifier between different development and release stages of the Qemu software, with each version possessing unique characteristics, such as new feature releases, performance improvements, security vulnerability fixes, and bug corrections. These version differences have a tangible impact on virtual machine functionality. Regarding memory management, different versions of Qemu software exhibit varying levels of asynchronous memory pre-allocation capabilities; some versions possess this feature, while others do not. Therefore, the software version is a crucial factor in determining whether asynchronous memory pre-allocation conditions are met.

[0060] The asynchronous memory pre-allocation attribute is a feature specifically added to achieve asynchronous memory pre-allocation. Its core function is to determine whether a corresponding Qemu software version supports asynchronous memory pre-allocation, and it can be regarded as a functional identifier. Once it is determined that a Qemu software version has this attribute, its attribute value is set to a first preset value. This first preset value is a pre-determined specific marker value, which indicates that the attribute has been successfully switched to an effective enabled state, meaning that this Qemu software version meets the conditions for asynchronous memory pre-allocation, thereby providing strong support and guarantee for any subsequent memory pre-allocation operations that the virtual machine may perform.

[0061] Specifically, when a virtual machine is detected to have a pre-allocation requirement, libvirt (a software library for managing virtualization platforms) queries whether the Qemu software version has the asynchronous memory pre-allocation attribute. This can be done by checking the Qemu software version's attribute list or by calling a specific interface. If the Qemu software version has this attribute, it means that it supports asynchronous memory pre-allocation. In this case, the attribute value of the asynchronous memory pre-allocation attribute can be set to a first preset value, such as "true" or "1", to confirm that the Qemu software version meets the asynchronous memory pre-allocation condition.

[0062] Step A3: If there is no pre-allocation requirement or no asynchronous memory pre-allocation function, then it is determined that the Qemu software version does not meet the asynchronous memory pre-allocation conditions.

[0063] Specifically, if the virtual machine does not have a pre-allocation requirement, then asynchronous memory pre-allocation is unnecessary, thus determining that the Qemu software version does not meet the asynchronous memory pre-allocation conditions. Furthermore, if the Qemu software version does not have asynchronous memory pre-allocation functionality, even if a pre-allocation requirement exists, asynchronous memory pre-allocation cannot be performed, similarly determining that the asynchronous memory pre-allocation conditions are not met.

[0064] Step S12: If the asynchronous memory pre-allocation conditions are met, the corresponding object-add command is generated through the virtual machine's preset memory management protocol.

[0065] In this embodiment, the asynchronous memory pre-allocation condition is that the Qemu software version of the virtual machine has a pre-allocation requirement and possesses the asynchronous memory pre-allocation attribute; the preset memory management protocol is a set of specifications and methods for managing virtual machine memory, which specifies how to perform operations such as memory allocation, release, and status query. Different virtual machine software can have different preset memory management protocols. The object-add command is an instruction used to add a specific Qemu software version to the virtual machine system.

[0066] As an example, the QEMU virtual machine can generate object-add commands using the QMP Machine Protocol (QMP). Specifically, if libvirt determines that the QEMU virtual machine supports asynchronous memory pre-allocation and that memory pre-allocation is required, it specifies the `prealloc_async` attribute as `true` in the `qmp object_add` command. This enables asynchronous memory allocation so that subsequent asynchronous memory allocation tasks can be performed in a dedicated iothread. If the QEMU virtual machine does not support asynchronous memory pre-allocation or that memory pre-allocation is not required, the `prealloc_async` attribute is not specified, and the `qmp` command is executed directly.

[0067] Step S13: Based on the parameters of the object-add command, create the corresponding asynchronous memory allocation task in the virtual machine's iothread, and set the allocation status of the memory object to the running state.

[0068] In this embodiment, after the asynchronous memory pre-allocation conditions are met, an `object-add` command is generated. Based on the command parameters of the `object-add` command, an asynchronous memory allocation task is created in the virtual machine's iothread. In the QEMU and ibvirt combination, when the conditions are met, libvirt specifies the `prealloc_async` attribute as `true` in the `qmp object_add` command. After parsing, QEMU creates the task in a dedicated iothread and sets the QEMU software version allocation status to running, so as to track and manage the task progress and allow other parts of the system to understand the current status for corresponding processing and monitoring.

[0069] Step S14: Control the virtual machine to execute asynchronous memory allocation tasks in iothread, obtain the execution results, and adjust the allocation status of memory objects according to the execution results.

[0070] In this embodiment, after creating an asynchronous memory allocation task in the iothread, it is necessary to control the virtual machine to execute this task in that iothread. For example, in the combination of QEMU and libvirt, the QEMU virtual machine executes the asynchronous memory allocation task in a dedicated iothread. Specifically, this process may involve creating a touch thread to trigger the actual memory allocation and waiting for the allocation to complete. During task execution, the virtual machine continuously monitors the task's progress. If the memory allocation is successful, the execution result is "done"; if a problem occurs during the allocation process leading to failure, the execution result is "error".

[0071] In this embodiment of the application, adjusting the allocation state of the memory object according to the execution result includes: if the execution result is successful, adjusting the allocation state of the memory object to the completed state; or, if the execution result is unsuccessful, performing the corresponding rollback operation on the asynchronous memory allocation task and adjusting the allocation state of the memory object to the terminated state.

[0072] Specifically, when the virtual machine performs an asynchronous memory allocation task in the iothread, if the result is successful, such as in the interaction between QEMU and libvirt, after QEMU completes the allocation, it sets the res_async attribute to done and the memory object state is adjusted to the completed state; if it fails, a rollback operation is performed, such as releasing some allocated resources, undoing some system state changes, and then setting the res_async attribute to error and the memory object state is adjusted to the terminated state.

[0073] It should be noted that Figure 2 illustrates a loop system, starting from initialization, going through preparation, polling, scheduling, and then returning to the main loop, forming a closed loop. During the scheduling phase, there are also external callback function calls. This type of flowchart is typically used to describe event loops or task scheduling mechanisms in software systems. In the virtual machine memory management technology of this application, the software system also has a similar loop scheduling mechanism to ensure that various operations are performed in an orderly manner. For example, in the memory allocation and management process, there may be processes such as initializing relevant memory management parameters, preparing memory allocation space, polling memory usage status, scheduling memory allocation tasks, and involving externally triggered callback function operations during scheduling (e.g., adjusting memory allocation strategies based on external events) to ensure the stable operation of the entire virtual machine memory management system.

[0074] As an example, as shown in Figure 3, Libvirt first queries the memory backend properties. It checks if the prealloc_async property is present. If it is, Libvirt adds the memory backend object via QMP and sets prealloc_async to true. If it is not, Libvirt directly adds the memory backend object via QMP. Libvirt then queries the memory device via QMP. Upon receiving the command, Qemu performs the following actions: if prealloc_async is present, Qemu creates a new I / O thread, performs backend memory prealloc (backend memory alloc mem_prealloc), and performs memory prealloc within the I / O thread (iothread_mem_prealloc). If prealloc_async is not present, Qemu performs backend memory alloc. Qemu updates the result (update res) and sends the result back to Libvirt. Libvirt checks whether the asynchronous result is complete or has an error (res_async is done / error?) and concludes that it is complete or has an error (Done / Error).

[0075] In this embodiment of the application, after creating the corresponding asynchronous memory allocation task in the virtual machine's iothread based on the parameters of the object-add command, the method further includes:

[0076] Step S21: Send a release signal from the main thread to libvirt.

[0077] In this embodiment, after a corresponding asynchronous memory allocation task is successfully created in the virtual machine's iothread, the system sends a main thread release signal to libvirt. This signal can be sent via a specific function call or by following a predetermined communication protocol, depending on the virtual machine and libvirt's implementation mechanism. For example, in a combination of QEMU and libvirt, the signal is sent according to their agreed-upon method so that libvirt can receive the information that the main thread can release the memory.

[0078] Step S22: Receive the main thread release signal through libvirt and obtain the attribute value of the asynchronous memory pre-allocation attribute.

[0079] In this embodiment, after receiving the release signal from the main thread, libvirt (such as libvirt) obtains the attribute value of the asynchronous memory pre-allocation attribute. Specifically, this includes querying the relevant attribute settings of the Qemu software version, obtaining the attribute value by calling the corresponding interface function or querying a specific data structure. For example, libvirt sends a query request to the virtual machine to obtain the value of the prealloc_async attribute of the qemu memory-backend object, thereby clarifying the relevant settings of the current memory pre-allocation task.

[0080] Step S23: If the attribute value is the first preset value, then query the allocation status of the Qemu software version. If the allocation status is running, continue to perform the allocation status monitoring operation.

[0081] Specifically, if the obtained asynchronous memory pre-allocation attribute value is the first preset value, it indicates that the current situation requires further monitoring of the memory allocation task's progress. At this point, libvirt queries the allocation status of the memory object. If the allocation status is found to be running, it means the memory allocation task is in progress, and the allocation status monitoring operation needs to continue. For example, periodically sending query requests to the virtual machine to obtain the value of the memory object's res_async attribute (indicating asynchronous execution status) allows for real-time monitoring of the memory allocation task's progress, enabling timely handling of any anomalies.

[0082] Step S24: If the attribute value is the second preset value, and / or the memory object allocation status is in the completed or terminated state, then the memory device consolidation mechanism is triggered, and corresponding control operations are performed on the virtual machine based on the memory device consolidation mechanism.

[0083] Specifically, when the value of the obtained asynchronous memory pre-allocation attribute is the second preset value, or when the allocation status of the memory object is in the completed or terminated state, the memory device consolidation mechanism will be triggered. The memory device consolidation mechanism is a mechanism used to optimize and manage the memory devices of the virtual machine. When specific conditions (such as attribute values ​​and allocation status conditions) are met, the mechanism will be triggered to reasonably configure and associate memory devices with the Qemu software version through a series of operations, so as to improve the utilization efficiency of virtual machine memory resources and overall performance.

[0084] In this embodiment of the application, a memory device consolidation mechanism is triggered, and corresponding control operations are performed on the virtual machine based on the memory device consolidation mechanism, including the following steps B1-B2:

[0085] Step B1: Using the virtual machine's default memory management protocol, add the virtual dual in-line memory module as a memory device to the virtual machine's configuration environment.

[0086] Specifically, a Virtual Dual In-line Memory Module (PC-DIMM) is a type of computer memory module. In a virtual machine environment, it refers to a concept that uses software simulation to handle memory modules similar to physical memory modules, providing additional memory resources for the virtual machine. The configuration environment includes existing hardware resource simulations (such as virtual CPUs and virtual disks) and related software settings (such as operating systems and drivers). Adding memory devices to this environment allows the virtual machine to recognize and use the newly added memory resources.

[0087] Step B2: In the configuration environment, establish the association between the virtual dual in-line memory module and the Qemu software version of the virtual machine.

[0088] Specifically, after adding the virtual dual in-line memory (DIM) module to the virtual machine configuration environment, it's necessary to establish its association with the Qemu software version. This requires setting relevant parameters or data structures within the virtual machine system to identify it. For example, a pointer to the memory module or a record of its identifier can be added to the Qemu software version's data structure. The virtual DIM module itself should also record the corresponding association information so that subsequent memory operations can accurately locate and collaboratively manage and optimize the use of virtual machine memory resources.

[0089] In this embodiment of the application, the method further includes the following steps:

[0090] Step S31: Obtain the memory devices added within the preset time period.

[0091] In this application embodiment, the preset time period refers to the time period used to define the status of recently added memory devices and perform related processing operations; the memory device refers to the virtual device that provides memory resources for the virtual machine, such as the memory device created by simulating virtual dual in-line memory modules (pc-dimm), etc. These devices are storage units that can be used by the virtual machine during runtime, and their addition, use and management are crucial to the normal operation and performance of the virtual machine.

[0092] Step S32: Match the memory device with the Qemu software version in the virtual machine to obtain the matching result.

[0093] In this embodiment, after obtaining the information of memory devices added within a preset time period, each memory device is matched one by one with the Qemu software version in the virtual machine. During matching, the memory device identification information (such as device number, type, etc.) and the Qemu software version management scope or compatibility type are compared. For example, by comparing whether the device number is within the management scope, whether the type is compatible, etc., the matching result of each memory device and the Qemu software version is obtained, clarifying whether a match is made and the specific matching situation (based on the set rules).

[0094] Step S33: Perform the corresponding processing operation on the memory device according to the matching result.

[0095] In this embodiment of the application, step S33 includes the following steps C1-C2:

[0096] Step C1: If the matching result is that the memory device does not match the Qemu software version, obtain the allocation status of the memory object; if the allocation status is completed or terminated, perform a deletion operation on the memory device; or, if the allocation status is running, end the currently running asynchronous memory allocation task and perform a deletion operation on the memory device after the task ends.

[0097] Specifically, when the matching result indicates that the memory device does not match the Qemu software version, the allocation status of the memory object is first obtained by querying the virtual machine memory management-related data structures or calling the corresponding query interface. If the allocation status is complete or terminated, a deletion command (such as the qmp object_del command) can be issued using a relevant protocol (such as the QMP protocol) to delete the mismatched memory device and release resources. If the allocation status is running, the memory device cannot be deleted directly. Instead, the running asynchronous memory allocation task can be terminated through specific instructions or operations (such as sending a termination signal in the relevant thread), and then the memory device can be processed in the deletion manner described above.

[0098] Step C2: When the matching result shows that the memory device matches the Qemu software version, monitor the usage requirements for the memory device, obtain the allocation status of the memory object according to the usage requirements, and perform usage operations on the memory device when the allocation status is completed or terminated.

[0099] Specifically, when the memory device matches the Qemu software version, the system monitors the memory access and usage by applications and system processes within the virtual machine to track their needs. Based on these needs, it queries relevant data structures or calls query interfaces to obtain the memory object allocation status. If the obtained allocation status is complete or terminated, the memory can be allocated to the corresponding application or system process by updating the memory mapping table, etc.

[0100] As an example, as shown in Figure 4, the process includes: First, libvirt uses the virsh command to attach a device configuration file (dimm.xml); checks the memory slots and maximum memory, and allocates memory slots; constructs the memory device string and backend attributes; creates the memory backend object, the memory device, and updates the memory device. Second, libvirt interacts with Qemu via QMP. Qemu adds the memory backend object and the PC-DIMM device, and queries the memory device; Qemu pre-allocates backend memory and inserts the PC-DIMM via ACPI notification, creating the DIMM object. The guest's udev comes online, and the kernel performs memory hot-plugging operations.

[0101] This embodiment provides a testing method for virtual machine memory management technology. Figure 5 is a flowchart of the testing method for virtual machine memory management technology according to an embodiment of this application. As shown in Figure 5, the process includes the following steps:

[0102] Step S41: Deploy a preset virtual machine software library in a preset virtual environment, and create a first virtual machine, a second virtual machine, and a third virtual machine, wherein the second virtual machine is the virtual machine to be tested, and the first virtual machine and the second virtual machine are control virtual machines.

[0103] Specifically, first, a version of libvirt (virtual machine software library) that supports asynchronous memory pre-allocation is deployed and installed. Next, three virtual machines configured with 4 cores and 8 RAM are created and started, named vm1, vm2, and vm3. These virtual machines are all equipped with a virtual network adapter of the vhost-user type. vm1 and vm3 use open-source QEMU versions that do not support this technology, while vm2 uses a QEMU version that does support this technology. This configuration aims to more comprehensively verify the effectiveness of this technology by comparing the performance of different versions of virtual machines in the same test scenario.

[0104] Step S42: Add a first memory module of preset capacity to the first virtual machine and the second virtual machine respectively, and detect the first output state of the first virtual machine and the second output state of the second virtual machine. Based on the first output state and the second output state, obtain the first test result.

[0105] Specifically, for virtual machines vm1 and vm2, a 120GB memory block was hot-added to each. During the memory addition process, the console output of the virtual machines was checked to see if it was normal (the virtual machines were set to output time information once per second). The result was that the console output of vm1 experienced an interruption lasting 18 seconds, while the console output of vm2 remained completely normal.

[0106] Step S43: Execute specific commands in the first virtual machine and the second virtual machine respectively to obtain the IO read status, and perform hot-add memory operation on the first virtual machine and the second virtual machine to obtain the second test result.

[0107] Specifically, specific commands are executed within virtual machines vm1 and vm2 to test I / O read performance. The specific command is: `sleep 3 && time dd if = / dev / vda of = / tmp / tmp iflag = direct count = 10`. This means that the virtual machine first delays for 3 seconds, then executes the `dd` command. In direct I / O mode, it reads a certain amount of data (here, 10 blocks) from the virtual machine's first virtual disk device ( / dev / vda) and fills the read data into the file " / tmp / tmp". Simultaneously, the `time` command records the execution time of the entire `dd` command for accurate evaluation of disk I / O performance later. Furthermore, immediately after executing this command, hot-add memory is performed on the virtual machine. This is done to observe the impact of hot-adding memory on disk I / O performance. After testing, it was concluded that VM1 took 10.063 seconds to read 5.1k of data, while VM2 took only 0.003 seconds, a difference of several thousand times.

[0108] Step S44: Add a second memory module of preset capacity to the first virtual machine and the second virtual machine respectively, and use the third virtual machine to send data streams to the first virtual machine and the second virtual machine to obtain the first network bandwidth of the first virtual machine and the second network bandwidth of the second virtual machine. Generate a third test result based on the first network bandwidth and the second network bandwidth.

[0109] Specifically, a 120GB memory module was hot-added to both virtual machines (vm1 and vm2). Simultaneously, the `iperf3` command was used from virtual machine (vm3) to send data traffic (i.e., streaming) to both vm1 and vm2 to observe the network bandwidth. The test concluded that vm1 experienced a network outage lasting over 20 seconds, while vm2's network remained uninterrupted and its bandwidth remained normal. This result further highlights the different performance of different virtual machine versions in terms of network bandwidth stability under hot-added memory operations.

[0110] The testing method provided in this application, through the testing steps and corresponding conclusions in the above-mentioned different scenarios, can comprehensively verify the performance of the virtual machine memory management related technical solutions involved in this application in different aspects (such as console output stability, disk I / O performance, network bandwidth stability, etc.), thereby proving its effectiveness in improving the performance and stability of virtual machines.

[0111] This embodiment also provides a virtual machine asynchronous memory allocation device, which is used to implement the above embodiments and preferred embodiments, and will not be repeated as already described. As used below, the term "module" can be a combination of software and / or hardware that implements a predetermined function. Although the device described in the following embodiments is preferably implemented in software, hardware implementation, or a combination of software and hardware, is also possible and contemplated.

[0112] This embodiment provides a virtual machine asynchronous memory allocation device, as shown in Figure 6, including:

[0113] The detection module 61 is used to detect whether the Qemu software version of the virtual machine meets the asynchronous memory pre-allocation conditions;

[0114] The generation module 62 is used to generate the corresponding object-add command according to the virtual machine's preset memory management protocol if the asynchronous memory pre-allocation conditions are met.

[0115] Create module 63 to create the corresponding asynchronous memory allocation task in the virtual machine's iothread based on the parameters of the object-add command, and set the allocation status of the memory object to the running state;

[0116] The control module 64 is used to control the virtual machine to execute asynchronous memory allocation tasks in iothread, obtain the execution results, and adjust the allocation status of memory objects according to the execution results.

[0117] In an optional embodiment of this application, the detection module 61 is used to detect whether there is a pre-allocation requirement for the virtual machine's memory; if there is a pre-allocation requirement, it queries whether the Qemu software version has an asynchronous memory pre-allocation attribute, and if it has an asynchronous memory pre-allocation attribute, it sets the attribute value of the asynchronous memory pre-allocation attribute to a first preset value, thus determining that the Qemu software version meets the asynchronous memory pre-allocation condition; or, if there is no pre-allocation requirement, or if it does not have an asynchronous memory pre-allocation function, it determines that the Qemu software version does not meet the asynchronous memory pre-allocation condition.

[0118] In an optional embodiment of this application, the control module 64 is configured to adjust the allocation state of the memory object to the completed state if the execution result is successful; or, if the execution result is unsuccessful, perform a corresponding rollback operation on the asynchronous memory allocation task and adjust the allocation state of the memory object to the terminated state.

[0119] In an optional embodiment of this application, the apparatus further includes: a sending module, configured to send a main thread release signal to libvirt; receive the main thread release signal through libvirt and obtain the attribute value of the asynchronous memory pre-allocation attribute; if the attribute value is a first preset value, query the allocation status of the memory object, and if the allocation status is in the running state, continue to perform the allocation status monitoring operation; or, if the attribute value is a second preset value, and / or, if the allocation status of the memory object is in the completed state or the terminated state, trigger the memory device consolidation mechanism, and perform corresponding control operations on the virtual machine based on the memory device consolidation mechanism.

[0120] In an optional embodiment of this application, the sending module is used to add the virtual dual in-line memory module as a memory device to the configuration environment of the virtual machine through the virtual machine's preset memory management protocol; and in the configuration environment, establish the association between the virtual dual in-line memory module and the Qemu software version of the virtual machine.

[0121] In an optional embodiment of this application, the apparatus further includes: a matching module, configured to acquire memory devices added within a preset time period; match the memory devices with the Qemu software version in the virtual machine to obtain a matching result; and perform corresponding processing operations on the memory devices according to the matching result.

[0122] In an optional embodiment of this application, the matching module is used to obtain the allocation status of the memory object when the matching result is that the memory device and the Qemu software version do not match; if the allocation status is a completed state or a terminated state, then a deletion operation is performed on the memory device; or, if the allocation status is a running state, then the currently running asynchronous memory allocation task is terminated, and a deletion operation is performed on the memory device after the task is terminated; when the matching result is that the memory device and the Qemu software version match, the usage requirements for the memory device are monitored, the allocation status of the memory object is obtained according to the usage requirements, and a usage operation is performed on the memory device when the allocation status is a completed state or a terminated state.

[0123] Please refer to Figure 7, which is a schematic diagram of the structure of a computer device provided in an optional embodiment of this application. As shown in Figure 7, the computer device includes one or more processors 10, a memory 20, and interfaces for connecting the various components, including high-speed interfaces and low-speed interfaces. The various components communicate with each other using different buses and can be mounted on a common motherboard or otherwise installed as needed. The processor can process instructions executed within the computer device, including instructions stored in or on memory to display graphical information of a GUI on an external input / output device (such as a display device coupled to the interface). In some optional embodiments, multiple processors and / or multiple buses can be used with multiple memories and multiple memory modules, if desired. Similarly, multiple computer devices can be connected, each providing some of the necessary operations (e.g., as a server array, a group of blade servers, or a multiprocessor system).

[0124] Processor 10 may be a central processing unit, a network processor, or a combination thereof. Processor 10 may further include a hardware chip. The hardware chip may be an application-specific integrated circuit (ASIC), a programmable logic device (PLD), or a combination thereof. The programmable logic device may be a complex programmable logic device (CAMP), a field-programmable gate array (FPGA), a general-purpose array logic (GDA), or any combination thereof.

[0125] The memory 20 stores instructions executable by at least one processor 10 to cause at least one processor 10 to perform the method shown in the above embodiments.

[0126] The memory 20 may include a program storage area and a data storage area. The program storage area may store the operating system and applications required for at least one function; the data storage area may store data created based on the use of the computer device as shown by a landing page for an app. Furthermore, the memory 20 may include high-speed random access memory and may also include non-transitory memory, such as at least one disk storage device, flash memory device, or other non-transitory solid-state storage device. In some alternative embodiments, the memory 20 may optionally include memory remotely located relative to the processor 10, which can be connected to the computer device via a network. Examples of such networks include, but are not limited to, the Internet, intranets, local area networks, mobile communication networks, and combinations thereof.

[0127] The memory 20 may include volatile memory, such as random access memory; the memory may also include non-volatile memory, such as flash memory, hard disk or solid-state drive; the memory 20 may also include a combination of the above types of memory.

[0128] The computer device also includes a communication interface 30 for communicating with other devices or communication networks.

[0129] This application also provides a computer-readable storage medium. The methods described in this application can be implemented in hardware or firmware, or implemented as recordable on a storage medium, or implemented as computer code downloaded over a network and originally stored on a remote storage medium or a non-transitory machine-readable storage medium and subsequently stored on a local storage medium. Thus, the methods described herein can be processed by software stored on a storage medium using a general-purpose computer, a dedicated processor, or programmable or dedicated hardware. The storage medium can be a magnetic disk, optical disk, read-only memory, random access memory, flash memory, hard disk, or solid-state drive, etc.; further, the storage medium can also include combinations of the above types of memory. It is understood that computers, processors, microprocessor controllers, or programmable hardware include storage components capable of storing or receiving software or computer code. When the software or computer code is accessed and executed by the computer, processor, or hardware, the methods shown in the above embodiments are implemented.

[0130] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0131] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are relatively specific and detailed, they should not be construed as limiting the scope of the patent application. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this patent application should be determined by the appended claims.

Claims

1. A method for allocating asynchronous memory in a virtual machine, executed by a computer device, wherein, The method includes: Check whether the Qemu software version of the virtual machine meets the asynchronous memory pre-allocation conditions; If the asynchronous memory pre-allocation conditions are met, the corresponding object-add command is generated through the virtual machine's preset memory management protocol; Based on the parameters of the `object-add` command, a corresponding asynchronous memory allocation task is created in the virtual machine's iothread, and the allocation status of the memory object is set to running; and, The virtual machine is controlled to execute the asynchronous memory allocation task in the iothread, the execution result is obtained, and the allocation state of the memory object is adjusted according to the execution result.

2. The method according to claim 1, wherein, The step of detecting whether the Qemu software version of the virtual machine meets the asynchronous memory pre-allocation conditions includes: Detect whether the virtual machine has a pre-allocation requirement for memory; If the pre-allocation requirement exists, then query whether the Qemu software version has an asynchronous memory pre-allocation attribute. If it does, set the attribute value of the asynchronous memory pre-allocation attribute to a first preset value, thus determining that the Qemu software version meets the asynchronous memory pre-allocation condition; and... If the pre-allocation requirement does not exist, or if the asynchronous memory pre-allocation function is not available, then the Qemu software version is determined to not meet the asynchronous memory pre-allocation conditions.

3. The method according to claim 1, wherein, The step of adjusting the allocation state of the memory object based on the execution result includes: If the execution result is successful, the allocation status of the Qemu software version is adjusted to the completed state; and if the execution result is unsuccessful, the corresponding rollback operation is performed on the asynchronous memory allocation task, and the allocation status of the Qemu software version is adjusted to the terminated state.

4. The method according to claim 1, wherein, After creating the corresponding asynchronous memory allocation task in the virtual machine's iothread based on the parameters of the object-add command, the method further includes: Send the main thread release signal to libvirt; The main thread release signal is received through libvirt, and the attribute value of the asynchronous memory pre-allocation attribute is obtained. If the attribute value is a first preset value, then the allocation status of the memory object is queried. If the allocation status is in the running state, the allocation status monitoring operation continues; and, If the attribute value is a second preset value, and / or the allocation status of the memory object is a completed state or a terminated state, then the memory device consolidation mechanism is triggered, and corresponding control operations are performed on the virtual machine based on the memory device consolidation mechanism.

5. The method according to claim 4, wherein, The triggering of the memory device consolidation mechanism, and the execution of corresponding control operations on the virtual machine based on the memory device consolidation mechanism, includes: The virtual dual in-line memory module is added as a memory device to the virtual machine's configuration environment using the virtual machine's preset memory management protocol; and, In the configuration environment, an association is established between the virtual dual in-line memory module and the Qemu software version of the virtual machine.

6. The method according to claim 1, wherein, The method further includes: Retrieve memory devices added within a preset time period; The memory device is matched with the Qemu software version in the virtual machine to obtain the matching result; and, The corresponding processing operation is performed on the memory device based on the matching result.

7. The method according to claim 6, wherein, The step of performing corresponding processing operations on the memory device based on the matching result includes: When the matching result indicates that the memory device and the Qemu software version do not match, the allocation status of the memory object is obtained; if the allocation status is a completed or terminated state, a deletion operation is performed on the memory device; or, if the allocation status is a running state, the currently running asynchronous memory allocation task is terminated, and a deletion operation is performed on the memory device after the task is completed; and, When the matching result is that the memory device matches the Qemu software version, the usage requirements for the memory device are monitored, the allocation status of the memory object is obtained according to the usage requirements, and the usage operation is performed on the memory device when the allocation status is a completed state or a terminated state.

8. A virtual machine asynchronous memory allocation device, wherein, The device includes: The detection module is used to detect whether the Qemu software version of the virtual machine meets the asynchronous memory pre-allocation conditions; The generation module is used to generate the corresponding object-add command according to the virtual machine's preset memory management protocol if the asynchronous memory pre-allocation conditions are met. A module is created to create a corresponding asynchronous memory allocation task in the virtual machine's iothread based on the parameters of the `object-add` command, and to set the allocation status of the memory object to the running state; and, The control module is used to control the virtual machine to execute the asynchronous memory allocation task in the iothread, obtain the execution result, and adjust the allocation state of the memory object according to the execution result.

9. A computer device comprising a memory and a processor, wherein, The memory and the processor are communicatively connected to each other. The memory stores computer-readable instructions, and the processor executes the computer-readable instructions to perform the method of any one of claims 1 to 7.

10. A computer-readable storage medium storing computer-readable instructions, wherein, The computer-readable instructions are used to cause a computer to perform the method of any one of claims 1 to 7.

Images