Virtual machine based server virtualization system

Abstract

The application relates to the technical field of computer virtualization and cloud computing, in particular to a server virtualization system based on a virtual machine, which comprises a bottom-layer virtual machine manager, a state monitoring module, a jitter quantification module and a decision scheduling module; the state monitoring module collects hardware performance counter data, current physical resource utilization and virtual machine resource request data, and analyzes kernel-level running state data; the jitter quantification module extracts central processing unit context switching frequency, translation lookaside buffer failure times and last-level cache contention indexes, and generates scheduling jitter entropy values; the decision scheduling module compares the scheduling jitter entropy values with a preset dangerous threshold value, executes a dynamic resource allocation scheme based on a deep reinforcement learning model below the threshold value, and executes a static locking degradation scheme when the threshold value reaches or exceeds the threshold value, so that the instability risk of a virtual machine monitor can be actively inhibited.

Description

Technical Field

[0001] This invention relates to the fields of computer virtualization and cloud computing technology, specifically to a server virtualization system based on virtual machines. Background Technology

[0002] In the daily operation of cloud data centers, the host machine usually needs to simultaneously host virtual machines of multiple business types, and use server virtualization technology to uniformly schedule computing and memory resources to improve the utilization of physical resources and the flexibility of business deployment. The operational stability of the virtualization system directly depends on the reliability of the underlying resource scheduling process. Especially in scenarios with high resource over-allocation, high concurrency, and mixed deployment of multiple services, once the fluctuation of the underlying scheduling state exceeds the preset range, it will increase the probability that the continuous operation of critical virtual machines will be restricted.

[0003] In traditional approaches, server virtualization systems mostly allocate resources dynamically based on virtual machine resource requests and current physical resource utilization. They typically focus on improving resource pooling efficiency and overall throughput. However, they lack sufficient awareness of hardware disturbances, cache contention, page table refresh anomalies, and scheduling jitter risks during the underlying scheduling process. When the host machine is under high load or experiences sudden interference, virtual machine migration, time slice adjustments, and memory reallocation operations may still continue, leading to increased underlying scheduling overhead and failure to meet the preset guarantee standards for virtual machine resource stability. Summary of the Invention

[0004] The purpose of this invention is to provide a virtual machine-based server virtualization system that addresses the following technical problems: Existing server virtualization technologies have technical deficiencies in their ability to perceive hardware disturbances, cache contention, page table refresh anomalies, and scheduling jitter risks during the underlying scheduling process, as well as in ensuring the stability of virtual machine resources. This invention aims to provide a virtual machine-based server virtualization system that can explicitly model underlying scheduling stability as a quantifiable object and switch between dynamic optimization and survival degradation accordingly, thereby proactively suppressing the risk of virtual machine monitor instability. This objective can be achieved through the following technical solutions:

[0005] A virtual machine-based server virtualization system, the system comprising:

[0006] The underlying virtual machine manager is used to perform resource allocation and isolation operations;

[0007] The status monitoring module is used to collect hardware performance counter data, current physical resource utilization and virtual machine resource request data at the underlying level of the physical server, and parse the hardware performance counter data to obtain kernel-level running status data.

[0008] The jitter quantization module, connected to the status monitoring module, is used to receive the kernel-level running status data, extract the CPU context switching frequency, the number of transition backup buffer failures and the last-level cache contention index based on the kernel-level running status data, and generate a scheduling jitter entropy value based on the extracted CPU context switching frequency, the number of transition backup buffer failures and the last-level cache contention index.

[0009] The decision scheduling module, connected to the underlying virtual machine manager, compares the scheduling jitter entropy value with a preset danger threshold. If the scheduling jitter entropy value is less than the preset danger threshold, it executes a dynamic resource allocation scheme based on a deep reinforcement learning model. This deep reinforcement learning model uses the virtual machine resource request data and the current physical resource utilization rate as its state space, and CPU time slice reallocation and dynamic memory migration as its action space for optimization processing, and outputs corresponding dynamic allocation instructions to the underlying virtual machine manager. If the scheduling jitter entropy value is greater than or equal to the preset danger threshold, it executes a static locking degradation scheme to output resource scheduling instructions to the underlying virtual machine manager.

[0010] Optionally, the status monitoring module includes:

[0011] The data acquisition unit is used to acquire the hardware performance counter data, the current physical resource utilization rate, and the virtual machine resource request data through a polling method with a preset period.

[0012] The feature extraction unit is used to perform time-series feature analysis on the hardware performance counter data to obtain the hardware-level cache miss rate and memory page table refresh frequency, which are the kernel-level running status data.

[0013] The state generation unit is used to encapsulate the cache miss rate and the memory page table refresh frequency into kernel-level runtime state data, and send them to the jitter quantization module.

[0014] Optionally, the jitter quantization module includes:

[0015] The weight allocation unit is used to allocate corresponding weight coefficients to the central processing unit context switching frequency, the number of failures of the transition backup buffer, and the last-level cache contention index according to preset system architecture parameters.

[0016] The entropy calculation unit is used to perform a weighted summation of the central processing unit context switching frequency, the number of failures of the transition backup buffer, and the last-level cache contention index based on the weighting coefficients to generate the scheduling jitter entropy value.

[0017] The risk prediction unit is used to input the scheduling jitter entropy value into a risk assessment model trained based on historical fault data to predict the probability of a kernel panic in the system, and to use the probability as an additional attribute of the scheduling jitter entropy value.

[0018] Optionally, when executing the dynamic resource allocation scheme based on the deep reinforcement learning model, the decision scheduling module is specifically used for:

[0019] The virtual machine resource request data and the current physical resource utilization rate are input into the deep reinforcement learning model;

[0020] Based on the output action space of the deep reinforcement learning model, CPU time slice reallocation and memory dynamic migration instructions are generated for each virtual machine.

[0021] Optionally, when executing the static locking degradation scheme, the decision scheduling module is specifically used for:

[0022] Freeze all dynamic migration operations for virtual machines;

[0023] It enforces static binding between the virtual CPU and the physical CPU, and implements physical memory isolation by modifying memory page table permissions.

[0024] Optionally, the decision scheduling module further includes:

[0025] The recovery monitoring unit is used to continuously monitor the scheduling jitter entropy value after the static locking degradation scheme is executed;

[0026] The state rollback unit is used to release the static locking degradation scheme and resume the execution of the dynamic resource allocation scheme based on the deep reinforcement learning model when the scheduling jitter entropy value is lower than the preset safety threshold for a continuous monitoring period of time. The preset safety threshold is less than the preset danger threshold.

