VHost controller management method, apparatus and device, and readable storage medium

Abstract

The invention provides a vhost controller management method, device and equipment and a readable storage medium, and the method comprises the steps: responding to a vhost target process starting event, creating a plurality of reactor threads, and binding each reactor thread to a different calculation unit; the method comprises the following steps of: configuring a schedulable working thread of each reactor thread, and respectively configuring an independent storage engine client instance for each working thread; according to virtual annular queues vRing which are configured in a virtual machine in advance and correspond to the number of the working threads, different vRing is configured for each working thread; and respectively creating a polling task on each working thread. Through the technical scheme of the specification, a plurality of reactor threads and corresponding working threads are created for a single vHost controller, and a plurality of vRings of a virtual machine are respectively bound to different working threads, so that full utilization of a plurality of computing unit cores by the single controller is realized.

Description

vHost controller management methods, devices, equipment, and readable storage media Technical Field

[0001] This specification relates to the field of communication technology, and in particular to a vHost controller management method, apparatus, device, and readable storage medium. Background Technology

[0002] Hyper-Converged Infrastructure (HCI), by highly integrating computing, storage, and network resources onto general-purpose server hardware, offers advantages such as simplified deployment, elastic scaling, and unified operation and maintenance, making it the mainstream architecture for building private clouds, edge computing, and enterprise-level virtualization platforms. In HCI systems, the storage performance requirements of virtual machines (VMs) are particularly critical, especially with increasingly stringent demands for low-latency, high-throughput block device I / O. To meet this need, the industry widely adopts kernel-based block device protocol stacks (such as iSCSI or NVMe over TCP) combined with QEMU / KVM virtualization solutions, using Virtio semi-virtualization drivers to enable communication between VMs and backend storage. However, traditional solutions suffer from significant performance bottlenecks: on the one hand, I / O requests must cross the user-space and kernel-space boundaries multiple times, incurring context switching overhead; on the other hand, QEMU, as an intermediary layer, introduces additional scheduling latency and memory copying when handling Virtio requests, making it difficult to fully utilize the potential of modern high-speed NVMe SSDs and other underlying storage media.

[0003] SPDK utilizes polling, lock-free data structures, zero-copy, and CPU core binding technologies to bypass the operating system kernel and interact directly with hardware, significantly improving I / O processing efficiency. Building on this, SPDK provides the vhosttarget module, allowing virtual machines to communicate directly with user-space storage backends via the standard Virtio protocol, thus completely bypassing the QEMU I / O path and achieving near-bare-metal performance. This solution has already been applied in some high-performance scenarios and has demonstrated significant advantages.

[0004] Existing SPDK-based vhost target implementations still have technical flaws, severely limiting their overall performance under complex business workloads. Currently, the vhost controller only supports a single-threaded model, meaning a controller instance can only be bound to a single SPDK reactor thread. Even if the virtual machine is configured with multiple Virtio queues, true parallel processing is impossible; all queues are ultimately polled serially by the same CPU core, resulting in inefficient utilization of multi-core CPU resources, creating a performance bottleneck, especially in high-concurrency I / O scenarios. Summary of the Invention

[0005] In view of this, this specification provides a vHost controller management method, apparatus, device, and readable storage medium to improve the aforementioned problem of poor vHost performance.

[0006] The specific technical solution is as follows: This specification provides a vHost controller management method applied to hyperconverged management devices. The method includes: in response to a vhost target process startup event, creating multiple reactor threads associated with the vhost target process, and binding each reactor thread to a different computing unit; configuring schedulable worker threads for each reactor thread, configuring independent storage engine client instances for each worker thread, and configuring resource mutual exclusion for each storage engine client instance; configuring different vRings for each worker thread according to a virtual circular queue vRing pre-configured in the QEMU virtual machine corresponding to the number of worker threads; and creating polling tasks on each worker thread, wherein the polling tasks are used to indicate IO requests for monitoring vRings.

