A method and system for attributing resource usage of a virtual machine across hosts and guests

CN122431801BActive Publication Date: 2026-08-21KYLIN CORP
View PDF 2 Cites 0 Cited by

Patent Information

Application Number
CN202610903359.2
Authority / Receiving Office
CN · China
Patent Type
Patents(China)
Current Assignee / Owner
Filing Date
2026-06-23
Publication Date
2026-08-21
Estimated Expiration
2046-06-23

AI Technical Summary

Technical Problem

[0006]宿主系统侧仅能统计虚拟机管理进程及相关线程的资源消耗,无法感知客户机内部各处理单元的真实负载情况

Benefits of technology

[0061] 1. A method for attributing resource consumption across host and client systems;

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN122431801B_ABST
    Figure CN122431801B_ABST
Patent Text Reader

Abstract

The present application relates to a kind of virtual machine cross-host and the resource occupation attribution method and system of guest machine, it belongs to computer virtualization field, method includes collecting the resource consumption data of virtual machine management process, virtual CPU thread and virtual I / O processing thread in host system;Collect the resource usage data of each virtual CPU and functional module inside guest machine system;Based on two-way time calibration mechanism, the time stamp of double-system acquisition data is aligned, the linear mapping relationship of host system time and guest machine system time is established;According to the preset cross-system mapping relationship, the resource consumption data of host side is distributed to the corresponding virtual CPU or functional module of guest machine system, and resource attribution result is generated.The present application solves the technical problems of resource statistics fragmentation, lack of cross-system correlation, time dimension misalignment and inability to support submodule fine attribution in virtualization scenario, realizes accurate resource monitoring and attribution analysis to virtual machine and its internal functional unit.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] This invention relates to the field of computer virtualization, and in particular to a method and system for attributing resource usage of virtual machines across hosts and clients. Background Technology

[0002] With the application of virtualization technology in mobile terminals and embedded systems, operating systems are increasingly adopting virtual machines to host functional modules with high security or high isolation requirements. In such systems, the host operating system creates and runs one or more virtual machine instances through a virtualization hypervisor, and the virtual machines run independent guest operating systems and their applications or services.

[0003] In existing technologies, system resource monitoring is typically based on a single operating system environment, obtaining information on CPU, memory, and I / O usage by collecting statistics from the operating system kernel or process levels. However, in virtualization scenarios, actual resource consumption is distributed across both the host and guest systems, making it difficult for traditional resource monitoring methods to accurately reflect the true resource usage of the virtual machine as a whole or its internal modules.

[0004] The existing technology has the following drawbacks:

[0005] 1. Fragmented resource statistics

[0006] The host system can only count the resource consumption of the virtual machine management process and related threads, and cannot perceive the actual load of each processing unit inside the guest machine.

[0007] 2. Lack of cross-system correlation mechanisms

[0008] Resource statistics in the client system cannot establish an effective mapping relationship with virtual machine threads or I / O processing units in the host system, making it difficult to attribute the statistical results.

[0009] 3. Time dimension cannot be aligned

[0010] The host system and the client system each maintain their own time base, and existing technologies cannot guarantee the consistency of data collected by different systems in the time dimension.

[0011] 4. Unable to support refined attribution

[0012] Existing methods cannot further attribute resource consumption to specific sub-modules or functional units within the virtual machine, which is not conducive to system scheduling, performance optimization, and energy consumption control.

[0013] Therefore, there is an urgent need for a method to attribute virtual machine resource usage across hosts and guests in order to improve the accuracy and availability of resource monitoring in virtualization systems. Summary of the Invention

[0014] To improve the accuracy and availability of resource monitoring in virtualization systems, this invention provides a method and system for attributing virtual machine resource usage across hosts and clients.

[0015] In a first aspect of the invention, a method for attributing virtual machine resource consumption across host and guest environments is provided. The method includes:

[0016] Step S1: Collect resource consumption data of virtual machine management processes, virtual CPU threads and virtual I / O processing threads related to virtual machine operation in the host system. The resource consumption data includes CPU consumption, memory consumption and I / O consumption.

[0017] Step S2: Collect resource usage data of each virtual CPU and functional module inside the client system. The resource usage data includes the running status of the virtual CPU and the resource occupancy of each functional module.

[0018] Step S3: Based on the bidirectional time calibration mechanism, the resource consumption data collected in the host system and the resource usage data collected in the client system are timestamped to establish a mapping relationship between the host system time and the client system time.

