---
title: Guest-only Resource Energy Estimation
url: https://www.emergentmind.com/topics/guest-only-resource-based-energy-estimation
type: topic
---

# Guest-only Resource Energy Estimation

Guest-only resource-based energy estimation is the estimation of power or energy from metrics that are visible to software running at the guest, container, process, or application layer, rather than from direct access to physical power meters or privileged host interfaces. In the literature summarized here, the common pattern is an offline or limited calibration phase against hardware measurements, followed by operational inference from resource-usage observables such as CPU, memory, disk, network, cgroup counters, container metrics, instruction mix, or model-structure descriptors [1205.2546] [2509.09991] [2407.00878]. The topic spans whole-server power prediction, per-VM estimation, per-container attribution, per-process disaggregation, workflow-task approximation, and pre-execution model-level prediction; however, the strongest formulations of “guest-only” are those in which inference uses only guest-visible resource metrics and does not require privileged host access at runtime [2509.09991] [2407.00878].

## 1. Conceptual definition and scope

Guest-only resource-based energy estimation is motivated by the fact that in cloud and virtualized systems “direct energy measurement is infeasible,” while tenants can still read “standard OS-level utilization metrics inside the guest” such as CPU, memory, disk I/O, and network I/O [2509.09991]. Earlier cloud work framed the same problem at server scale: hardware monitoring devices can be “impractical or uneconomical due to the large number of machines to be metered,” so power is inferred from “resource-usage metrics collected in software” [1205.2546]. A closely related formulation in Kubernetes states that after model training, power approximation of individual containers should not require “online power measurements,” “information on the physical servers,” or “information on other tenants sharing the same machine” [2407.00878].

Across the literature, the term covers several levels of attribution. CloudMonitor predicts the “total power of a physical server” from CPU, memory, hard disk, and network usage, and then reuses the model on machines with the same hardware configuration [1205.2546]. A later virtual-server study explicitly targets “guest-only resource-based energy estimation without privileged host access,” with the guest predicting “its own” energy from six guest-visible metrics and host RAPL used only during training [2509.09991]. Container-oriented frameworks seek “container-level” or “service-level” energy from cgroups, cAdvisor, eBPF, and optional hardware counters [2407.00878] [2601.16635]. Process-oriented work in shared HPC nodes estimates “single processes’ power consumption in isolated and shared resource environments” from process CPU usage and instruction mix, but it is operator-facing rather than strictly unprivileged guest-side because training and monitoring rely on PSU power, RAPL, IPMI, and `perf` [2409.17368].

A useful boundary condition appears in the workflow literature: “measuring the energy consumption of a single task is straight forward when only one task runs at a time, but concurrent task executions on the same node require approximating per-task energy usage using metrics such as CPU utilization” [2505.09375]. This suggests that guest-only estimation is not only a measurement problem but also an attribution problem.

## 2. Observables and model inputs

The defining feature of the paradigm is that the predictors are software-visible resource observables. In the classic cloud-server formulation, the model is a linear combination of “CPU,” “Memory,” “Hard Disk,” “Network,” and a “Baseline Power” term:
\[
\text{Power} = a \cdot \text{Baseline Power} + (B_1 \cdot \text{CPU}) + (B_2 \cdot \text{Memory}) + (B_3 \cdot \text{Hard Disk}) + (B_4 \cdot \text{Network})
\]
[1205.2546]. A later Linux-based study broadened this to “commodity system variables commonly provided by Linux,” initially collecting 47 variables from `/proc` and then retaining variables with MIC \(\ge 0.1\), including CPU times, memory counters, disk statistics, network counters, and an “ARCH” indicator [1709.06076].