[0007] As a technical solution, the method of creating polling tasks on each worker thread, wherein the polling tasks are used to indicate the monitoring of vRing IO requests, includes: executing the polling tasks according to a set time interval, wherein the set time interval is dynamically positively correlated with the utilization rate of the computing unit bound to the reactor thread to which the worker thread associated with the polling task belongs.

[0008] As a technical solution, polling tasks are created on each worker thread, and the polling tasks are used to instruct the monitoring of vRing IO requests, including: each worker thread processes the IO requests of its bound vRing in parallel according to the monitored IO requests.

[0009] As a technical solution, the step of creating polling tasks on each worker thread, wherein the polling tasks are used to indicate the monitoring of vRing IO requests, includes: creating a first event listener epoll fd on each reactor thread; creating a second event listener epoll fd on each worker thread and registering the second event listener to the first event listener of the reactor thread to which it belongs; registering the vRing notification file descriptor kick fd bound to each worker thread and the storage engine client instance completion notification file descriptor stor fd to the second event listener of that worker thread.

[0010] This specification also provides a vHost controller management device for use in hyperconverged infrastructure management devices. The device includes: a first module, configured to create multiple reactor threads associated with the vhost target process in response to a vhost target process startup event, and bind each reactor thread to a different computing unit; the first module is also configured to configure schedulable worker threads for each reactor thread, configure an independent storage engine client instance for each worker thread, and configure resource mutual exclusion for each storage engine client instance; a second module, configured to configure different vRings for each worker thread according to a virtual circular queue vRing pre-configured in the QEMU virtual machine corresponding to the number of worker threads; and a third module, configured to create polling tasks on each worker thread, the polling tasks being used to indicate IO requests for monitoring the vRing.

[0011] As a technical solution, the method of creating polling tasks on each worker thread, wherein the polling tasks are used to indicate the monitoring of vRing IO requests, includes: executing the polling tasks according to a set time interval, wherein the set time interval is dynamically positively correlated with the utilization rate of the computing unit bound to the reactor thread to which the worker thread associated with the polling task belongs.

[0012] As a technical solution, polling tasks are created on each worker thread, and the polling tasks are used to instruct the monitoring of vRing IO requests, including: each worker thread processes the IO requests of its bound vRing in parallel according to the monitored IO requests.

[0013] As a technical solution, the step of creating polling tasks on each worker thread, wherein the polling tasks are used to indicate the monitoring of vRing IO requests, includes: creating a first event listener epoll fd on each reactor thread; creating a second event listener epoll fd on each worker thread and registering the second event listener to the first event listener of the reactor thread to which it belongs; registering the vRing notification file descriptor kick fd bound to each worker thread and the storage engine client instance completion notification file descriptor stor fd to the second event listener of that worker thread.

[0014] This specification also provides an electronic device, including a processor and a readable storage medium storing machine-executable instructions that can be executed by the processor, the processor executing the machine-executable instructions to implement the aforementioned vHost controller management method.

[0015] This specification also provides a readable storage medium storing machine-executable instructions that, when invoked and executed by a processor, cause the processor to implement the aforementioned vHost controller management method.

[0016] The technical solution provided in this specification offers at least the following benefits: By creating multiple reactor threads and corresponding worker threads for a single vHost controller, and binding multiple vRings of the virtual machine to different worker threads, full utilization of multiple computing unit cores by a single controller is achieved. Each worker thread is equipped with an independent storage engine client instance, ensuring mutual exclusion access to input / output path resources and avoiding inter-thread contention. This design breaks through the performance bottleneck of the traditional single-threaded model, significantly improving the input / output concurrent processing capability and overall throughput of the vHost controller. Attached Figure Description

[0017] To more clearly illustrate the technical solutions in the embodiments of this specification or the prior art, the drawings used in the description of the embodiments of this specification or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments recorded in this specification. For those skilled in the art, other drawings can be obtained based on these drawings of the embodiments of this specification.