[0019] Step S4: Based on the preset cross-system mapping relationship and the mapping relationship in step S3, allocate the resource consumption data in the host system to the corresponding virtual CPU or functional module in the client system, and generate resource attribution results.

[0020] Step S5: Output the attribution results of CPU, memory, and I / O resources for the entire virtual machine or a specified sub-module.

[0021] Optionally, the bidirectional time calibration mechanism in step S3 includes:

[0022] The host system and the client system periodically exchange timestamps, which include the host system sending timestamp, the client system receiving timestamp, the client system sending timestamp, and the host system receiving timestamp.

[0023] The time offset and communication delay between the host system and the client system are calculated based on the timestamp, and the calculation results are obtained.

[0024] Based on the calculation results, a linear mapping function model between host system time and client system time is established.

[0025] A preset strategy is used to control time alignment errors.

[0026] Optionally, the linear mapping function model is:

[0027] Client system time = a Host system time + b;

[0028] Where a represents the clock frequency offset coefficient between the host system and the client system, and b represents the time offset between the host system and the client system.

[0029] Optionally, the preset strategy includes:

[0030] Remove abnormal delayed sampling points;

[0031] Smooth data using a sliding window;

[0032] Exponentially weighted average filtering algorithm.

[0033] Optionally, the preset cross-system mapping relationship in step S4 includes:

[0034] Establish a correspondence between the virtual machine management process identifier in the host system and the virtual machine instance identifier in the guest system;

[0035] Establish a mapping relationship between the threads used to execute virtual CPUs in the host system and the corresponding virtual CPUs in the guest system;

[0036] This establishes the association between virtual I / O processing threads in the host system and corresponding functional modules in the client system.

[0037] Optionally, the preset cross-system mapping relationship is dynamically maintained in the following ways;

[0038] Periodic verification mechanism;

[0039] Heartbeat-based survival detection;

[0040] Mapping cleanup after abnormal exit;

[0041] Automatic registration of new resource objects.

[0042] Optionally, the allocation of resource consumption data from the host system to the corresponding virtual CPU or functional module in the client system in step S4 includes:

[0043] Divide the time-aligned resource data into multiple consecutive time windows;

[0044] Within each time window, resource consumption data in the host system and resource usage data in the client system are collected separately.

[0045] Based on the preset cross-system mapping relationship, the resource consumption data in the host system is allocated to the corresponding virtual CPU or functional module in the client system;

[0046] The contribution of the client system to the host system is calculated based on preset weighting rules;

[0047] Based on the resource occupancy contribution, resource attribution results are generated for the virtual machine as a whole or its internal sub-modules.

[0048] Optionally, the preset weighting rules include:

[0049]

[0050] in, Indicates the weight based on virtual CPU runtime. This indicates a weight based on I / O resource consumption. This represents the weight based on scheduling priority, where α, β, and γ are weight coefficients, and α+β+γ=1.

[0051] Optionally, exception handling mechanisms may also be included:

[0052] When mapping relationships are missing, amortization or historical mapping is used;

[0053] When data is missing, use the difference or previous value to preserve it;

[0054] Abnormally high data spikes are subject to amplitude limiting.

[0055] In a second aspect of the invention, a virtual machine resource consumption attribution system across host and guest environments is provided. The system includes:

[0056] The host resource acquisition module is used to collect resource consumption data of virtual machine management processes, virtual CPU threads, and virtual I / O processing threads related to the operation of virtual machines in the host system. The resource consumption data includes CPU consumption, memory consumption, and I / O consumption.

[0057] The client resource acquisition module is used to collect resource usage data of each virtual CPU and functional module inside the client system. The resource usage data includes the running status of the virtual CPU and the resource occupancy of each functional module.

[0058] The time alignment module is used to align the timestamps of resource consumption data collected in the host system and resource usage data collected in the client system based on a two-way time calibration mechanism, and to establish a mapping relationship between the host system time and the client system time.

[0059] The resource attribution module is used to allocate resource consumption data in the host system to the corresponding virtual CPUs or functional modules in the guest system according to the preset cross-system mapping relationship and the mapping relationship in the time alignment module, calculate the occupancy contribution, and output the resource attribution results of the virtual machine as a whole and its sub-modules.

[0060] In summary, the present invention has at least one of the following beneficial technical effects:

[0061] 1. A method for attributing resource consumption across host and client systems;

