Ecovisor: A Virtual Energy System for Carbon-Efficient Applications

The electrical socket promises every server reliable power, hiding exactly the signals — grid carbon intensity, solar availability, battery charge — that software needs to cut emissions; the ecovisor virtualizes the energy system the way a hypervisor virtualizes a server, giving each application its own virtual grid, solar array, and battery to manage by its own policy.

Why this problem is worth solving

The paper targets

The outward view is volatile by nature. Zero-carbon sources are intermittent: solar output tracks the weather and the hour. And

None of that flexibility can currently be used, because of an abstraction. The electrical socket implements what the paper calls the reliability abstraction: power is always available, up to a maximum, no questions asked. Modern datacenter energy systems — grid connection plus batteries plus co-located renewables — hide all their internal richness behind it. Software gets no visibility into carbon intensity or solar output, and no control over power flows. The abstraction that made electrical engineering simple now blocks climate engineering.

What people did before, and where it broke

Carbon offsets. The dominant industry practice: keep operations unchanged, buy renewable generation elsewhere as an accounting counterweight. Offsets require no operational change — which is precisely their limit: direct emissions continue, and as grids decarbonize there is less and less dirty energy elsewhere to offset.

System-level carbon scheduling. Research like WaitAWhile suspends jobs when grid carbon intensity is high and resumes them when it drops — a policy the platform applies uniformly. It works, but bluntly: the paper measures 24.5% carbon reduction on an ML training job at the cost of 7.4× longer runtime. A uniform policy cannot know that one application parallelizes cheaply while another bottlenecks on synchronization, or that a web service cannot suspend at all.

The auto-scaling precedent. Cloud platforms already faced this exact dilemma for resources: how many servers an application needs under varying load is application-specific knowledge, so platforms exposed elastic auto-scaling APIs and delegated the policy to applications. The ecovisor argues carbon deserves the same treatment: the platform provides mechanism and isolation; the application, which knows its own performance-cost-carbon trade-off, provides policy. Existing monitoring APIs (CloudWatch, Azure Monitor) could be extended with power and carbon the same way.

The idea

Virtualize energy like compute. Each application receives a virtual energy system: a share of grid power, a share of the solar array’s variable output, and a slice of the battery’s energy and power capacity. The ecovisor meters and attributes everything — power, energy, and carbon — per container and per application.

Mechanism has fixed physics; policy is free. The virtual system follows conservation rules the application cannot break: virtual solar is used first; excess solar charges the virtual battery; demand beyond solar draws from the battery up to the application-set maximum discharge rate, then from the grid — with grid carbon attributed to the application. One subtlety the paper enjoys: unlike CPU schedulers, which may choose to be non-work-conserving, an energy system is energy-conserving by physics — excess solar when a battery is full must go somewhere (be reassigned to other tenants, net-metered to the grid, or curtailed), and that choice is an explicit platform policy.

The API is deliberately narrow. Three setters (container power cap, battery charge rate, battery max discharge), a handful of getters, and a periodic tick() callback. Everything applications need to implement suspend-resume, scale-up, carbon budgeting, or battery management — and nothing that entangles the platform in their logic. Power capping rides on proven container machinery (per-core utilization limits via cgroups).

Policies live where the knowledge lives. The case studies are the argument. A Wait&Scale batch policy suspends above a carbon threshold but scales up below it — and its optimal scale factor is application physics: ResNet training stops benefiting at 2× (gradient synchronization overheads), while embarrassingly-parallel BLAST profits through 3× and only saturates at 4× (its task-queue server becomes the bottleneck). A web service cannot suspend, so it budgets: banking carbon credits during low-carbon or low-load hours and spending them to hold its 95th-percentile latency SLO through simultaneous carbon and traffic peaks. No platform scheduler could know any of this.

B: low load → banks carbon credits
A: carbon < threshold → scale to 3×

Why it works

• The socket’s reliability abstraction hides carbon signals in hardware → virtualizing the energy system re-exposes them as software state → applications can finally use their temporal, spatial, and intensity flexibility on the actual problem.
• The performance-cost-carbon trade-off is application knowledge (sync overheads, SLOs, delay tolerance) → delegating policy to applications, like auto-scaling did, puts decisions where the information is → app-specific policies dominate system-wide ones in every experiment.
• Mechanism/policy separation keeps the platform honest → the ecovisor enforces conservation and isolation (your battery, your carbon attribution) while refusing to guess preferences → tenants with opposite policies coexist on shared hardware.
• The API mirrors proven cloud idioms (get/set/tick, per-container caps via cgroups) → adoption is an extension of existing COPs and monitoring APIs, not a new stack.
• Batteries turn carbon volatility into an arbitrage opportunity → charge when clean, discharge when dirty — under application control, sized to each tenant’s risk tolerance.

What it costs

• Application effort. Carbon policy becomes tenant code; naive or adversarial policies waste their own budget (though isolation contains the damage).
• Small scale. The physical prototype is ARM microservers (1.35–10 W each) with a 2 kW solar emulator; datacenter-scale runs use simulated energy sources on 16 Xeon servers.
• Missing incentives. The paper is explicit: without carbon pricing or caps, no financial force pushes tenants to use these controls — a social problem the ecovisor enables but cannot solve.
• Scope 2 only. Embodied (Scope 3) carbon — manufacturing — and direct (Scope 1) emissions are out of scope; so are spatial (multi-datacenter) policies, though the API could support them.
• Attribution fidelity. Virtual accounting inherits the accuracy of software power meters and of grid carbon-intensity feeds, both approximations.

The evaluation

The prototype virtualizes a real physical energy system: an ARM-microserver cluster on a power bus fed by grid, physical battery, and a Chroma solar-array emulator replaying real solar traces, with carbon intensity from real CAISO (California grid) 2020 data. Case studies run concurrently as tenants, each policy compared against carbon-agnostic and system-level baselines.

A third case study runs a solar-plus-battery-only (“zero-carbon”) setup: a delay-tolerant Spark preprocessing pipeline and a web server share one panel and one battery, each managing its own virtual battery differently — Spark tracking the solar curve with its worker count, the web server drawing a guaranteed minimum power to smooth solar volatility under a minimum state-of-charge policy. The multi-tenant runs confirm the isolation story: concurrent tenants with opposite policies each meet their own goals on shared hardware.