[0018] Figure 1 is a flowchart of a vHost controller management method according to one embodiment of this specification; Figure 2 is a topology diagram according to one embodiment of this specification; Figure 3 is a structural diagram of a vHost controller management device according to one embodiment of this specification; Figure 4 is a hardware structure diagram of an electronic device according to one embodiment of this specification.

[0019] Reference numerals: Module 1 21, Module 22, Module 3 23. Detailed Implementation

[0020] The terminology used in the embodiments described herein is for the purpose of describing particular embodiments only and is not intended to limit the scope of this specification. The singular forms “a,” “described,” and “the” as used in this specification and claims are also intended to include the plural forms unless the context clearly indicates otherwise. It should also be understood that the term “and / or” as used herein refers to any and all possible combinations comprising one or more of the associated listed items.

[0021] It should be understood that although the terms first, second, third, etc., may be used to describe various information in embodiments of this specification, such information should not be limited to these terms. These terms are only used to distinguish information of the same type from one another. For example, without departing from the scope of this specification, first information may also be referred to as second information, and similarly, second information may also be referred to as first information. Depending on the context, the word "if" may also be interpreted as "when," "when," or "in response to a determination."

[0022] This specification provides a vHost controller management method, apparatus, device, and readable storage medium to at least improve one of the above-mentioned technical problems.

[0023] The specific technical solution is described below.

[0024] In one embodiment, this specification provides a vHost controller management method applied to a hyperconverged management device. The method includes: in response to a vhost target process startup event, creating multiple reactor threads associated with the vhost target process, and binding each reactor thread to a different computing unit; configuring schedulable worker threads for each reactor thread, configuring an independent storage engine client instance for each worker thread, and configuring resource mutual exclusion for each storage engine client instance; configuring a different vRing for each worker thread according to a virtual circular queue vRing pre-configured in a QEMU virtual machine corresponding to the number of worker threads; and creating a polling task on each worker thread, the polling task being used to indicate IO requests for monitoring the vRing.

[0025] This implementation proposes a vHost controller management method, which reconstructs the task scheduling and resource allocation mechanism inside the vhost target, enabling it to support collaborative work of multiple reactor threads, and equips each worker thread with an independent storage engine client instance and a dedicated virtual ring queue (vRing), thereby achieving parallel I / O processing of multiple queues.

[0026] Specifically, as shown in Figure 1, the steps are as follows. The order of these steps can be changed according to the needs of the actual application scenario: Step S11, in response to the vhost target process startup event, create multiple reactor threads associated with the vhost target process and bind each reactor thread to a different computing unit.

[0027] When the hyperconverged management device detects a vhost target process startup event (e.g., a user creates a virtual disk connected to a distributed storage volume via the management interface and specifies the use of the vhost protocol for connection), it first initializes the vhost target main process context and immediately enters the multi-threaded architecture construction phase. During this phase, the management device dynamically determines the number of Reactor threads to be created based on the current physical host's CPU topology (such as the number of logical cores, NUMA node distribution, etc.) and preset performance policies.

[0028] For example, on a server with dual Intel Xeon Silver 4310 processors (24 cores and 48 threads in total), if the target virtual machine is expected to handle high-concurrency database loads, 8 Reactor threads can be configured to be created; for lightweight web applications, only 2–4 may be created. Each Reactor thread, after creation, is immediately and strictly bound to an independent logical computing unit (i.e., a CPU core) through the CPU affinity interface provided by the operating system (such as pthread_setaffinity_np). This avoids cache invalidation and scheduling jitter caused by thread migration, ensuring that each Reactor runs exclusively on its dedicated core, maximizing instruction execution efficiency.

[0029] Step S12: Configure the schedulable worker threads for each reactor thread, configure an independent storage engine client instance for each worker thread, and configure resource mutual exclusion for each storage engine client instance.

[0030] Each Reactor thread can schedule one or more worker threads. However, in the preferred embodiment of this work, in order to simplify the scheduling logic and maintain a one-to-one correspondence, each Reactor is usually configured with a dedicated worker thread.