[0062] 2. A mechanism for simultaneously collecting resource data from both the host and client systems;

[0063] 3. A time-aligned method for cross-system resource association;

[0064] 4. Attribution model that maps host-side resource consumption to sub-modules within the virtual machine;

[0065] 5. Supports detailed resource statistics for the virtual machine as a whole and its internal functional units. Attached Figure Description

[0066] Figure 1 This is a schematic diagram of the architecture of a virtual machine resource usage attribution system across hosts and clients according to an embodiment of this application.

[0067] Figure 2 This is a flowchart illustrating a method for attributing virtual machine resource usage across hosts and guests according to an embodiment of this application.

[0068] Figure 3 This is a schematic diagram illustrating the resource mapping and attribution relationship between the host system and the client system in an embodiment of this application. Detailed Implementation

[0069] The present invention will be further described in detail below with reference to the accompanying drawings.

[0070] This specific embodiment is merely an explanation of the present invention and is not intended to limit the invention. After reading this specification, those skilled in the art can make modifications to this embodiment without contributing any inventive step, but such modifications are protected by patent law as long as they fall within the scope of the claims of the present invention.

[0071] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0072] The embodiments of the present invention will now be described in further detail with reference to the accompanying drawings.

[0073] like Figure 1 As shown, a virtual machine cross-host and guest resource occupancy attribution system includes a host resource acquisition module, a guest and resource acquisition module, a time alignment module, and a resource attribution module, wherein:

[0074] The host resource acquisition module is deployed in the host operating system and is used to collect resource consumption data of virtual machine management processes, virtual CPU threads and virtual I / O processing threads related to virtual machine operation in the host system. The resource consumption data includes CPU consumption, memory consumption and I / O consumption.

[0075] The client resource acquisition module is deployed in the client operating system and is used to collect resource usage data of each virtual CPU and functional module inside the client system. The resource usage data includes the running status of the virtual CPU and the resource occupancy of each functional module.

[0076] The time alignment module is used to align the timestamps of resource consumption data collected in the host system and resource usage data collected in the client system based on a two-way time calibration mechanism, and to establish a mapping relationship between the host system time and the client system time.

[0077] The resource attribution module is used to allocate resource consumption data in the host system to the corresponding virtual CPUs or functional modules in the guest system according to the preset cross-system mapping relationship and the mapping relationship in the time alignment module, calculate the occupancy contribution, and output the resource attribution results of the virtual machine as a whole and its sub-modules.

[0078] like Figure 2 As shown, a method for attributing virtual machine resource consumption across hosts and guests is as follows:

[0079] Step S1: Collect resource consumption data of virtual machine management processes, virtual CPU threads, and virtual I / O processing threads related to virtual machine operation in the host system (this step corresponds to the appendix). Figure 2 (Host-side resource collection).

[0080] Specifically, the host resource acquisition module collects resource consumption data of virtual machine management processes, virtual CPU threads, and virtual I / O processing threads related to virtual machine operation in the host system. The resource consumption data includes CPU consumption, memory consumption, and I / O consumption.

[0081] Step S2: Collect resource usage data for each virtual CPU and functional module within the client system (this step corresponds to the attached document). Figure 2 (Client-side resource collection).

[0082] Specifically, the client resource acquisition module collects resource usage data of each virtual CPU and functional module within the client system. The resource usage data includes the running status of the virtual CPU and the resource occupancy of each functional module.

[0083] Step S3: Based on the bidirectional time calibration mechanism, align the timestamps of the resource consumption data collected in the host system and the resource usage data collected in the client system to establish a mapping relationship between the host system time and the client system time (this step corresponds to the appendix). Figure 2 (Time synchronization and alignment in the middle).

[0084] Specifically, the time alignment module employs a two-way time calibration mechanism to timestamp-align the resource consumption data collected in step S1 with the resource usage data collected in step S2. This two-way time calibration mechanism includes:

[0085] First, timestamps are periodically exchanged between the host system and the client system. The timestamps include the host system sending timestamp T1, the client system receiving timestamp T2, the client system sending timestamp T3, and the host system receiving timestamp T4.

[0086] Subsequently, the round-trip latency between the host system and the client system is calculated based on the above four timestamps:

[0087] Communication round-trip delay = (T4-T1) - (T3-T2).