[0027] Optionally, the status monitoring module further includes:

[0028] An anomaly filtering unit is used to smooth the collected hardware performance counter data to filter out pulse interference data caused by transient hardware noise.

[0029] Compared with the prior art, the present invention has the following beneficial effects:

[0030] 1. To address the weakness of traditional systems in perceiving hardware disturbances, cache contention, and page table refresh anomalies, this invention utilizes a status monitoring module and a jitter quantification module to perform time-series feature analysis on the hardware performance counter data at the physical server's underlying level, obtaining hardware-level cache miss rates and memory page table refresh frequencies. Simultaneously, by combining preset system architecture parameters, it generates a scheduling jitter entropy value by weighted summing of the CPU context switching frequency, the number of transition backstop failures, and the last-level cache contention index, and uses a risk assessment model to predict the probability of kernel panic. This mechanism transforms fragmented hardware counters into quantified kernel-level operational status data and risk indicators, enabling early identification of microarchitectural disturbances and underlying scheduling instability risks.

[0031] 2. To address the issues of increased overhead and low virtual machine stability caused by continuous scheduling operations when the host machine is interfered with in high-concurrency and multi-service mixed deployment scenarios, the decision scheduling module of this invention compares the scheduling jitter entropy value with a preset danger threshold. When the preset danger threshold is reached or exceeded, a static locking degradation scheme is directly triggered. By freezing the dynamic migration operations of all virtual machines, forcibly executing the static binding of virtual central processing units to physical central processing units, and implementing physical memory isolation by modifying memory page table permissions, the system can quickly cut off the continuous deterioration of the scheduling loop, exchanging the limited control plane overhead for the survival and operational stability of the core virtual machines.

[0032] 3. Within a safe range where the scheduling jitter entropy value is less than a preset danger threshold, this system utilizes a dynamic resource allocation scheme based on a deep reinforcement learning model. Using virtual machine resource request data and current physical resource utilization as the state space, it intelligently generates CPU time slice reallocation and memory dynamic migration instructions, thereby maximizing physical resource utilization. Furthermore, through a dual-threshold design of the recovery monitoring unit and the state rollback unit, the system can automatically degrade and smoothly restore dynamic scheduling after remaining in a safe state for a consecutive preset time period. This mechanism avoids repeated jitter switching at threshold critical states and ensures the system's elastic and rapid recovery after anomalies subside.

[0033] 4. To address the issue of transient hardware noise or occasional sampling jitter potentially misleading system decisions during daily operation, this invention introduces an anomaly filtering unit in the status monitoring module to smooth the collected hardware performance counter data. This mechanism can accurately filter out pulse interference data caused by transient hardware noise, preventing the system from misjudging single bursts of high-amplitude data as long-term trends. This avoids unnecessary static locking and elasticity loss, ensuring the reliability of the entire resource scheduling system decision-making chain in environments with high resource over-allocation and mixed multi-service deployment. Attached Figure Description

[0034] Figure 1This is a structural diagram of the system of the present invention. Detailed Implementation

[0035] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to specific embodiments.

[0036] like Figure 1 As shown, a virtual machine-based server virtualization system includes:

[0037] The underlying virtual machine manager is used to perform resource allocation and isolation operations;

[0038] The status monitoring module is used to collect hardware performance counter data, current physical resource utilization and virtual machine resource request data at the physical server level, and parse the hardware performance counter data to obtain kernel-level running status data.

[0039] The jitter quantization module, connected to the status monitoring module, is used to receive kernel-level runtime status data and extract the CPU context switching frequency, transition back buffer failure count, and last-level cache contention index based on the kernel-level runtime status data. It also generates a scheduling jitter entropy value based on the extracted CPU context switching frequency, transition back buffer failure count, and last-level cache contention index.

[0040] The decision-making and scheduling module, connected to the underlying virtual machine manager, compares the scheduling jitter entropy value with a preset danger threshold. If the scheduling jitter entropy value is less than the preset danger threshold, a dynamic resource allocation scheme based on a deep reinforcement learning model is executed. This deep reinforcement learning model uses virtual machine resource request data and current physical resource utilization as its state space, and CPU time slice reallocation and dynamic memory migration as its action space for optimization, outputting corresponding dynamic allocation instructions to the underlying virtual machine manager. If the scheduling jitter entropy value is greater than or equal to the preset danger threshold, a static locking degradation scheme is executed, outputting resource scheduling instructions to the underlying virtual machine manager.

[0041] This embodiment provides a mechanism for a server virtualization system based on virtual machines. Specifically, the system is deployed in a cloud data center host cluster where the resource allocation rate reaches a preset 300% over-allocation threshold. The host machine simultaneously hosts financial-grade database virtual machines and burstable microservice virtual machines. The optimization goal of the system is to prioritize avoiding resource starvation of core virtual machines for 3 consecutive seconds due to underlying scheduling instability, while maintaining the central processing unit and memory utilization rates at preset high thresholds over a long period of time.

[0042] Specifically, the underlying virtual machine manager can be a virtual machine monitor execution layer deployed in the host kernel mode. After receiving resource scheduling instructions from the upper layer, it completes virtual CPU scheduling, memory page mapping adjustment, virtual machine migration freezing or recovery, and physical resource isolation control. The status monitoring module periodically collects three types of data: first, hardware performance counter data, such as context switch count, transition backstop failure count, and last-level cache miss count within the period; second, current physical resource utilization, such as CPU utilization, memory utilization, and the number of remaining pages of non-uniform memory access architecture nodes; and third, virtual machine resource request data, such as the virtual CPU demand, memory increment demand, and migration request intent reported or inferred by each virtual machine in the current period. After parsing the hardware performance counter data, kernel-level running status data is formed, which serves as the basic input for subsequent judgment of whether the virtual machine monitor has entered an unstable range.

[0043] Based on this, the jitter quantization module receives kernel-level runtime status data and extracts the CPU context switching frequency, transition back buffer failure count, and last-level cache contention index. For ease of explanation, assume that a host machine measures 120 and 260 context switches per 10 milliseconds in two consecutive sampling periods, 300 and 900 transition back buffer failures, and 0.25 and 0.72 last-level cache contention indexes, respectively. The system first normalizes the indices of different dimensions. For example, it maps 120 times to 0.30, 260 times to 0.65, 300 times to 0.20, and 900 times to 0.60 based on the upper limit of the historical stable range. It keeps 0.25 and 0.72 as 0.25 and 0.72, respectively.