[0031] These worker threads are not native operating system threads, but rather lightweight task execution units built within the SPDK framework based on an event-driven model, with their respective Reactors responsible for polling and scheduling. Each worker thread initializes an independent Storage Engine Client instance. This client instance encapsulates all the context information required for communication with the backend distributed storage system (such as Ceph RBD, NVMe-oF Target, or a self-developed high-performance block storage service), including connection handles, session tokens, buffer pools, and command queues. Each client instance is completely isolated at the resource level, possessing its own independent memory pool, command descriptor array, and completion queue. There are no shared data structures between them, thus eliminating the locking mechanisms or atomic operations required for cross-thread access and avoiding performance jitter or latency spikes caused by resource contention.

[0032] For example, while worker thread A is submitting a 4KB random write request to the storage cluster, worker thread B can simultaneously handle another 64KB sequential read request. The two do not interfere with each other, and each completes protocol encapsulation, DMA mapping and network transmission in its own private client context, which greatly improves the parallelism and determinism of the I / O path.

[0033] Step S13: Configure a different vRing for each worker thread according to the virtual circular queue vRing pre-configured in the QEMU virtual machine corresponding to the number of worker threads.

[0034] To ensure that the Virtio configuration on the front-end virtual machine side is strictly aligned with the multi-threaded architecture of the back-end vhost target, the administrator or automated orchestration system must pre-configure the multiqueue parameter of the virtual disk device before starting the QEMU virtual machine, explicitly specifying the number of Virtio queues (num_queues) to be enabled. This number must be consistent with the number of worker threads planned to be created on the vhost target side.

[0035] For example, if you plan to use 4 worker threads, the QEMU startup command must include parameters such as "mq=on,queues=4". Once the virtual machine starts and completes Virtio driver initialization, the operating system kernel (such as the Linux virtio-blk driver) will automatically distribute I / O requests to multiple hardware queues, each corresponding to a vRing. During initialization, vhosttarget obtains the shared memory addresses, descriptor table locations, and event notification file descriptors (kickfd) of these vRings through the control channel (such as a Unix Domain Socket) established with QEMU.

[0036] These vRings are mapped sequentially to the previously configured worker threads: the first vRing is assigned to worker thread 0, the second to worker thread 1, and so on. The static binding strategy ensures that I / O requests originating from the virtual machine, after entering the vhost target via a specific vRing, are always handled by a fixed, dedicated worker thread, forming an end-to-end lock-free, cross-connected I / O pipeline.

[0037] For example, when an application inside a virtual machine initiates a write operation, the Linux kernel's blk-mq subsystem may route it to hardware queue number 2. The request is then written to an available descriptor slot in vRing number 2 and a kick notification is triggered via the eventfd mechanism. Worker thread 1 on the vhost target side (bound to vRing number 2) captures this event in its polling task, immediately parses the request content from vRing, calls its private storage engine client instance, and writes the data directly to the backend storage. The entire process does not require any global locks or cross-thread synchronization.

[0038] Step S14: Create polling tasks on each worker thread, the polling tasks being used to instruct the monitoring of vRing's IO requests.

[0039] Each worker thread registers a dedicated poller in the scheduling loop of its Reactor. The poller continuously monitors the status of available descriptors of the vRing it is bound to, as well as the corresponding kickfd event notifications.

[0040] Specifically, the polling task periodically checks whether the available ring index of the vRing has changed, or listens for whether the kickfd is set (in interrupt mode) via epoll_wait. Once a new I / O request arrives, it immediately extracts the request descriptor from the vRing and parses out key information such as the operation type (read / write), logical block address (LBA), data buffer pointer, and length. Subsequently, the task calls the submission interface of the local storage engine client instance to asynchronously send the request to the distributed storage backend.