In strict VM guest-only work, the input vector is intentionally minimal and generic:
\[
\mathbf{x}_t = \big[ \text{cpu.total}_t,\, \text{mem.used}_t,\, \text{disk.read}_t,\, \text{disk.write}_t,\, \text{net.rx}_t,\, \text{net.tx}_t \big]
\]
with “Glances” logging these six metrics every second inside the guest [2509.09991]. The target is host-side power in Watts obtained via “PowerJoular” pinned to the KVM process during training, after which inference uses only the guest-side features [2509.09991]. The feature-importance results in that work show that workload type determines which guest-visible metrics dominate: “cpu.total” for compilation, “net.rx” and “net.tx” for a web server, and “disk.write” for a database [2509.09991].

Container-oriented systems extend the metric space rather than changing the principle. The Kepler training framework groups features by “metric producer”: hardware performance counters when available, “cGroups metrics,” “cAdvisor metrics,” and “BPF (eBPF) probe metrics” [2407.00878]. GOXN builds service-level energy from three container-level data streams: \(E_{\text{compute}(c,t)}\) from Kepler, \(B_{\text{network}(c,t)}\) from cAdvisor/Prometheus, and \(B_{\text{storage}(c,t)}\) from cAdvisor plus storage snapshots [2601.16635]. CEEMS likewise attributes node energy to workloads using “CPU time,” “memory usage,” and “job counts derived from cgroups and job metadata” [2412.07290].

At the process level, EfiMon introduces a richer resource description. For a process of interest it records “CPU usage,” “RAM usage,” “Network usage,” and an “instruction mix histogram” over “scalar arithmetic, scalar memory, scalar logic, vector arithmetic, vector memory, vector logic, branches, jumps” [2409.17368]. This is still resource-based, but the predictors are closer to microarchitectural activity than to ordinary guest VM counters.

Adjacent work on deep learning introduces a different kind of guest-visible input: model structure. A design-time estimator predicts CPU inference energy from “layer type,” “hyperparameters,” “tensor dimensions,” “batch size,” and “MAC count,” without runtime measurements at inference time [2304.00897]. This is not runtime guest-only metering, but it remains resource-based in the sense that the required inputs are software-visible and no privileged energy interface is required after the offline training stage [2304.00897]. A similar “energy transparency” line lifts ISA energy models to LLVM IR, so that energy can be attached to IR instructions and basic blocks through static analysis or profiling “without hardware energy measurements” at estimation time [1609.02193].

| Representative setting | Guest-visible observables | Runtime access to hardware power |
|---|---|---|
| Cloud server model [1205.2546] | CPU, Memory, Hard Disk, Network | No, after calibration |
| VM guest-only model [2509.09991] | `cpu.total`, `mem.used`, `disk.read`, `disk.write`, `net.rx`, `net.tx` | No |
| Container/service models [2407.00878] [2601.16635] | cGroups, cAdvisor, eBPF, container bytes and usage | No, after training |
| Process disaggregation [2409.17368] | CPU usage, RAM, network, instruction mix histogram | No, after calibration |
| Design-time DL model [2304.00897] | Layer parameters, tensor sizes, MACs | No |

## 3. Modeling forms and calibration regimes

A recurring pattern is a two-phase regime: calibration with hardware measurements on a subset of systems, followed by software-only inference. CloudMonitor is explicit that operation is divided into a “Training phase” using “hardware power measurements from PDUs on a subset of machines” and an “Operational phase” in which “no more hardware power meters are required” for machines of the same hardware configuration [1205.2546]. The virtual-server study follows the same structure: host-side PowerJoular and RAPL provide labels, while the guest model is trained from timestamp-aligned guest metrics and then deployed without privileged access [2509.09991]. The NLP measurement study reaches a similar conclusion from the opposite direction, recommending “using hardware power meters to measure the energy consumption, and then possibly calibrate the software energy values” because uncalibrated software-only estimates are unreliable [2010.05248].

The simplest model family is linear regression. CloudMonitor uses a host-level linear model with an intercept representing baseline or idle power [1205.2546]. A broader Linux-based study compares Multiple Linear Regression, Regression Trees, and Multilayer Perceptron, with generic form
\[
P = \beta_0 + \sum_k \beta_k x_k
\]
for the linear model and cross-validated alternatives for heterogeneous hardware [1709.06076]. The authors report that MLP is the “overall winner,” especially on the mixed-hardware dataset, while MLR remains attractive for homogeneous deployment because of its simplicity and low inference cost [1709.06076].