[0044] The scheduling jitter entropy value is generated based on preset combination rules. One feasible approach is to use a weighted summation method. For example, if the current host architecture is more sensitive to cache contention, the weights of context switching, transition backstop failure, and last-level cache contention can be assigned as 0.3, 0.2, and 0.5 respectively. Then, the scheduling jitter entropy value for the second cycle can be obtained.

[0045] If the preset danger threshold is 0.60, it is determined that the current host machine is close to the edge of scheduling instability.

[0046] The decision-making and scheduling module compares the scheduling jitter entropy value with a preset danger threshold. When the scheduling jitter entropy value is lower than the preset danger threshold, a dynamic resource allocation scheme is entered. At this time, the deep reinforcement learning model receives state space input, and the state space contains at least virtual machine resource request data and current physical resource utilization.

[0047] The deep reinforcement learning model is constructed using a deep deterministic policy gradient algorithm. Its reward function is defined as the difference between the gain value of the host physical resource utilization and the control surface overhead penalty term caused by the execution of scheduling actions. The deep reinforcement learning model constructs an experience replay pool by collecting state matrices, action vectors and corresponding reward values ​​in an offline simulation environment, and uses a gradient descent method based on temporal difference to backpropagate and iteratively update the parameters of the policy network and the evaluation network.

[0048] For example, a host machine has three virtual machines. The first database virtual machine requests to add two virtual CPUs and requires that the memory be kept unchanged. The second microservice virtual machine requests to add 1GB of memory. The batch processing virtual machine V3 is willing to be downgraded. The current physical state is that the CPU utilization is 93% and the memory utilization is 96%. The model outputs actions based on the historical training strategy, such as reducing the CPU time slice of V3 by 15%, adding one high-priority time slice to V1, and migrating the 1GB of memory of V2 from a low-load non-uniform memory access architecture node to make up for it. This action is executed by the underlying virtual machine manager, so as to complete elastic scheduling without triggering virtual machine monitor overload.

[0049] When the scheduling jitter entropy value is greater than or equal to a preset danger threshold, the system stops performing global resource allocation optimization and instead executes a static locking degradation scheme. The technical essence of this scheme is to reduce the control plane overhead and state disturbance of the underlying kernel caused by the scheduling action itself. Specifically, it includes freezing dynamic migration, shrinking the variable scheduling plane, strengthening the fixedness of the mapping between virtual CPUs and physical CPUs, and limiting frequent page table adjustment operations. This can suppress the further expansion of scheduler overhead and prevent the scheduling loop from entering an unstable state due to the continuous amplification of feedback delay.

[0050] As an anomaly-tolerant handling method, if there is a hardware counter reading failure, monitoring delay exceeding the preset window, or missing virtual machine resource request data in a certain sampling period, the system will not directly perform a large-scale dynamic migration based on this. Instead, it will fill in the missing fields with the most recent valid value and mark the period as a confidence decline period. If multiple consecutive confidence decline periods occur, it will directly enter the conservative scheduling mode, limiting the action space to only allowing fine-tuning of the central processing unit time slice and disallowing memory migration. If the preset danger threshold itself is abnormally configured, such as being mistakenly set to 0 or greater than 1, the system will correct it to a legal range at startup, such as limiting it to between 0.3 and 0.9.

[0051] During the core financial accounting settlement period, the primary host machine hosts a database virtual machine and more than twenty microservice virtual machines. After a malicious tenant initiates a cache eviction event with concurrency exceeding the preset threshold, although the overall CPU utilization remains at around 94%, context switching and transition buffer failures begin to rise abnormally. The status monitoring module detects a deterioration in the kernel-level operating status, and the jitter quantization module calculates that the scheduling jitter entropy value rises rapidly from 0.41 to 0.67. Based on this, the decision scheduling module stops the planned hot migration of multiple virtual machines, retaining only the fixed CPU share and exclusive memory page area of ​​the primary database virtual machine, and downgrading the operation of several non-core microservice virtual machines. As a result, the overall resource pooling efficiency temporarily decreases, but the virtual machine monitor maintains a predictable response time, preventing the core accounting virtual machine from being interrupted due to three seconds of resource starvation.

[0052] The purpose of this step is to explicitly model the underlying scheduling stability as a quantifiable object in virtualization scenarios where the over-resolution rate is greater than the preset over-resolution threshold and the resource contention rate is greater than the preset contention threshold, and switch between dynamic optimization and survival degradation accordingly, so as to actively suppress the risk of virtual machine monitor instability.

[0053] In this embodiment, the status monitoring module includes:

[0054] The data acquisition unit is used to acquire hardware performance counter data, current physical resource utilization, and virtual machine resource request data through a polling method at a preset period.

[0055] The feature extraction unit is used to perform time-series feature analysis on hardware performance counter data to obtain hardware-level cache miss rate and memory page table refresh frequency as kernel-level runtime status data.

[0056] The state generation unit is used to encapsulate cache miss rate and memory page table refresh frequency into kernel-level runtime state data for sending to the jitter quantization module.

[0057] This embodiment provides a refined mechanism for the state monitoring module. Specifically, in the previous embodiment, if only the single sampling result is used as the basis for judging the underlying scheduling state, there is a possibility of missing microarchitecture-level resource contention anomalies that have not yet filled the central processing unit but have already destroyed cache locality in the early stage of an attack. Therefore, this embodiment further subdivides the state monitoring process into three actions: data acquisition, time-series feature extraction, and state generation, in order to enhance the early perception capability of microarchitecture disturbances.

[0058] Specifically, the data acquisition unit polls the host machine's underlying counters at a preset period. This preset period can be configured in layers according to the host machine's load level; for example, it is once every 50 milliseconds during normal load and can be switched to once every 10 milliseconds during high-risk periods. The polling objects include not only the number of CPU cycles, the number of context switches, and the number of transition backstop failures, but also the number of cache references, the number of cache misses, the number of page table refresh events, and the changes in resource requests of each virtual machine in the previous period. For ease of explanation, assuming that in three consecutive sampling points t1, t2, and t3, a host machine collects 10,000, 12,000, and 15,000 cache references, and 500, 1,800, and 4,200 cache misses, respectively, the cache miss rates can be calculated to be 5%, 15%, and 28%, respectively. Furthermore, assuming that the number of page table refresh events is 40, 90, and 220, a sequence of progressively increasing page table refresh frequencies can be formed.