[0041] Since each worker thread has an independent client instance and buffer management mechanism, the entire request processing flow is completed within the context of the current thread, avoiding the lock contention overhead introduced by the shared request queue in traditional solutions.

[0042] In addition, to support subsequent hybrid working modes (polling / interrupt adaptive switching), each polling task also has a built-in performance monitoring module that calculates the CPU busy percentage of the current Reactor thread in the past second in real time, which serves as the basis for mode switching decisions.

[0043] For example, in scenarios with continuous high load (such as virtual machines performing large-scale database imports), all polling tasks remain active, ensuring microsecond-level response. During the idle period of batch processing at night, if a worker thread's busy percent is below 50% for 3 consecutive seconds, its polling task will automatically switch to an interrupt-waiting mode based on epoll, releasing CPU resources and being woken up again when the next kick event arrives, thereby significantly reducing energy consumption while ensuring performance.

[0044] In one implementation, creating polling tasks on each worker thread, the polling tasks being used to indicate monitoring vRing IO requests, includes: executing the polling tasks according to a set time interval, the set time interval being dynamically positively correlated with the utilization rate of the computing unit bound to the reactor thread to which the worker thread associated with the polling task belongs.

[0045] In one implementation, the step of creating polling tasks on each worker thread, the polling tasks being used to instruct the monitoring of vRing IO requests, includes: each worker thread processing the IO requests bound to its vRing in parallel based on the monitored IO requests.

[0046] In one implementation, the step of creating polling tasks on each worker thread, the polling tasks being used to indicate the monitoring of vRing IO requests, includes: creating a first event listener epoll fd on each reactor thread; creating a second event listener epoll fd on each worker thread and registering the second event listener to the first event listener of the reactor thread to which it belongs; and registering the vRing notification file descriptor kick fd bound to each worker thread and the storage engine client instance completion notification file descriptor stor fd to the second event listener of that worker thread.

[0047] In one implementation, as shown in Figure 2, after the vhost target process starts, it creates and manages multiple reactor threads. The reactor thread is the basic scheduling unit, and each reactor thread is an event loop bound to a specific CPU core.

[0048] The hyperconverged management appliance determines how many reactor threads to create for the vhost target process during startup based on the host server's CPU topology and preset resource allocation policies. For example, on a server with two NUMA nodes, each with 12 physical cores, the management appliance might decide to create four reactor threads to strike a balance between performance and resource consumption.