Later work emphasizes nonlinearity. The VM guest-only paper uses a “Gradient Boosting Regressor” with “200 regression trees,” motivated by the ability to capture “non-linear relationships between resource usage and power” [2509.09991]. The Kepler training framework does not fix a single regressor; it evaluates “Linear regression,” “Polynomial regression,” “k-Nearest Neighbors (kNN) regression,” “Gradient Boosting Regression (GBR),” “Stochastic Gradient Descent (SGD) regression,” and “Support Vector Regression (SVR)” for both system-level and container-level models [2407.00878]. By contrast, GOXN’s service-level model is additive rather than learned:
\[
E_{\text{service}} = E_{\text{compute}} + E_{\text{network}} + E_{\text{storage}}
\]
with compute taken from Kepler and network/storage inferred through energy-intensity factors applied to container bytes [2601.16635].

Process-level disaggregation in EfiMon uses a regression over transformed resource features. The system model begins from
\[
P_{\text{system},t} = P_{\text{static},t} + \sum_{p=1}^{N_p} \sum_{k=1}^{S} \gamma_k \, \sigma(h_k^p, w_p)
\]
and, for a process in isolation, reduces to
\[
P_{\text{PSU},t} = \sum_{k=1}^{S} \gamma_k \, \sigma(h_k^p, w_p) + \hat{P}_{\text{static},t}
\]
where \(h_k^p\) is the instruction-type fraction and \(w_p\) is CPU utilization [2409.17368]. The work shows that the precise choice of \(\sigma\) is “micro-architecture dependent,” with a mixed linear/log form best on AMD EPYC and a pure linear form better on Intel Xeon [2409.17368].

A different calibration logic appears in design-time and static-analysis work. The deep-learning predictor trains per-layer regressors offline from “high-quality energy data” and then estimates full-model energy by summing predicted layer energies:
\[
\hat{E}_{\text{model}} = \sum_{k=1}^K \hat{E}_{L_k}
\]
[2304.00897]. LLVM-based “energy transparency” similarly assumes an ISA energy model has already been built; energy is then lifted to LLVM IR through a mapping
\[
\mathrm{E}(ir_i) = \sum_{isa_j \in \mathrm{R}(ir_i)} \mathrm{E}(isa_j)
\]
and either aggregated statically or combined with profiled basic-block counts [1609.02193]. This suggests an important distinction: some guest-only estimators infer from runtime usage metrics, while others infer from program structure alone.

## 4. Attribution, isolation, and multi-tenancy

The hardest problem is not total-node estimation but allocation under sharing. CloudMonitor itself is “per-host / per-server” and “does not implement or detail per-VM power attribution,” although the paper notes that the same principles could be extended if per-VM resource metrics were available [1205.2546]. The workflow paper states the issue plainly: when “only one task runs at a time,” task energy can be identified with node energy over the task interval, but “concurrent task executions on the same node require approximating per-task energy usage using metrics such as CPU utilization” [2505.09375]. CEEMS operationalizes this at job level through a rule-based power split that uses node power from IPMI, CPU/DRAM proportions from RAPL, CPU-time fractions, memory fractions, and equal sharing of a residual “10%” networking/other component [2412.07290].

Container systems formalize attribution through isolation. The Kepler framework trains a system-level model \(M_{\text{sys}}\) from aggregated node usage \(U(t)\) to node power \(P(t)\), then estimates background power for a target container \(x\) as \(M_{\text{sys}}(U(t)-x(t))\), and defines isolated workload power as
\[
\Delta P_x(t) = P(t) - P_{U-x}(t)
\]
[2407.00878]. The framework then trains a container model on \(x(t)\) with \(\Delta P_x(t)\) as labels, rather than on raw node power. To decide whether a system model is suitable for this labeling step, it introduces “isolation goodness” \(\rho\), defined as the maximum Pearson correlation between isolated power and any target-container feature [2407.00878]. This explicitly acknowledges that a numerically accurate system-level fit can still produce poor attribution if the residual no longer tracks workload usage.