[0059] The feature extraction unit does not directly use the original values, but performs time-series feature analysis on them. One feasible approach is to calculate the slope, fluctuation amplitude, and persistence. Specifically, the slope is obtained by linearly fitting the index values ​​within three consecutive sampling windows using the least squares method. The fluctuation amplitude is obtained by calculating the standard deviation of the index values ​​within the three consecutive sampling windows. Persistence is determined by counting the number of windows in which the index value is continuously greater than the historical dynamic mean. When the slope of the current window is detected to be greater than the slope of the previous window, and the difference exceeds a preset slope increase threshold, the corresponding index is determined to be in an accelerating upward state.

[0060] For example, for cache miss rates of 5%, 15%, and 28%, an increase of 10 and 13 percentage points respectively within adjacent periods indicates an accelerating upward trend; for page table refresh frequencies of 40, 90, and 220, a significant increase within a short window can be identified; the system can use a sustained increase within the last three windows as a timing trigger condition; the cache miss rate and memory page table refresh frequency obtained in this way are considered kernel-level runtime state data that better reflect underlying abnormal trends, rather than isolated instantaneous values.

[0061] The state generation unit encapsulates the above timing analysis results into a unified data structure and sends it to the jitter quantization module. In a simplified example, the state object can be constructed as a quadruple, namely <timestamp, cache miss rate, page table refresh frequency, trend marker>. For example, at time t3, <t3, 28%, 220 times / window, accelerating upward> is formed. After receiving the data, the jitter quantization module can process it together with other kernel-state indicators without having to repeat the underlying timing analysis.

[0062] As an exception handling mechanism, if the polling cycle is too short, causing the read overhead to intrude into the normal scheduling of the host machine (e.g., the monitoring thread occupies more than a preset proportion of the central processing unit), the system will automatically lengthen the polling cycle to prioritize the operation of the business and the virtual machine monitor itself. If a certain hardware counter cannot be provided due to differences in the host machine model (e.g., some hardware platforms do not expose complete page table refresh events), the system will use a proxy indicator instead, such as the number of memory mapping updates or page fault frequency. If the continuous sampling results are completely constant, the system will also determine whether the monitoring link has failed to avoid misjudging the collector's abnormality as system stability.

[0063] In the aforementioned financial settlement mainline scenario, the first host machine enters the high-concurrency payment and settlement window at 09:58; the data acquisition unit polls at 10-millisecond intervals and finds that although the increase in the central processing unit requests of the first database virtual machine is less than the preset proportional threshold, the host machine cache miss rate rises rapidly from 4% to 26%, and the page table refresh frequency increases from 35 times per window to 210 times; the feature extraction unit identifies this change as a micro-architectural disturbance caused by abnormal business growth, and the state generation unit packages it and sends it to the subsequent processing; in this way, the system has already obtained the early warning information of scheduling instability before the service quality of the business layer has fallen below the preset normal operation threshold;

[0064] The purpose of this step is to improve the underlying hardware noise from scattered counts to a timing state that can be used for risk assessment, thereby enabling early identification of microarchitecture-level abnormal disturbances and fragmented high-concurrency input / output requests.

[0065] In this embodiment, the jitter quantization module includes:

[0066] The weight allocation unit is used to assign corresponding weight coefficients to the central processing unit context switching frequency, the number of transition back buffer failures and the last-level cache contention index according to the preset system architecture parameters.

[0067] The entropy calculation unit is used to perform a weighted summation of the central processing unit context switching frequency, the number of transition back buffer failures, and the last-level cache contention index based on weight coefficients to generate a scheduling jitter entropy value.

[0068] The risk prediction unit is used to input the scheduling jitter entropy value into a risk assessment model trained based on historical fault data to predict the probability of a kernel panic in the system, and to use the probability as an additional attribute of the scheduling jitter entropy value.

[0069] This embodiment provides a refined mechanism for the jitter quantification module. Specifically, the previous implementation was able to detect underlying anomalies from a time-series perspective. However, if the sensitivity of different host architectures to various hardware disturbances is not distinguished, the same monitoring data may correspond to different risk levels on different servers. Therefore, this embodiment further introduces weight allocation based on architecture parameters and additional prediction of kernel panic probability, so that the scheduling jitter entropy value can not only characterize the current system resource contention and fluctuation level, but also quantify the probability or trend of the system state reaching the underlying scheduler instability trigger condition.

[0070] Specifically, the weight allocation unit sets the weights of each indicator based on the host architecture parameters. These architecture parameters may include the number of CPU cores, whether hyper-threading is enabled, the number of nodes in the non-uniform memory access architecture, the last-level cache capacity, the memory page size configuration, and the virtual machine monitor version characteristics. For example, for a type of host where the last-level cache capacity is less than a preset capacity threshold but the context switching cost is greater than a preset overhead threshold, the weights of the CPU context switching frequency, the number of transition backstop failures, and the last-level cache contention indicator can be set to 0.45, 0.25, and 0.30, respectively. For another type of server with a high number of cores in a non-uniform memory access architecture, if actual tests show that cache contention is more likely to induce scheduling degradation, the weights can be changed to 0.25, 0.20, and 0.55. These settings can be obtained through offline testing before deployment or issued by the operation and maintenance policy table.

[0071] The entropy calculation unit generates the scheduling jitter entropy value based on the weighting coefficients. For ease of explanation, assume that a host machine in the current window has a normalized context switching frequency of 0.70, a transition backstop failure count of 0.50, and a last-level cache contention index of 0.80, with weights set to 0.25, 0.20, and 0.55. Then the scheduling jitter entropy value is... If another host machine uses different weights, even if the three original indicators are the same, the resulting scheduling jitter entropy values ​​will be different, thus reflecting the differences in the vulnerability of different platforms to scheduling jitter.

[0072] Based on this, the risk prediction unit inputs the scheduling jitter entropy value into the risk assessment model trained on historical failure data; the risk assessment model constructs a mapping relationship by performing machine learning training on past host machine crash samples, and its input includes at least the scheduling jitter entropy value, and may also include the slope information of the most recent windows;

[0073] Specifically, the risk assessment model is constructed using a long short-term memory network. The gating mechanism of the long short-term memory network is used to extract dynamic dependency features from the input sequence, and the probability distribution of different risk levels is output through a fully connected layer and a normalized exponential function. The machine learning training uses the cross-entropy loss function to optimize the weights inside the model.