[0049] Once created, each reactor thread is bound to an independent, pre-planned computing unit, typically a physical CPU core or a logical core enabled by Hyper-Threading. The purpose of binding is to avoid cache invalidation and context switching overhead caused by thread migration between cores, thereby ensuring the stability and predictability of data processing latency. The binding operation is accomplished by calling the CPU affinity setting interface provided by the operating system (such as Linux's pthread_setaffinity_np or sched_setaffinity system calls), ensuring that each reactor thread can only run on the specified core.

[0050] After a reactor thread is successfully created and bound, each reactor thread creates and configures its subordinate worker threads. Worker threads are the entities that actually execute input / output request processing tasks. Each reactor thread can schedule one or more worker threads, the number of which can be configured based on the expected parallelism and workload characteristics.

[0051] A typical configuration is to create one worker thread for each reactor thread, forming a one-to-one relationship. This simplifies the scheduling model and reduces communication overhead. In some scenarios, it may be reasonable for one reactor thread to manage multiple worker threads, such as when processing input / output traffic with different priorities or characteristics.

[0052] Each worker thread is configured with an independent storage engine client. The storage engine client is the interface through which the vhost target process communicates with the backend distributed storage system (such as Ceph or a custom distributed storage engine). By creating an independent client instance for each worker thread, it is ensured that each thread has its own dedicated channel for interacting with the storage engine. The resources managed by these client instances, such as network connections, memory buffers, and session state, are configured to be mutually exclusive. When a worker thread accesses the resources of its client instance, it does not need to consider synchronization issues with other worker threads because the resources are private.

[0053] When configuring a virtual machine (usually via QEMU command-line arguments or libvirt domain XML configuration), the number of virtual ring queues (vRings) for the virtual machine is pre-set. A vRing is a core data structure in the Virtio paravirtualization architecture, a shared memory ring used for communication between the front-end driver in the virtual machine kernel and the back-end process of the vhost target on the host machine. The number of vRings configured here must correspond to the number of worker threads created by the vhost target process for the corresponding controller. For example, if the vhost target prepares four worker threads for a virtual machine's controller, then four vRing queues need to be configured when starting that virtual machine.

[0054] When a virtual machine starts and attempts to connect to the vhost target process, during the connection establishment process, vhosttarget negotiates the vhost-user protocol with QEMU. During this phase, vhosttarget identifies the vRing provided by the virtual machine based on the negotiated information and performs a crucial binding operation: assigning each vRing to a specific worker thread. This binding is one-to-one; the first vRing is assigned to the first worker thread, the second vRing to the second worker thread, and so on. This mapping ensures that input / output requests from different queues of the virtual machine can be processed in parallel by different worker threads, thus achieving true multi-queue parallel processing capabilities and fully utilizing the computing power of multi-core CPUs.

[0055] A polling task is created on the worker thread. Each worker thread initializes a continuously running loop task whose core function is to actively monitor the state of the vRing it is bound to.

[0056] The polling task periodically checks the available rings of the vRing for new descriptors placed by the virtual machine frontend driver. These descriptors point to the location in the virtual machine memory of the data that needs to be read or written. The polling task performs checks at a set frequency. Upon discovering a new request, it extracts the request's descriptor information from the vRing, parsing parameters such as the operation type (read or write), data address, and data length. Then, the worker thread calls its independent storage engine client instance to submit these requests to the backend distributed storage engine for processing.

[0057] This polling process is continuous. As long as the vhost target process is running, the worker thread will continuously check the vRing it is responsible for, ensuring that the virtual machine's input / output requests are processed in a timely manner. Although pure polling mode consumes some CPU resources when idle, it provides the lowest latency and highest throughput under high load.

[0058] To manage resource consumption more precisely and adapt to dynamic loads, an adaptive mode switching mechanism can be employed. This means that, in addition to the polling task mentioned above, a parallel monitoring system is established. Each reactor thread periodically (e.g., every second) calculates the total CPU time consumed by all its subordinate worker threads when performing actual input / output tasks, and calculates a CPU busy percentage. This percentage reflects the utilization of the cores bound to that reactor thread. A central scheduler collects the utilization data reported by all reactor threads. Based on preset thresholds and decision algorithms (e.g., if the utilization is below 50% for three consecutive statistical periods), the scheduler can decide to switch a reactor thread and its worker threads from polling mode to interrupt mode. In interrupt mode, worker threads no longer actively poll the vRing, but instead listen to an event file descriptor (usually an eventfd, called kickfd) associated with the vRing through Linux's epoll mechanism. When the virtual machine has a new input / output request, it writes to this kickfd, triggering an event that wakes up the worker thread that is sleeping on the epoll_wait system call. Once the thread is awakened, it processes the requests in the vRing. Similarly, when the storage engine completes an I / O operation, it notifies the worker thread via another event file descriptor. This mechanism allows the CPU to enter a sleep state under low load, significantly reducing energy consumption. When the load increases again, the system can automatically switch back to the high-performance polling mode. This dynamic adjustment capability makes this method not only high-performing but also very intelligent and environmentally friendly.

[0059] In one embodiment, as shown in Figure 3, this specification also provides a vHost controller management device applied to a hyperconverged management device. The device includes: a first module, configured to create multiple reactor threads associated with the vhost target process in response to a vhost target process startup event, and bind each reactor thread to a different computing unit; the first module is further configured to configure schedulable worker threads for each reactor thread, configure independent storage engine client instances for each worker thread, and configure resource mutual exclusion for each storage engine client instance; a second module, configured to configure different vRings for each worker thread according to a virtual circular queue vRing pre-configured in the QEMU virtual machine corresponding to the number of worker threads; and a third module, configured to create polling tasks on each worker thread, the polling tasks being used to indicate IO requests for monitoring vRings.

[0060] In one implementation, creating polling tasks on each worker thread, the polling tasks being used to indicate monitoring vRing IO requests, includes: executing the polling tasks according to a set time interval, the set time interval being dynamically positively correlated with the utilization rate of the computing unit bound to the reactor thread to which the worker thread associated with the polling task belongs.

[0061] In one implementation, the step of creating polling tasks on each worker thread, the polling tasks being used to instruct the monitoring of vRing IO requests, includes: each worker thread processing the IO requests bound to its vRing in parallel based on the monitored IO requests.

[0062] In one implementation, the step of creating polling tasks on each worker thread, the polling tasks being used to indicate the monitoring of vRing IO requests, includes: creating a first event listener epoll fd on each reactor thread; creating a second event listener epoll fd on each worker thread and registering the second event listener to the first event listener of the reactor thread to which it belongs; and registering the vRing notification file descriptor kick fd bound to each worker thread and the storage engine client instance completion notification file descriptor stor fd to the second event listener of that worker thread.

[0063] The implementation methods of the apparatus are the same as or similar to the corresponding implementation methods, and will not be described again here.

[0064] In one embodiment, this specification provides an electronic device including a processor and a readable storage medium storing machine-executable instructions that can be executed by the processor. The processor executes the machine-executable instructions to implement the aforementioned vHost controller management method. From a hardware perspective, a hardware architecture diagram can be seen in Figure 4.

[0065] In one embodiment, this specification provides a readable storage medium storing machine-executable instructions that, when invoked and executed by a processor, cause the processor to implement the aforementioned vHost controller management method.

[0066] Here, a readable storage medium can be any electronic, magnetic, optical, or other physical storage device that can contain or store information, such as executable instructions, data, etc. For example, a readable storage medium can be: RAM (Random Access Memory), volatile memory, non-volatile memory, flash memory, storage drives (such as hard disk drives), solid-state drives, any type of storage disk (such as optical discs, DVDs, etc.), or similar storage media, or combinations thereof.

[0067] The systems, devices, modules, or units described in the above embodiments can be implemented by computer chips or entities, or by products with certain functions. A typical implementation device is a computer, which can take the form of a personal computer, laptop computer, cellular phone, camera phone, smartphone, personal digital assistant, media player, navigation device, email sending and receiving device, game console, tablet computer, wearable device, or any combination of these devices.

[0068] For ease of description, the above devices are described in terms of function, divided into various units. Of course, in implementing this specification, the functions of each unit can be implemented in one or more software and / or hardware components.

[0069] Those skilled in the art will understand that embodiments of this specification can be provided as methods, systems, or computer program products. Therefore, this specification can take the form of a completely hardware implementation, a completely software implementation, or an implementation combining software and hardware aspects. Furthermore, embodiments of this specification can take the form of a computer program product implemented on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0070] This specification is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this specification. It should be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions specified in one or more blocks of the flowchart illustrations and / or one or more blocks of the block diagrams.

