The hardware measures itThe hypervisor has it Your VM doesn't
An open call to every cloud provider: let tenants see exactly how much energy their VMs consume in real time. Once that data exists, tools like Kepler can break it down to every container and process.
The gap between intention and measurement
Every major cloud provider has a sustainability pledge. Every one publishes a carbon dashboard — monthly, aggregated, weeks delayed. Yet not a single one gives tenants the one thing that would make software carbon intensity actionable: real-time energy measurements for the workloads they run.
The best the ecosystem can offer today is estimation. Projects like Kepler use ML models to infer energy from CPU counters. Tools like Cloud Carbon Footprint reverse-engineer consumption from billing line items. These are impressive engineering efforts — and they are fundamentally limited by the absence of ground truth.
The hardware already knows. On x86 servers, RAPL (Running Average Power Limit) reads energy at the socket level with hardware-grade accuracy. The hypervisor has this data. It is being withheld from the tenants who need it most.
Principles of Open VM Energy Telemetry
Measure, don't model
Energy data exposed to tenants must originate from hardware counters, not from billing-derived estimates. Any hardware measurement — even imperfect — is closer to reality than reverse-engineering energy from cloud bills.
Per-VM, not per-account
Aggregate carbon dashboards cannot drive workload-level optimization. Energy telemetry must be attributable to individual VM instances and consumable by existing observability stacks like Prometheus and OpenTelemetry.
Secure by design
Rate limiting, noise injection, and domain aggregation are non-negotiable. Energy telemetry must never become a side-channel vector.
Opt-in, not mandatory
Energy telemetry should be a configuration flag on VM creation — available to those who need it, invisible to those who don't.
Open format, open spec
The telemetry format should be standardized across providers — OpenMetrics-compatible, documented publicly, and governed by a neutral body. No vendor lock-in on sustainability data.
Start with what exists
Begin with CPU package energy on x86 where hardware measurement exists and the proportional attribution model is validated. Network, storage, and accelerator attribution should follow as separate, honest specifications.
Why we wrote this
We built kubmin — a Kubernetes observability tool that tracks per-workload cost, energy consumption, and Software Carbon Intensity scores. It works. But in cloud environments, every energy number it shows is an estimate. The ML models behind tools like Kepler are the best available — and they're still models. We have no way to validate them against ground truth because ground truth is locked inside the hypervisor. Real energy measurements would transform estimates into auditable metrics — not just for kubmin, but for every tool in the ecosystem.
What we're asking
To cloud providers
- Implement per-VM energy attribution at the hypervisor level using hardware energy counters and CPU scheduling data.
- Expose it as an opt-in VM configuration flag — default off, documented in public API references.
- Deliver readings via a secure, rate-limited channel at no more than one sample per 30 seconds with calibrated noise injection.
- Publish the attribution methodology, security model, and measurement source openly.
To the ecosystem
- If you build tools that estimate energy — co-sign this manifesto. The more tools that would consume this data, the stronger the case for providers to produce it.
- If you run workloads on public cloud and care about energy transparency — tell your provider. Feature requests from paying customers move roadmaps.
This is a conversation starter, not a finished standard.
We're applying the principle of the Open Cloud Manifesto to the one resource cloud providers measure but don't share — energy. Join the discussion.
References
- RAPL in Action: Experiences in Using RAPL for Power Measurements — Khan et al., ACM TOMPECS 2018
- PLATYPUS: Software-based Power Side-Channel Attacks on x86 — Lipp et al., 2020
- Kepler: Kubernetes-based Efficient Power Level Exporter — CNCF Sandbox Project
- ISO/IEC 21031:2024 — Software Carbon Intensity (SCI) — Green Software Foundation / ISO
- Container-level Energy Observability in Kubernetes Clusters — Pijnacker et al., 2025
- Real-Time Energy and Carbon Standard for Cloud Providers — Green Software Foundation
- EP-003: VM CPU Power Modeling for Kepler — Proposal for ML estimation when RAPL is unavailable — Kepler / CNCF