[0074] In a simplified example, historical data shows that when the scheduling jitter entropy value is below 0.45, the probability of a kernel panic is less than 1%; when the scheduling jitter entropy value is between 0.45 and 0.60 and continues to rise for two consecutive windows, the probability is approximately 8%; when the scheduling jitter entropy value is between 0.60 and 0.70, the probability is approximately 15%; when the scheduling jitter entropy value is above 0.70 and has risen for the last three windows, the probability can reach over 35%; when the current scheduling jitter entropy value is 0.715 and continues to rise, the risk prediction unit can output an additional attribute of a 35% probability of a kernel panic. In this way, subsequent scheduling decisions can consider not only the threshold but also the rate of evolution towards an unstable state.

[0075] As an anomaly tolerance mechanism, if the host machine has just been put online and there are insufficient historical fault samples, the risk assessment model can temporarily use rule-based mapping instead. For example, it can give three levels of risk: low, medium, and high, based on segmented thresholds, without affecting the basic operation of the system. If the total weight is not equal to 1 due to a configuration error, the system will automatically perform normalization correction. For example, if the original weights are 3, 2, and 5, they can be converted to 0.3, 0.2, and 0.5. If a certain indicator is missing, the corresponding weight will be redistributed to the other valid indicators proportionally, and the output will be marked as a decrease in the confidence of the current scheduling jitter entropy value, so as to avoid using incomplete data as a basis for high-precision judgment.

[0076] On the aforementioned first host machine, in the three windows following the outbreak of a cache eviction event where concurrency exceeded the preset threshold, the context switching frequency, the number of transition back buffer failures, and the last-level cache contention index rose to 0.62, 0.58, and 0.79, respectively. This host machine belongs to a high-concurrency database node with a multi-non-uniform memory access architecture, and the system increased the last-level cache contention weight to 0.5. The entropy calculation result reached 0.69. The risk prediction unit, combining historical settlement windows and cache contention failure samples, gave a probability of 27% that the system would enter the pre-kernel panic state within the next 3 seconds. Compared to simply outputting an abstract score, this result with probabilistic attributes is more conducive to the rapid execution of conservative strategies by subsequent stages.

[0077] The purpose of this step is to quantify scheduling disturbances on different hardware platforms into comparable and mappable indicators of failure risk, thereby enabling scheduling decisions that are closer to the actual failure boundary.

[0078] In this embodiment, when executing a dynamic resource allocation scheme based on a deep reinforcement learning model, the decision scheduling module is specifically used for:

[0079] Input virtual machine resource request data and current physical resource utilization into the deep reinforcement learning model;

[0080] Based on the output action space of the deep reinforcement learning model, instructions for CPU time slice reallocation and memory dynamic migration for each virtual machine are generated.

[0081] This embodiment provides a dynamic resource allocation execution mechanism. Specifically, the aforementioned implementation has established a jitter risk assessment framework. However, if fixed rules are still used to allocate resources when the entropy value is still within a safe range, there is a high probability that insufficient resource utilization or critical virtual machine response latency will exceed the preset latency threshold in a 300% oversubscription scenario. Therefore, this embodiment uses a deep reinforcement learning model to generate CPU time slice reallocation and memory dynamic migration actions within the safe range to improve overall resource utilization and system business elasticity.

[0082] Specifically, the state space of the model input consists of virtual machine resource request data and the current physical resource utilization rate; for ease of explanation, it is assumed that the first host machine currently hosts four virtual machines: the first database virtual machine requests an increase of 2 units in the central processing unit and keeps the memory unchanged; the transaction gateway virtual machine V2 requests an increase of 1 unit in the central processing unit and an increase of 2GB in the memory; the reporting virtual machine V3 can be downgraded; the log analysis virtual machine V4 requests to migrate to an idle non-uniform memory access architecture node;

[0083] The current physical state of the host machine is: CPU utilization 91%, memory utilization 94%, 1GB remaining on the first non-uniform memory access architecture node, and 4GB remaining on N2. This state can be abstracted as a state vector S = [2, 0, 1, 2, -1, 0, 0, 1, 91, 94, 1, 4]. The first 8 elements of the state vector S correspond to the CPU and memory requests of virtual machines V1 to V4, respectively. Positive values ​​indicate an increase in requests, negative values ​​indicate a reduction in requests, and 0 indicates no change. The last 4 elements of the state vector S correspond to the CPU utilization, memory utilization, and remaining memory of the first non-uniform memory access architecture node and N2, respectively.

[0084] After receiving the state vector S, the model selects an action within a preset action space. For example, each action in the action space consists of a CPU time slice adjustment and a memory migration amount for a virtual machine. This can be simplified as A1 corresponding to adding 1 CPU time slice to V1, A2 corresponding to migrating 2GB of V2 to N2, A3 corresponding to reducing the CPU time slice of V3 by 10%, and A4 corresponding to disabling migration of V4. The model can output a combination of the first action, the second action, and the third action.

[0085] After generating actions, the decision-making and scheduling module converts them into executable instructions. On the CPU side, this can manifest as adjusting the virtual CPU scheduling weight or time slice length; on the memory side, it can manifest as updating the migration queue, selecting the target non-uniform memory access architecture page frame, and limiting the migration rate to prevent a single migration from crowding out control plane resources of the virtual machine monitor beyond the preset limit. In a feasible implementation, CPU time slices are first increased for V1, and then 2GB of memory is migrated to V2 in batches of 256MB each to reduce page table update peaks. Thus, a clear mapping relationship is established between the model output and the underlying executable actions.

[0086] As an exception handling method, if the action output by the model exceeds the current host machine's executable boundary, such as requesting to migrate 4GB of memory but the target node only has 2GB remaining, the decision scheduling module will prune the action, prioritizing the parts most critical to the core virtual machine; if the model gives conflicting actions, such as requiring a virtual machine to migrate in and out at the same time, then deduplication will be performed according to the preset priority rules; if some resource request fields are missing in the state space, then the average value of the most recent stable period will be used to replace them, and the magnitude of the executable actions in this round will be reduced to prevent unexpected large-scale scheduling actions based on incomplete input;

[0087] During the aforementioned settlement window, the query latency of the first database virtual machine increased, but the scheduling jitter entropy value remained at only 0.43, which was within a safe range. The system input the resource requests of V1, V2, V3, and V4 and the real-time host machine water level into the deep reinforcement learning model. The model output was to increase the CPU time slice of V1, migrate the 2GB of memory added to V2 to N2, and reduce the CPU share of V3. After the virtual machine monitor implemented these measures in sequence, the database query latency recovered, while the overall CPU utilization remained around 95%, without triggering premature degradation.