[0088] Where (T4-T1) represents the total time from when the host system sends a request to when the client system responds, and (T3-T2) represents the time consumed by the client system to process the request internally. Therefore, the round-trip delay represents the round-trip transmission delay generated by the actual communication link between the host system and the client system.

[0089] Calculate the time offset between the host system and the client system based on the above four timestamps:

[0090] Time offset = ((T2-T1)-(T3-T4)) / 2.

[0091] The time offset is used to reflect the fixed time difference between the host system time and the client system time at a certain moment.

[0092] For example, if the current time of the host system is 10:00:00 and the current time of the client system is 10:00:05, it means that the client system time is 5 seconds ahead of the host system time, and the time offset is 5 seconds.

[0093] To achieve long-term stable time alignment, the system periodically collects multiple sets of time synchronization samples and establishes a linear mapping model between the host system time and the client system time.

[0094] The linear mapping function model is: Client system time = a Host system time + b.

[0095] Where a represents the clock frequency offset coefficient between the host system and the client system, and b represents the time offset between the host system and the client system.

[0096] b is the time offset calculated through the above two-way time synchronization process, and a is obtained by fitting multiple time synchronization samples.

[0097] Specifically, the system calculates the corresponding time offset at multiple times and obtains multiple sets of samples showing the correspondence between the host system time and the client system time:

[0098] (Host system time 1, Client system time 1);

[0099] (Host system time 2, Client system time 2);

[0100] ...

[0101] (Host system time n, Client system time);

[0102] Then, the least squares fitting method is used to establish a linear mapping model, thereby obtaining parameters a and b.

[0103] Parameter 'a' is used to describe the difference in operating speed between the host system clock and the guest system clock.

[0104] In an ideal situation:

[0105] The host system waited for 1 second;

[0106] The client system also waited for 1 second;

[0107] Then a = 1.

[0108] However, in a virtualized environment, the following factors affect the process:

[0109] (1) Virtual machine scheduling is paused;

[0110] (2) The vCPU is preempted by the host system;

[0111] (3) The client system time is derived from the virtual clock rather than the physical clock;

[0112] (4) The timestamp counter (TSC) exhibits frequency drift;

[0113] (5) Client system time progression is affected by KVM, Hypervisor, or scheduling mechanisms;

[0114] This can cause a difference in the progression rate between the client system time and the host system time.

[0115] For example:

[0116] The host system waited 10 seconds;

[0117] The client system completed the task in just 9.8 seconds;

[0118] Therefore, a = 9.8 / 10 = 0.98.

[0119] This indicates that the client system clock is running slower than the host system clock.

[0120] therefore:

[0121] Round-trip delay is used to eliminate measurement errors caused by message transmission time.

[0122] The time offset b is used to describe the fixed difference between the current time bases of the two systems;

[0123] The frequency offset coefficient 'a' is used to describe the long-term drift relationship between the clock operating rates of the two systems.

[0124] By establishing a mapping relationship between the host system time and the client system time using parameters a and b, precise alignment of cross-system resource collection data on a unified time axis can be achieved.

[0125] Finally, to further reduce time synchronization errors, a preset strategy is adopted for error control, which includes:

[0126] Eliminate communication delay anomalies;

[0127] Use a sliding window for data smoothing;

[0128] An exponentially weighted average filtering algorithm is used to reduce the impact of jitter.

[0129] in:

[0130] Communication delay anomalies are sampling points where the round-trip delay is significantly higher than the normal statistical range;

[0131] A sliding window is used to smooth short-period time fluctuations;

[0132] Exponentially weighted average filtering is used to suppress the impact of instantaneous communication jitter on time synchronization results, thereby improving the stability and accuracy of the time mapping model.

[0133] Step S4: Based on the preset cross-system mapping relationship and the mapping relationship in Step S3, allocate the resource consumption data of the host system to the corresponding virtual CPU or functional module in the client system, and generate resource attribution results (this step corresponds to the appendix). Figure 2 (from "Mapping and Resource Attribution" in Chinese).

[0134] Specifically, the resource attribution module allocates the resource consumption data in the host system to the corresponding virtual CPU or functional module in the client system based on the data after aligning the host system time with the client system time in the preset cross-system mapping relationship step S3.

[0135] First, the data after aligning the host system time with the client system time is divided into multiple consecutive time windows (e.g., each time window is 100ms). Within each time window, the resource consumption data of the host system and the resource usage data of the client system are counted separately.