GOXN addresses a related attribution issue from a service perspective. It maps containers to pods and pods to Kubernetes services, then aggregates container-level compute, network, and storage energy to service level [2601.16635]. The principal empirical result is attributional rather than purely predictive: “excluding network and storage can underestimate auxiliary-service energy by up to 63%, and that high tracing loads shift energy dominance toward network and storage” [2601.16635]. This directly challenges CPU-only attribution schemes.

EfiMon treats disaggregation as superposition. The per-process dynamic power estimate is
\[
P_{\text{dynamic}^{(p)}(t)} = \sum_{k=1}^{S} \gamma_k \,\sigma(h_k^p(t), w_p(t))
\]
and total dynamic power is the sum across processes [2409.17368]. In shared-node experiments with a dgemm noise process, the predicted power of the process of interest remains close to its isolated prediction, with maximum deviation of “2.2% on Intel-based machines and 4.4% on AMD systems” compared to non-shared cases [2409.17368]. This is not a guest-only deployment model in the strict VM-tenant sense, but it is a strong result on attribution under sharing.

A persistent misconception is that guest-only estimation must be equivalent to direct per-guest measurement. The literature does not support that view. The cloud, workflow, container, and process papers all distinguish between total-system energy, dynamic background or baseline components, and the portion attributable to an individual tenant, container, or process [1205.2546] [2505.09375] [2407.00878] [2409.17368]. A plausible implication is that “guest-only” is best understood as an inference layer over resource observables, not as a direct sensor.

## 5. Accuracy, robustness, and known failure modes

Accuracy claims vary sharply with scope, hardware homogeneity, and whether calibration is performed. On homogeneous cloud servers, CloudMonitor reports an “average error rate of 3.91%,” corresponding to “mean accuracy of 96.09%,” after training on “24 hours” of usage data [1205.2546]. A Linux-based multi-resource model reports “99.94% of accuracy and 6.32 watts of error in the best case,” with the best mixed-hardware MLP achieving “Average AE ≈ 1.55 W,” “Average APE ≈ 2.35%,” and \(R^2 \approx 99.94\%\) [1709.06076]. EfiMon reports robust shared-node process prediction, with maximum deviations of “2.2%” on Intel and “4.4%” on AMD relative to isolated execution [2409.17368].

Strict VM guest-only estimation without privileged host access has lower, but still strong, predictive performance. The virtual-server paper reports
\[
0.90 \leq R^2 \leq 0.97
\]
across three workload classes and a merged model, with MAE ranging from “2.48” to “4.10” W and the merged model reaching \(R^2 = 0.96\), MAE \(\approx 3.17\) W, RMSE \(\approx 5.11\) W [2509.09991]. The key result is not only the metric value but the claim that these results are obtained “using resource utilization metrics collected from guest virtual machines” and “without privileged host access” at inference time [2509.09991].

By contrast, the NLP measurement paper demonstrates the failure of uncalibrated, hardware-agnostic software estimation. Using “experiment-impact-tracker” and the Strubell et al. model
\[
e_{\text{total}} = PUE \sum_p (p_{dram} e_{dram} + p_{cpu} e_{cpu} + p_{gpu} e_{gpu}),
\]
the observed error ranges “from ~2% up to 47%,” with “>90% of runs” showing “error \(\ge 20\%\)” and average errors of “26%” for BERT-base, “47%” for RoBERTa-base, “30%” for MobileBERT, and “36%” for DistilBERT [2010.05248]. The paper attributes these failures to “hardware variabilities” and “the non-linear relationship between resource utilization and energy consumption,” along with “tail energy” and phase misalignment [2010.05248]. This result is important because it identifies the conditions under which guest-side energy estimation becomes misleading.