[0088] The purpose of this step is to use a learning strategy to quickly optimize the resource requirements of multiple virtual machines while the underlying system can still bear the overhead of dynamic scheduling, so as to achieve a balance between high utilization and the stability of core process execution.

[0089] In this embodiment, when executing the static locking degradation scheme, the decision scheduling module is specifically used for:

[0090] Freeze all dynamic migration operations for virtual machines;

[0091] It enforces static binding between the virtual CPU and the physical CPU, and implements physical memory isolation by modifying memory page table permissions.

[0092] This embodiment provides a static locking degradation mechanism. Specifically, in the previous embodiment, dynamic resource scheduling can improve the utilization efficiency of the resource pool. However, when the concurrency exceeds the preset threshold for cache eviction events or fragmented high-concurrency input / output requests cause the scheduling jitter entropy value to approach the danger range, continuing to perform frequent virtual machine migration and CPU rebinding operations will exacerbate the control plane overhead of the underlying scheduler, causing the virtual machine monitor to enter a state of frequent state oscillation and continuously amplified scheduling latency, resulting in a continuously unstable system. Therefore, this embodiment quickly reduces the range of control plane changes by freezing migration, static binding, and hard memory isolation when the danger threshold is triggered.

[0093] Specifically, freezing all virtual machine dynamic migration operations means pausing hot migration, pausing automatic non-uniform memory access architecture balancing migration, pausing memory page migration triggered by load prediction, and pausing active relocation of low-priority virtual machines; this can directly cut off the additional overhead caused by frequent page table updates and memory mapping reconstruction; forcing the static binding of virtual CPUs to physical CPUs means specifying a fixed set of physical CPUs for core virtual machines and prohibiting the scheduler from migrating their virtual CPUs outside the set during the demotion period;

[0094] For ease of explanation, assume that the first host machine has 8 physical CPU cores, labeled P1 to P8; the first database virtual machine has 4 virtual CPUs, which can be statically bound to the first to fourth physical CPU cores; the transaction gateway virtual machine V2 has 2 virtual CPUs, bound to physical CPU cores P5 to P6; and the remaining microservice virtual machines share physical CPU cores P7 to P8. Although this layout sacrifices flexibility, it avoids high-frequency context migration.

[0095] Implementing physical memory isolation by modifying memory page table permissions refers to reserving a fixed physical memory region for the core virtual machine during the degradation period and restricting non-core virtual machines from accessing the page frames corresponding to this region. In one possible implementation, the critical data pages of the first database virtual machine are fixed to a physical page region on the first non-unified memory access architecture node. The page table only grants write permissions to the address space where V1 resides, and other virtual machines are either invisible to this page region or have no mapping to it. This can reduce cross-virtual machine cache contention and page frame preemption, ensuring that the core virtual machine still has available memory resources in the worst case.

[0096] As an exception handling method, if the current physical resource contention rate of the host machine exceeds the preset resource contention threshold, making it impossible to provide fully exclusive CPU binding and memory isolation for all virtual machines, then core business virtual machines will be prioritized. For non-core virtual machines, a coarser-grained shared binding can be adopted, such as multiple microservice virtual machines being bound to a small number of physical cores. If a non-core virtual machine is found to have persistently insufficient resources after the migration is frozen, then limited downgrading or rate limiting is allowed for it, rather than lifting the overall downgrade strategy. If page table permission modification fails, then at least the static CPU binding will be completed first, and new migration actions will be prevented from entering the queue to ensure that the downgrade operation has partial effectiveness.

[0097] During the peak of the attack at the settlement window, the scheduling jitter entropy of the first host machine reached 0.71, and the risk prediction results indicated a significant increase in the probability of short-term kernel panic. The system immediately stopped the memory migration of multiple microservice virtual machines that were originally running, fixed the first database virtual machine to P1-P4, and locked its 8GB critical memory page area to the first non-unified memory access architecture node. At this time, the processing speed of some log analysis and reporting services dropped beyond the preset judgment threshold, but the core financial accounting writes no longer experienced resource starvation, and the host machine scheduling latency returned to normal after a few sampling periods.

[0098] The purpose of this step is to achieve survivability protection for core business operations by exchanging limited control surface overhead for stability gains that meet the system's preset requirements when the underlying scheduler is close to the instability boundary.

[0099] In this embodiment, the decision scheduling module further includes:

[0100] The recovery monitoring unit is used to continuously monitor the scheduling jitter entropy value after the static locking degradation scheme is executed;

[0101] The state rollback unit is used to release the static locking degradation scheme and resume the execution of the dynamic resource allocation scheme based on the deep reinforcement learning model when the scheduling jitter entropy value is lower than the preset safety threshold for a continuous monitoring period. The preset safety threshold is less than the preset danger threshold.

[0102] This embodiment provides a recovery and rollback mechanism after degradation. Specifically, if there is only a degradation trigger without a recovery path, although it can protect the system at risk, it will keep the host machine in a low-elasticity and low-efficiency state for a long time. Especially after the attack or the event with the concurrency exceeding the preset threshold has subsided, the resource pooling capability cannot be restored. Therefore, this embodiment constructs a control closed loop of entering degradation, stable observation, and safe exit through a recovery monitoring unit and a state rollback unit.

[0103] Specifically, the recovery monitoring unit continues to collect and calculate the scheduling jitter entropy value after the static lock downgrade scheme is executed, instead of stopping monitoring. To avoid repeated switching at the edge of danger, this embodiment adopts a dual threshold design, that is, the preset danger threshold is higher than the preset safety threshold; for example, the preset danger threshold is set to 0.60 and the preset safety threshold is set to 0.45. The state rollback unit only releases the static lock when the scheduling jitter entropy value is lower than 0.45 for a continuous preset time period. The preset time period can be set according to the type of business carried by the host machine, for example, 30 seconds for financial database nodes and 10 seconds for ordinary elastic computing nodes. This can avoid the scheduling jitter entropy value from decreasing for just one cycle and then resuming dynamic scheduling before the stable duration requirement is met, causing the jitter to rise again and exceed the preset danger threshold.

