Guest-only Resource Energy Estimation

• Guest-only resource-based energy estimation is a method that predicts power consumption solely from guest-level resource metrics after an offline calibration phase.
• It utilizes a range of models from linear regression to gradient boosting to convert observables like CPU, memory, disk, and network usage into accurate power estimates.
• The approach supports scales from server-level predictions to per-VM, container, and process disaggregation, addressing critical challenges of attribution and multi-tenancy.

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 (Smith et al., 2012, Sangha, 12 Sep 2025, Choochotkaew et al., 2024). 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 (Sangha, 12 Sep 2025, Choochotkaew et al., 2024).

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 (Sangha, 12 Sep 2025). 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” (Smith et al., 2012). 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” (Choochotkaew et al., 2024).

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 (Smith et al., 2012). 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 (Sangha, 12 Sep 2025). Container-oriented frameworks seek “container-level” or “service-level” energy from cgroups, cAdvisor, eBPF, and optional hardware counters (Choochotkaew et al., 2024, Legler, 23 Jan 2026). 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 (León-Vega et al., 2024).

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” (Thamm et al., 14 May 2025). 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})$$ (Smith et al., 2012). 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 (Povoa et al., 2017).

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 (Sangha, 12 Sep 2025). 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 (Sangha, 12 Sep 2025). 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 (Sangha, 12 Sep 2025).

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” (Choochotkaew et al., 2024). 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 (Legler, 23 Jan 2026). CEEMS likewise attributes node energy to workloads using “CPU time,” “memory usage,” and “job counts derived from cgroups and job metadata” (Paipuri, 2024).

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” (León-Vega et al., 2024). 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 (Getzner et al., 2023). 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 (Getzner et al., 2023). 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 (Georgiou et al., 2016).

Representative setting	Guest-visible observables	Runtime access to hardware power
Cloud server model (Smith et al., 2012)	CPU, Memory, Hard Disk, Network	No, after calibration
VM guest-only model (Sangha, 12 Sep 2025)	cpu.total, mem.used, disk.read, disk.write, net.rx, net.tx	No
Container/service models (Choochotkaew et al., 2024, Legler, 23 Jan 2026)	cGroups, cAdvisor, eBPF, container bytes and usage	No, after training
Process disaggregation (León-Vega et al., 2024)	CPU usage, RAM, network, instruction mix histogram	No, after calibration
Design-time DL model (Getzner et al., 2023)	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 (Smith et al., 2012). 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 (Sangha, 12 Sep 2025). 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 (Cao et al., 2020).

The simplest model family is linear regression. CloudMonitor uses a host-level linear model with an intercept representing baseline or idle power (Smith et al., 2012). 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 (Povoa et al., 2017). 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 (Povoa et al., 2017).

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” (Sangha, 12 Sep 2025). 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 (Choochotkaew et al., 2024). 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 (Legler, 23 Jan 2026).

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 $\ge 0.1$0 is the instruction-type fraction and $\ge 0.1$1 is CPU utilization (León-Vega et al., 2024). The work shows that the precise choice of $\ge 0.1$2 is “micro-architecture dependent,” with a mixed linear/log form best on AMD EPYC and a pure linear form better on Intel Xeon (León-Vega et al., 2024).

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: $\ge 0.1$3 (Getzner et al., 2023). LLVM-based “energy transparency” similarly assumes an ISA energy model has already been built; energy is then lifted to LLVM IR through a mapping

$\ge 0.1$4

and either aggregated statically or combined with profiled basic-block counts (Georgiou et al., 2016). 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 (Smith et al., 2012). 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” (Thamm et al., 14 May 2025). 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 (Paipuri, 2024).

Container systems formalize attribution through isolation. The Kepler framework trains a system-level model $\ge 0.1$5 from aggregated node usage $\ge 0.1$6 to node power $\ge 0.1$7, then estimates background power for a target container $\ge 0.1$8 as $\ge 0.1$9, and defines isolated workload power as

$$\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]$$0

(Choochotkaew et al., 2024). The framework then trains a container model on $$\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]$$1 with $$\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]$$2 as labels, rather than on raw node power. To decide whether a system model is suitable for this labeling step, it introduces “isolation goodness” $$\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]$$3, defined as the maximum Pearson correlation between isolated power and any target-container feature (Choochotkaew et al., 2024). 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 (Legler, 23 Jan 2026). 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” (Legler, 23 Jan 2026). This directly challenges CPU-only attribution schemes.

EfiMon treats disaggregation as superposition. The per-process dynamic power estimate is

$$\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]$$4

and total dynamic power is the sum across processes (León-Vega et al., 2024). 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 (León-Vega et al., 2024). 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 (Smith et al., 2012, Thamm et al., 14 May 2025, Choochotkaew et al., 2024, León-Vega et al., 2024). 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 (Smith et al., 2012). 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 $$\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]$$5 (Povoa et al., 2017). EfiMon reports robust shared-node process prediction, with maximum deviations of “2.2%” on Intel and “4.4%” on AMD relative to isolated execution (León-Vega et al., 2024).

Strict VM guest-only estimation without privileged host access has lower, but still strong, predictive performance. The virtual-server paper reports

$$\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]$$6

across three workload classes and a merged model, with MAE ranging from “2.48” to “4.10” W and the merged model reaching $$\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]$$7, MAE $$\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]$$8 W, RMSE $$\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]$$9 W (Sangha, 12 Sep 2025). 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 (Sangha, 12 Sep 2025).

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{compute}(c,t)}$0

the observed error ranges “from ~2% up to 47%,” with “>90% of runs” showing “error $E_{\text{compute}(c,t)}$1” and average errors of “26%” for BERT-base, “47%” for RoBERTa-base, “30%” for MobileBERT, and “36%” for DistilBERT (Cao et al., 2020). 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 (Cao et al., 2020). 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%” (Legler, 23 Jan 2026). 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 (Thamm et al., 14 May 2025). 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” (Smith et al., 2012). The paper explicitly argues that separate energy usage tariffs could “incentivize software developers to create energy-efficient applications” (Smith et al., 2012). 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 (Paipuri, 2024).

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 (Choochotkaew et al., 2024). GOXN uses the OpenTelemetry Demo to study “monitoring, tracing, service mesh,” showing that observability settings change the energy balance between compute, network, and storage (Legler, 23 Jan 2026). 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” (Sangha, 12 Sep 2025). 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 (Getzner et al., 2023). 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 (Georgiou et al., 2016). 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 (Smith et al., 2012, Cao et al., 2020, Sangha, 12 Sep 2025). Multi-tenancy and concurrent attribution remain central unresolved challenges in workflow and VM settings (Thamm et al., 14 May 2025, Sangha, 12 Sep 2025). Dynamic frequency scaling, background power, and control-plane activity create non-stationary baselines that static or heuristic subtraction handles poorly (Cao et al., 2020, Choochotkaew et al., 2024). GPU-heavy and accelerator-heavy workloads are only partially covered: the NLP study shows the danger of simplistic GPU models (Cao et al., 2020), EfiMon leaves GPU energy “for future work” (León-Vega et al., 2024), and CEEMS supports NVIDIA and AMD GPU reporting but remains rule-based (Paipuri, 2024).

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 (Smith et al., 2012, Choochotkaew et al., 2024, Sangha, 12 Sep 2025, Legler, 23 Jan 2026).