Robustness also depends on what resources are modeled. GOXN shows that “compute-only” estimation can severely misattribute service energy in distributed systems, because “network and storage can become the dominant contributors” under heavy tracing, and ignoring them can cause underestimation “by up to 63%” [2601.16635]. The workflow paper shows another robustness boundary: coarse Prometheus scrape intervals can introduce large errors for short workflows, with 30-second scrape intervals producing discrepancies of around “30%” or “36%” on the shorter workflows tested [2505.09375]. A plausible implication is that time resolution becomes part of the model specification whenever workloads are bursty or short-lived.

## 6. Systems, applications, and open directions

The most mature application is accounting and tariffing. CloudMonitor uses estimated energy to compute that a video processing web application requires “15.73 kWh per day,” leading to a “Total energy cost over 36 months” of “\$2,767,” and in a hypothetical public cloud tariff energy becomes “2.6% of total costs” [1205.2546]. The paper explicitly argues that separate energy usage tariffs could “incentivize software developers to create energy-efficient applications” [1205.2546]. CEEMS extends the same logic to “energy and equivalent emissions of user workloads in real time for HPC and cloud platforms alike,” with operator-defined “energy estimation rules” and emissions obtained by multiplying energy with static or real-time emission factors [2412.07290].

In cloud-native systems, the topic is increasingly tied to observability and control-plane overhead. The Kepler training framework is explicitly designed for “multiple customers sharing the same hardware platform (multi-tenancy)” and for the fact that the “Cloud platform control plane induces” non-negligible overhead [2407.00878]. GOXN uses the OpenTelemetry Demo to study “monitoring, tracing, service mesh,” showing that observability settings change the energy balance between compute, network, and storage [2601.16635]. This suggests that guest-only estimation in microservices must be service-aware, not only CPU-aware.

In virtualized infrastructure, the new result is feasibility at the VM boundary. The virtual-server study presents “the first” experimental demonstration of “guest-only resource-based energy estimation without privileged host access,” but it also states clear limits: experiments are on a “single physical hardware platform,” there is “no multi-tenant interference,” and future work must address “transfer learning and cross-hardware generalization” as well as “validation on multi-tenant cloud” [2509.09991]. The literature therefore supports deployment in controlled settings more strongly than it supports universal cross-cloud portability.

Several adjacent directions broaden the concept. Design-time model estimation predicts energy “before running or training” a deep-learning model by summing layer-wise estimates from guest-visible architectural descriptors [2304.00897]. LLVM-based “energy transparency” attaches energy costs to software representations and achieves “an average error of 3%” for profiling-based estimation at LLVM IR level [1609.02193]. These are not host-agnostic runtime meters, but they show that the resource-based paradigm can be pushed above the operating-system layer to program structure itself.

Open problems are consistent across the corpus. Hardware heterogeneity repeatedly forces retraining or at least recalibration [1205.2546] [2010.05248] [2509.09991]. Multi-tenancy and concurrent attribution remain central unresolved challenges in workflow and VM settings [2505.09375] [2509.09991]. Dynamic frequency scaling, background power, and control-plane activity create non-stationary baselines that static or heuristic subtraction handles poorly [2010.05248] [2407.00878]. GPU-heavy and accelerator-heavy workloads are only partially covered: the NLP study shows the danger of simplistic GPU models [2010.05248], EfiMon leaves GPU energy “for future work” [2409.17368], and CEEMS supports NVIDIA and AMD GPU reporting but remains rule-based [2412.07290].

Taken together, the literature supports a precise characterization. Guest-only resource-based energy estimation is feasible, often accurate within a calibrated hardware context, and already useful for accounting, scheduling, and observability; but its validity depends on explicit treatment of baseline power, hardware specificity, attribution under sharing, and the inclusion of non-CPU resources when the workload demands them [1205.2546] [2407.00878] [2509.09991] [2601.16635].

Source: https://www.emergentmind.com/topics/guest-only-resource-based-energy-estimation