[0136] Then, based on the preset cross-system mapping relationship, the resource consumption data in the host system is allocated to the corresponding virtual CPU or functional module in the guest system; the resource consumption contribution of the guest system in the host system is calculated based on the preset weight rules; and the resource attribution results of the virtual machine as a whole or its internal sub-modules are generated based on the resource consumption contribution.

[0137] The preset cross-system mapping relationships include:

[0138] Establish a correspondence between the virtual machine management process identifier in the host system and the virtual machine instance identifier in the guest system;

[0139] Establish a mapping relationship between the threads used to execute virtual CPUs in the host system and the corresponding virtual CPUs in the guest system;

[0140] This establishes the association between virtual I / O processing threads in the host system and corresponding functional modules in the client system.

[0141] It is important to know that the preset cross-system mapping relationships are dynamically maintained in the following ways;

[0142] Periodic verification mechanism: The system performs consistency verification on the mapping relationship between the host system and the client system according to a preset time period, specifically including:

[0143] 1) Verify whether the virtual CPU thread in the host system is still associated with the corresponding virtual CPU in the guest system;

[0144] 2) Verify whether the virtual I / O processing thread still corresponds to the target functional module;

[0145] 3) Verify whether the virtual machine instance identifier, thread identifier, and resource object identifier have changed;

[0146] 4) Verify whether the resource objects corresponding to the recorded mapping relationships are still in the running state.

[0147] When a mapping relationship fails, a thread is rebuilt, a resource object is migrated, or its identifier changes, the corresponding mapping relationship is re-established.

[0148] Periodic verification mechanisms can help avoid attribution errors caused by thread rebuilding, virtual machine migration, or changes in resource objects.

[0149] Heartbeat-based liveness detection: The host system and the client system periodically exchange heartbeat information to detect whether the mapped object remains alive, specifically including:

[0150] 1) The host system periodically sends status check requests to the client system;

[0151] 2) The client system returns the current status information of the virtual CPU, functional module, or resource object;

[0152] 3) If no response is received within the preset time, the corresponding resource object is determined to be inactive or communication is abnormal.

[0153] Furthermore:

[0154] 1) When it is detected that the virtual CPU has stopped running;

[0155] 2) The functional module exited abnormally;

[0156] 3) Virtual I / O thread becomes inactive;

[0157] 4) The virtual machine hangs abnormally;

[0158] The corresponding mapping relationship will then be marked as invalid, and resource attribution calculations based on that mapping relationship will be stopped.

[0159] By using heartbeat-based liveness detection, the real-time performance and reliability of cross-system resource mapping relationships can be improved.

[0160] Mapping cleanup after abnormal exit: When an abnormal exit of a virtual machine, virtual CPU thread, virtual I / O thread, or functional module is detected, the corresponding mapping relationship is automatically cleaned up, specifically including:

[0161] 1) Delete the mapping table entry corresponding to the invalid resource object;

[0162] 2) Clear the resource statistics cache corresponding to the failed thread;

[0163] 3) Terminate the resource attribution task based on failure mapping;

[0164] 4) Prevent exited objects from continuing to participate in subsequent resource attribution calculations.

[0165] Abnormal exits include:

[0166] 1) Virtual machine crash;

[0167] 2) The thread terminates abnormally;

[0168] 3) Process exit;

[0169] 4) The virtio connection is lost;

[0170] 5) The host system restarts;

[0171] 6) Suspension recovery failed.

[0172] By cleaning up the mappings after an abnormal exit, errors in resource attribution results can be avoided due to historically invalid mapping relationships.

[0173] Automatic registration of new resource objects: When a new resource object is created in the host system or client system, a new cross-system mapping relationship is automatically established, specifically including:

[0174] 1) When a new virtual CPU thread is created, the corresponding virtual CPU mapping relationship is automatically registered;

[0175] 2) When a new virtual I / O thread is created, the association between it and the target functional module is automatically established;

[0176] 3) When a new functional module is loaded into the client system, it is automatically added to the resource attribution management scope;

[0177] 3) When a new virtual machine instance starts, it automatically initializes the mapping table between the host system and the guest system.

[0178] Furthermore:

[0179] The system automatically updates the mapping relationship by listening to thread creation events, virtual machine lifecycle events, or resource object registration events.

[0180] Automatic registration of new resource objects can improve the adaptability of resource attribution systems to dynamic virtualization environments.

[0181] The preset weighting rules include:

[0182] In the resource attribution process, a weighting coefficient is introduced, and its calculation formula is as follows:

[0183] ;

[0184] in, This represents the overall resource usage contribution weight corresponding to the j-th client resource object within the i-th time window. Indicates the weight based on virtual CPU runtime. This indicates a weight based on I / O resource consumption. This represents the weight based on scheduling priority, where α, β, and γ are weight coefficients, and α+β+γ=1.

[0185] In the attribution process, abnormal situations are handled as follows:

[0186] When mapping relationships are missing, amortized or historical mapping is used: When the cross-system mapping relationship between the host system and the guest system is missing, that is, when the correspondence between host-side resource objects (such as virtual CPU threads, I / O processing threads) and guest-side resource objects (such as virtual CPUs or functional modules) cannot be determined, the following processing method is adopted:

[0187] 1) Amortization method: The host system resource consumption that cannot be mapped at present is evenly distributed among all existing valid client resource objects according to a preset ratio to avoid loss of resource statistics;

[0188] 2) Historical mapping backtracking method: Based on the stable mapping relationship that exists in the historical time window, backtracking and matching are performed on the currently missing mapping relationship, and the most recent valid mapping relationship is selected as the alternative mapping basis.

[0189] The above methods can ensure the continuity and consistency of resource attribution results during the temporary failure or reconstruction of mapping relationships.

[0190] When data is missing, the following compensation mechanism is used: When resource acquisition data is missing within a certain time window, such as when the host system or guest system fails to successfully acquire CPU, I / O, or scheduling-related data, the following compensation mechanism is used:

[0191] 1) Difference compensation method: Based on the trend of resource data changes within adjacent time windows, linear interpolation or trend extrapolation is performed on the data in the missing time window to restore the continuous time series;

[0192] 2) Previous value preservation method: When the system resources change relatively smoothly or the short-term fluctuations are small, the resource data of the previous effective time window is directly used as the replacement value of the current missing window.

[0193] The above methods can effectively avoid resource attribution breaks or statistical biases caused by short-term data loss.

[0194] Abnormal surges in data are subject to limiting: When an abnormal surge in resource consumption is detected within a certain time window, i.e., when the resource value changes abnormally and drastically compared to historical statistical levels, a limiting mechanism is used to constrain it.

[0195] 1) First, calculate the average and fluctuation range of resource consumption based on historical sliding windows;

[0196] 2) When the current sampled value exceeds the preset upper limit threshold, it is truncated to the maximum value within the allowed range;

[0197] 3) When the current sampled value is lower than the preset lower limit threshold, correct it to the minimum reasonable value range;

[0198] The threshold can be dynamically determined based on the historical mean and standard deviation, for example, set as the mean plus or minus a certain number of standard deviations.

[0199] By using amplitude limiting processing, resource statistics distortion caused by system jitter, instantaneous load spikes, or sampling anomalies can be effectively suppressed, thereby improving the stability and robustness of attribution results.

[0200] Step S5: Output the CPU, memory, and I / O resource attribution results for the entire virtual machine or a specified sub-module (this step corresponds to the appendix). Figure 2 (See "Results Output" in the middle).

[0201] The above description is merely a preferred embodiment of the present invention and an explanation of the technical principles employed. Those skilled in the art should understand that the scope of disclosure in this invention is not limited to technical solutions formed by specific combinations of the above-described technical features, but should also cover other technical solutions formed by arbitrary combinations of the above-described technical features or their equivalents without departing from the foregoing disclosed concept. For example, technical solutions formed by substituting the above features with (but not limited to) technical features with similar functions disclosed in this invention.

Claims

1. A method for attributing virtual machine resource consumption across host and guest environments, characterized in that, include: Step S1: Collect resource consumption data of virtual machine management processes, virtual CPU threads and virtual I / O processing threads related to virtual machine operation in the host system. The resource consumption data includes CPU consumption, memory consumption and I / O consumption. Step S2: Collect resource usage data of each virtual CPU and functional module inside the client system. The resource usage data includes the running status of the virtual CPU and the resource occupancy of each functional module. Step S3: Based on the bidirectional time calibration mechanism, the resource consumption data collected in the host system and the resource usage data collected in the client system are timestamped to establish a mapping relationship between the host system time and the client system time. Step S4: Based on the preset cross-system mapping relationship and the mapping relationship in step S3, allocate the resource consumption data in the host system to the corresponding virtual CPU or functional module in the client system, and generate resource attribution results; Step S5: Output the attribution results of CPU, memory, and I / O resources for the entire virtual machine or a specified sub-module.