[0104] For ease of explanation, assume the first host machine enters static lock mode at 09:59:00. Thereafter, the scheduling jitter entropy value is calculated every 5 seconds, resulting in the sequence 0.58, 0.49, 0.43, 0.41, 0.42, 0.44, 0.46. If the preset safety threshold is 0.45 and requires the value to remain below this threshold for 20 consecutive seconds, then the 20-second safety condition is met from the third sampling point (0.43) to the sixth sampling point (0.44). Therefore, the state rollback unit can initiate the recovery process after the sixth sampling point. The recovery process does not release all restrictions at once, but can be implemented in stages: first, the migration freeze of non-core virtual machines is lifted, then low-risk memory migration is restored, and finally, the complete deep reinforcement learning dynamic scheduling is restored. If the scheduling jitter entropy value rises again and reaches the preset danger threshold at any stage of the recovery, the recovery is immediately stopped and the system returns to static lock mode.

[0105] As an anomaly tolerance mechanism, if the scheduling jitter entropy value cannot be reduced below the preset safety threshold after degradation, the system maintains the locked mode and can send host offline suggestions, tenant attack alarms, or service migration requests to the upper-level operation and maintenance system. If the difference between the preset safety threshold configuration and the preset danger threshold is less than the preset safety interval (e.g., the difference is less than the minimum interval), the system automatically expands the interval to prevent frequent jitter switching. If monitoring data is missing during continuous observation, the missing period is not included in the continuous safety duration, and only complete and effective low scheduling jitter entropy value windows participate in the recovery determination.

[0106] In the aforementioned main scenario, the first host machine performed a static lock after the peak of the attack; as the cache eviction events with concurrency exceeding the preset threshold weakened, the scheduling jitter entropy value gradually decreased to below 0.44 within the following 30 seconds, and the recovery monitoring unit confirmed that it had continuously met the security requirements; the state rollback unit first restored the limited CPU elasticity of the report virtual machine V3, then restored the small-batch memory migration of the transaction gateway virtual machine V2, and re-enabled the deep reinforcement learning model; throughout the process, the first database virtual machine was kept fixed until all observations passed, thereby avoiding the reintroduction of severe jitter in the early stage of recovery;

[0107] The purpose of this step is to preserve the system's state recovery capability while protecting the underlying stability, thereby achieving a smooth transition from survival mode to high utilization mode.

[0108] In this embodiment, the status monitoring module further includes:

[0109] The anomaly filtering unit is used to smooth the acquired hardware performance counter data to filter out pulse interference data caused by transient hardware noise.

[0110] This embodiment provides an anomaly filtering mechanism. Specifically, in the aforementioned monitoring and quantification process, if all instantaneous spikes of hardware counters are regarded as real risks, the system may be falsely triggered to degrade under brief hardware noise, occasional sampling jitter, or single input / output load peaks, resulting in unnecessary elasticity loss. Therefore, this embodiment adds an anomaly filtering unit at the front end of the status monitoring link to smooth the hardware performance counter data.

[0111] Specifically, the anomaly filtering unit can use a sliding window smoothing method. For ease of explanation, assume that the number of conversion backup buffer failures in five consecutive sampling windows are 100, 110, 105, 420, and 108, respectively. If the original values ​​are used directly, the fourth window will produce an abnormally high value of 420. However, considering the preceding and following windows, it can be determined that it belongs to a single-pulse interference. In this case, median smoothing or amplitude-limited averaging can be used to replace the fourth window with 110 or correct it to about 108 according to the neighborhood mean, thereby avoiding the increase of scheduling jitter entropy value by single-point noise. The same processing can be done for the cache miss rate sequence of 6%, 7%, 29%, 8%, and 7%, identifying 29% as an isolated spike and suppressing its influence.

[0112] Furthermore, anomaly filtering does not unconditionally smooth all high-amplitude data; one possible implementation is to check for both amplitude anomalies and persistence anomalies simultaneously; only when an indicator deviates from the preceding and following windows by more than a preset proportion and the duration is less than two windows is it determined to be impulse interference; if high values ​​appear consecutively for two or more windows, it is considered a true trend and peak suppression is not performed; for example, in the sequence 7%, 8%, 24%, 26%, 28%, the latter three high values ​​are persistent and should be directly retained for subsequent identification of cache eviction events where the concurrency exceeds a preset threshold;

[0113] As an anomaly tolerance mechanism, if a negative value or the physical upper limit of the indicator appears after smoothing, it will be truncated according to the boundary value; for example, the cache miss rate is limited to between 0% and 100%; if the number of sampling windows is insufficient to support sliding smoothing, for example, the system only obtains two sampling points when it starts up, complex filtering will not be performed for the time being, and the adjacent mean limit strategy will be adopted; if the anomaly filtering unit itself fails, the system can fall back to the original sampling data pass-through mode, while increasing the duration required to trigger the danger threshold and reducing the probability of false judgment.

[0114] During the monitoring of the first host machine, at a certain moment, due to a momentary bus jitter, the collector read that the last-level cache contention index suddenly jumped to 0.88, and then dropped back to 0.33 in the next window. The anomaly filtering unit identified that this spike was not persistent, so it smoothed it to 0.32 before sending it to the jitter quantization module. This prevented the system from mistakenly entering the static lock mode during normal financial settlement. Conversely, when a subsequent attack actually occurred, the last-level cache contention index remained above 0.70 for several consecutive windows, and the anomaly filtering unit maintained the original value, enabling the subsequent stage to respond in a timely manner.

[0115] The purpose of this step is to suppress transient noise from contaminating the decision-making process while ensuring the sensitivity of risk perception, thereby achieving more robust scheduling and switching control.

[0116] While data filtering is a common technique in conventional technologies, the anomaly filtering unit in this system is not simply for noise reduction; rather, it forms a tightly coupled and collaborative relationship with the subsequent deep reinforcement learning model. Deep reinforcement learning models are extremely sensitive to inputs to their state space. If transient impulses at the microarchitecture level, such as a single large-capacity cache miss spike, are not accurately filtered out before being converted into action instructions, the deep reinforcement learning model will frequently output excessively large time slice reallocation or memory migration instructions, leading to serious scheduling failures. This invention smooths the data through the anomaly filtering unit before extracting temporal features, essentially constructing a stable and differentiable Markov decision process state space for the deep reinforcement learning model. This allows the deep reinforcement learning model to converge quickly even under a high load of 300% over-allocation, avoiding model decision oscillations caused by fluctuations in the underlying monitoring data. This synergy between underlying data cleaning and upper-layer AI algorithm decision-making produces stability gains far exceeding those of simple superposition of conventional monitoring and algorithms.