[0071] Furthermore, these computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means that implement the functions specified in one or more flowcharts and / or one or more block diagrams.

[0072] These computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer-implemented process, such that the instructions, which execute on the computer or other programmable apparatus, provide steps for implementing the functions specified in one or more flowcharts and / or one or more block diagrams.

[0073] Those skilled in the art will understand that embodiments of this specification can be provided as methods, systems, or computer program products. Therefore, this specification can take the form of a completely hardware implementation, a completely software implementation, or an implementation combining software and hardware aspects. Furthermore, this specification can take the form of a computer program product implemented on one or more computer-usable storage media (which may include, but are not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0074] The above description is merely an embodiment of this specification and is not intended to limit this specification. Various modifications and variations can be made to this specification by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this specification should be included within the scope of the claims of this specification.

Claims

1. A vHost controller management method, characterized in that, The method, applied to hyperconverged management devices, includes: in response to a vhost target process startup event, creating multiple reactor threads associated with the vhost target process, and binding each reactor thread to a different computing unit; configuring schedulable worker threads for each reactor thread, configuring an independent storage engine client instance for each worker thread, and configuring resource mutual exclusion for each storage engine client instance; configuring a different vRing for each worker thread according to a virtual circular queue vRing pre-configured in a QEMU virtual machine corresponding to the number of worker threads; and creating a polling task on each worker thread, the polling task being used to indicate IO requests for monitoring the vRing.