2. The method for attributing virtual machine resource consumption across hosts and guests according to claim 1, characterized in that, The bidirectional time calibration mechanism in step S3 includes: The host system and the client system periodically exchange timestamps, which include the host system sending timestamp, the client system receiving timestamp, the client system sending timestamp, and the host system receiving timestamp. The time offset and communication delay between the host system and the client system are calculated based on the timestamp, and the calculation results are obtained. Based on the calculation results, a linear mapping function model between host system time and client system time is established. A preset strategy is used to control time alignment errors.

3. The method for attributing virtual machine resource consumption across hosts and guests according to claim 2, characterized in that, The linear mapping function model is as follows: Client system time = a Host system time + b; Where a represents the clock frequency offset coefficient between the host system and the client system, and b represents the time offset between the host system and the client system.

4. The method for attributing virtual machine resource consumption across hosts and guests according to claim 2, characterized in that, The preset strategy includes: Remove abnormal delayed sampling points; Smooth data using a sliding window; Exponentially weighted average filtering algorithm.

5. The method for attributing virtual machine resource consumption across hosts and guests according to claim 1, characterized in that, The preset cross-system mapping relationship in step S4 includes: Establish a correspondence between the virtual machine management process identifier in the host system and the virtual machine instance identifier in the guest system; Establish a mapping relationship between the threads used to execute virtual CPUs in the host system and the corresponding virtual CPUs in the guest system; This establishes the association between virtual I / O processing threads in the host system and corresponding functional modules in the client system.

6. The method for attributing virtual machine resource consumption across hosts and guests according to claim 5, characterized in that, The preset cross-system mapping relationship is dynamically maintained in the following ways; Periodic verification mechanism; Heartbeat-based survival detection; Mapping cleanup after abnormal exit; Automatic registration of new resource objects.

7. The method for attributing virtual machine resource consumption across hosts and guests according to claim 1, characterized in that, The step S4, which involves allocating resource consumption data from the host system to the corresponding virtual CPU or functional module in the client system, includes: Divide the time-aligned resource data into multiple consecutive time windows; Within each time window, resource consumption data in the host system and resource usage data in the client system are collected separately. Based on the preset cross-system mapping relationship, the resource consumption data in the host system is allocated to the corresponding virtual CPU or functional module in the client system; The contribution of the client system to the host system is calculated based on preset weighting rules; Based on the resource occupancy contribution, resource attribution results are generated for the virtual machine as a whole or its internal sub-modules.

8. The method for attributing virtual machine resource consumption across hosts and guests according to claim 7, characterized in that, The preset weighting rules include: , in, Indicates the weights based on virtual CPU runtime. This indicates the weight based on I / O resource consumption. This represents the weight based on scheduling priority, where α, β, and γ are weight coefficients, and α+β+γ=1.

9. A method for attributing virtual machine resource consumption across hosts and guests according to claim 1, characterized in that, It also includes an exception handling mechanism: When mapping relationships are missing, amortization or historical mapping is used; When data is missing, use the difference or previous value to preserve it; Abnormally high data spikes are subject to amplitude limiting.

10. A virtual machine resource consumption attribution system across host and guest environments, characterized in that, include: The host resource acquisition module is used to collect resource consumption data of virtual machine management processes, virtual CPU threads, and virtual I / O processing threads related to the operation of virtual machines in the host system. The resource consumption data includes CPU consumption, memory consumption, and I / O consumption. The client resource acquisition module is used to collect resource usage data of each virtual CPU and functional module inside the client system. The resource usage data includes the running status of the virtual CPU and the resource occupancy of each functional module. The time alignment module is used to align the timestamps of resource consumption data collected in the host system and resource usage data collected in the client system based on a two-way time calibration mechanism, and to establish a mapping relationship between the host system time and the client system time. The resource attribution module is used to allocate resource consumption data in the host system to the corresponding virtual CPUs or functional modules in the guest system according to the preset cross-system mapping relationship and the mapping relationship in the time alignment module, calculate the occupancy contribution, and output the resource attribution results of the virtual machine as a whole and its sub-modules.

Citation Information

Patent Citations

  • Virtual server Virtual CPU resource monitoring and dynamic allocation method

    CN103729254A

  • Method and system for improving the accuracy of timing and process accounting within virtual machines

    US7945908B1