[0117] Unlike existing technologies that simply calculate the weighted fit of resource utilization or predict application response time, the scheduling jitter entropy value proposed in this invention physically represents the degree of disorder in the system kernel scheduling queue, i.e., the uncertainty of the microstate, rather than simply the level of load. Even when the CPU utilization is only 60%, a specific combination of cache contention and translational backstop failure can lead to extremely high scheduling jitter entropy values, triggering a system kernel panic crash. This invention's weight allocation unit, combined with system architecture parameters, fuses multi-dimensional hardware failure data into a one-dimensional entropy value, using this as a pre-emptive quantitative representation to predict kernel instability. This technique of transforming abstract system instability precursors into a concrete, calculable entropy value attribute—the kernel panic probability—represents a deep reconstruction of the underlying architecture and operating mechanism of server virtualization. This allows the system to achieve precise survival protection from the kernel's essence, independent of application-level service level protocols.

[0118] When dealing with extremely high concurrent requests, such as malicious cache eviction events, existing technologies using a single threshold scheduling strategy often fall into a vicious cycle—the scheduling ping-pong effect—where static locking and isolation are implemented upon reaching the threshold, the load drops instantly, dynamic migration resumes immediately, and the load spikes again. This invention creatively designs an asymmetric hysteresis loop logic composed of preset danger and safety thresholds. The state rollback unit in the decision scheduling module only releases the static lock when the scheduling jitter entropy value continuously falls below the preset safety threshold for a preset monitoring period. This technical feature gives the system state transition inertia and memory properties, mathematically breaking the vicious cycle of positive feedback under high pressure. This rigid degradation and flexible recovery closed loop, composed of dual thresholds and a time window, ensures that core business virtual machines not only survive but also smoothly transition back to an elastic scheduling state when facing extremely severe physical machine interference. The system's anti-interference stability exhibited is unmatched by simple conditional judgment logic in existing common knowledge.

[0119] It should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention and are not intended to limit it. Although the present invention has been described in detail with reference to preferred embodiments, those skilled in the art should understand that modifications or equivalent substitutions can be made to the technical solutions of the present invention without departing from the spirit and scope of the technical solutions of the present invention.

Claims

1. A server virtualization system based on virtual machines, characterized in that, The system includes: The underlying virtual machine manager is used to perform resource allocation and isolation operations; The status monitoring module is used to collect hardware performance counter data, current physical resource utilization and virtual machine resource request data at the underlying level of the physical server, and parse the hardware performance counter data to obtain kernel-level running status data. The jitter quantization module, connected to the status monitoring module, is used to receive the kernel-level runtime status data, and extract the CPU context switching frequency, the number of transition backup buffer failures, and the last-level cache contention index based on the kernel-level runtime status data. It also generates a scheduling jitter entropy value based on the extracted CPU context switching frequency, the number of transition backup buffer failures, and the last-level cache contention index. The entropy value is obtained by weighted summation of the CPU context switching frequency, the number of transition backup buffer failures, and the last-level cache contention index. The decision scheduling module, connected to the underlying virtual machine manager, compares the scheduling jitter entropy value with a preset danger threshold. If the scheduling jitter entropy value is less than the preset danger threshold, it executes a dynamic resource allocation scheme based on a deep reinforcement learning model. This deep reinforcement learning model uses the virtual machine resource request data and the current physical resource utilization rate as its state space, and CPU time slice reallocation and dynamic memory migration as its action space for optimization processing, and outputs corresponding dynamic allocation instructions to the underlying virtual machine manager. If the scheduling jitter entropy value is greater than or equal to the preset danger threshold, it executes a static locking degradation scheme to output resource scheduling instructions to the underlying virtual machine manager.

2. The server virtualization system based on virtual machines according to claim 1, characterized in that, The status monitoring module includes: The data acquisition unit is used to acquire the hardware performance counter data, the current physical resource utilization rate, and the virtual machine resource request data through a polling method with a preset period. The feature extraction unit is used to perform time-series feature analysis on the hardware performance counter data to obtain the hardware-level cache miss rate and memory page table refresh frequency, which are the kernel-level running status data. The state generation unit is used to encapsulate the cache miss rate and the memory page table refresh frequency into kernel-level runtime state data, and send them to the jitter quantization module.

3. The server virtualization system based on virtual machines according to claim 2, characterized in that, The jitter quantization module includes: The weight allocation unit is used to allocate corresponding weight coefficients to the central processing unit context switching frequency, the number of failures of the transition backup buffer, and the last-level cache contention index according to preset system architecture parameters. The entropy calculation unit is used to perform a weighted summation of the central processing unit context switching frequency, the number of failures of the transition backup buffer, and the last-level cache contention index based on the weighting coefficients to generate the scheduling jitter entropy value. The risk prediction unit is used to input the scheduling jitter entropy value into a risk assessment model trained based on historical fault data to predict the probability of a kernel panic in the system, and to use the probability as an additional attribute of the scheduling jitter entropy value.

4. The server virtualization system based on virtual machines according to claim 1, characterized in that, When executing the dynamic resource allocation scheme based on the deep reinforcement learning model, the decision scheduling module is specifically used for: The virtual machine resource request data and the current physical resource utilization rate are input into the deep reinforcement learning model; Based on the output action space of the deep reinforcement learning model, CPU time slice reallocation and memory dynamic migration instructions are generated for each virtual machine.

5. The server virtualization system based on virtual machines according to claim 1, characterized in that, When executing the static locking degradation scheme, the decision scheduling module is specifically used for: Freeze all dynamic migration operations for virtual machines; It enforces static binding between the virtual CPU and the physical CPU, and implements physical memory isolation by modifying memory page table permissions.

6. The server virtualization system based on virtual machines according to claim 1, characterized in that, The decision-making and scheduling module also includes: The recovery monitoring unit is used to continuously monitor the scheduling jitter entropy value after the static locking degradation scheme is executed; The state rollback unit is used to release the static locking degradation scheme and resume the execution of the dynamic resource allocation scheme based on the deep reinforcement learning model when the scheduling jitter entropy value is lower than the preset safety threshold for a continuous monitoring period of time. The preset safety threshold is less than the preset danger threshold.

7. The server virtualization system based on virtual machines according to claim 1, characterized in that, The status monitoring module also includes: An anomaly filtering unit is used to smooth the collected hardware performance counter data to filter out pulse interference data caused by transient hardware noise.

Images