2. The method according to claim 1, characterized in that, The step of creating polling tasks on each worker thread, wherein the polling tasks are used to indicate the monitoring of vRing IO requests, includes: executing the polling tasks according to a set time interval, wherein the set time interval is dynamically positively correlated with the utilization rate of the computing unit bound to the reactor thread to which the worker thread associated with the polling task belongs.

3. The method according to claim 1, characterized in that, The process of creating polling tasks on each worker thread, wherein the polling tasks are used to instruct the monitoring of vRing IO requests, includes: each worker thread processing the IO requests of its bound vRing in parallel according to the monitored IO requests.

4. The method according to claim 1, characterized in that, The step of creating polling tasks on each worker thread, wherein the polling tasks are used to instruct the monitoring of vRing IO requests, includes: creating a first event listener epoll fd on each reactor thread; creating a second event listener epoll fd on each worker thread and registering the second event listener to the first event listener of the reactor thread to which it belongs; and registering the vRing notification file descriptor kick fd bound to each worker thread and the storage engine client instance completion notification file descriptor stor fd to the second event listener of that worker thread.

5. A vHost controller management device, characterized in that, The device, applied to hyperconverged infrastructure management equipment, includes: a first module for responding to a vhost target process startup event, creating multiple reactor threads associated with the vhost target process, and binding each reactor thread to a different computing unit; the first module is also used to configure schedulable worker threads for each reactor thread, configure an independent storage engine client instance for each worker thread, and configure resource mutual exclusion for each storage engine client instance; a second module for configuring different vRings for each worker thread according to a virtual circular queue vRing pre-configured in a QEMU virtual machine corresponding to the number of worker threads; and a third module for creating polling tasks on each worker thread, the polling tasks being used to indicate IO requests for monitoring the vRing.

6. The apparatus according to claim 5, characterized in that, The step of creating polling tasks on each worker thread, wherein the polling tasks are used to indicate the monitoring of vRing IO requests, includes: executing the polling tasks according to a set time interval, wherein the set time interval is dynamically positively correlated with the utilization rate of the computing unit bound to the reactor thread to which the worker thread associated with the polling task belongs.

7. The apparatus according to claim 5, characterized in that, The process of creating polling tasks on each worker thread, wherein the polling tasks are used to instruct the monitoring of vRing IO requests, includes: each worker thread processing the IO requests of its bound vRing in parallel according to the monitored IO requests.

8. The apparatus according to claim 5, characterized in that, The step of creating polling tasks on each worker thread, wherein the polling tasks are used to instruct the monitoring of vRing IO requests, includes: creating a first event listener epoll fd on each reactor thread; creating a second event listener epoll fd on each worker thread and registering the second event listener to the first event listener of the reactor thread to which it belongs; and registering the vRing notification file descriptor kick fd bound to each worker thread and the storage engine client instance completion notification file descriptor stor fd to the second event listener of that worker thread.

9. An electronic device, characterized in that, include: A processor and a readable storage medium storing machine-executable instructions that can be executed by the processor to implement the method of any one of claims 1-4.

10. A readable storage medium, characterized in that, The readable storage medium stores machine-executable instructions that, when invoked and executed by a processor, cause the processor to implement the method described in any one of claims 1-4.

Images