Project Vision: Replacing Model-Based VM Power Estimation with Direct Measurement

[dipankardas011]

Project Vision

Can vrapl eliminate the need for model-based power estimation algorithms in cloud environments?

Short Answer: YES, mostly - but with caveats.

The vrapl project demonstrates that real-time, hardware-based power attribution to VMs is feasible and significantly more accurate than traditional model-based approaches. This could revolutionize how cloud providers expose power consumption data to tenants.

---

Technical Feasibility Analysis

1. Character Device Approach (Most Practical)

/dev/vm-power or /sys/class/vm-power/vm-<uuid>/

How it would work:

# Inside VM:
cat /sys/class/vm-power/energy_uj
cat /sys/class/vm-power/power_uw
cat /sys/class/vm-power/attribution_method  # Shows how power is calculated

Implementation:

• Kernel module in host OS
• Exposes virtual device to each VM
• Rate-limited reads (e.g., 1 Hz max)
• Quantized values to prevent side-channels
• Read-only, no privileged access needed

Security mitigations:

// Pseudocode for the kernel driver
struct vm_power_device {
    u64 last_read_time;
    u64 read_count;
    u32 rate_limit_hz;  // Max 1-10 Hz
    u32 quantize_bits;  // Round to nearest 100mW
};

// Rate limiting + quantization
int vm_power_read(struct file *f, char __user *buf) {
    if (time_since_last_read < rate_limit)
        return -EAGAIN;
    
    power = get_vm_attributed_power();
    power = quantize(power, 100mW);  // Reduce precision
    
    return copy_to_user(buf, &power, sizeof(power));
}

---

What This Would Solve

✅ Eliminates for CPU power:

• Direct RAPL measurement
• Real-time attribution
• No need for CPU power models

✅ Reduces need for models:

• More accurate than utilization-based estimation
• No need to calibrate per-workload
• Works across different CPU generations

✅ Side-channel protection:

• Rate limiting prevents high-resolution monitoring
• Quantization adds noise
• Still useful for accounting, not for attacks

---

What Still Needs Models

❌ Memory power (harder to attribute):

• Shared memory controllers
• NUMA effects
• Cache sharing between VMs
• Would need DRAM RAPL + memory bandwidth tracking

❌ I/O subsystem power:

• Shared storage controllers
• Network interfaces
• PCIe devices
• Needs activity-based models

❌ Platform/Uncore power:

• Shared across all VMs
• How to split chipset power?
• Fair attribution is complex

---

Hybrid Approach (Best Solution)

Total VM Power = Measured CPU Power + Modeled Memory + Modeled I/O
                 ^^^^^^^^^^^^^^^^     ^^^^^^^^^^^^^^   ^^^^^^^^^^^
                 vrapl does this      Still need       Still need
                 accurately           models           models

---

Real-World Implementation Path

Phase 1: Current vrapl approach ✅ (We're here!)

// What we have now:
vmPower = hostRAPL * (vmCPUtime / totalCPUtime)

Pros:

• Works today
• No cloud provider needed
• Good for CPU-bound workloads

Cons:

• Requires host access
• Only CPU power
• Manual setup per VM

Phase 2: Enhanced attribution (Next step)

Add memory and I/O:

vmPower = (cpuPower * cpuFraction) + 
          (memPower * memBandwidthFraction) +
          (ioPower * ioActivityFraction)

Where to get the data:

# CPU: RAPL (we have this)
/sys/class/powercap/intel-rapl:0/energy_uj

# Memory: RAPL DRAM + bandwidth tracking
/sys/class/powercap/intel-rapl:0:1/energy_uj  # DRAM subdomain
/sys/devices/system/node/node0/meminfo         # Bandwidth estimate

# I/O: Model based on activity
/proc/<pid>/io  # VM process I/O stats

Phase 3: Cloud Provider Standard (Future vision)

Option A: Virtio-power device

New virtio device type that all hypervisors support:
- QEMU/KVM
- Xen
- VMware
- Hyper-V

Option B: Cloud metadata service

# Inside VM:
curl http://169.254.169.254/latest/power-metrics
{
  "timestamp": "2025-10-23T10:30:00Z",
  "power_watts": 12.5,
  "energy_joules": 25.0,
  "attribution_method": "cpu-proportional",
  "accuracy": "±5%",
  "components": {
    "cpu": 8.5,
    "memory": 2.0,
    "io": 2.0
  }
}

Option C: Standard device path

# Similar to our current approach but standardized:
/sys/class/vm-energy/current_uj
/sys/class/vm-energy/power_uw
/sys/class/vm-energy/attribution_details

---

Industry Adoption Likelihood

HIGH likelihood because:

1. Sustainability pressure - Cloud providers need to report carbon footprint
2. Cost transparency - Customers want to see energy costs
3. Green computing - Regulatory requirements coming
4. Already happening - Some providers expose partial data:
   • AWS CloudWatch has EC2 metrics (CPU, network)
   • Google Cloud Carbon Footprint
   • Azure Sustainability Calculator

What's missing: Direct power measurement exposure to VMs

---

vrapl's Demonstration Value

This project demonstrates:

1. ✅ It's technically feasible
2. ✅ Attribution can be done in real-time
3. ✅ Works with existing hardware (RAPL)
4. ✅ Low overhead

This could be a reference implementation!

---

Would This Eliminate Models?

Summary:

Component	Current (Models)	With vrapl approach	Still need models?
CPU Power	❌ Estimated	✅ Measured (RAPL)	❌ No
Memory Power	❌ Estimated	⚠️ Partially measured	✅ Some
I/O Power	❌ Estimated	❌ Estimated	✅ Yes
Network Power	❌ Estimated	❌ Estimated	✅ Yes
Storage Power	❌ Estimated	❌ Estimated	✅ Yes

Result: 60-70% of power can be measured, 30-40% still needs models

For CPU-intensive workloads (ML training, compute, data processing), this approach is massively better than models.

---

Recommended Enhancements

To strengthen vrapl as a reference implementation:

1. Memory attribution - Add RAPL DRAM domain monitoring
2. Multiple VM support - Monitor N VMs simultaneously
3. Standard export format - Prometheus metrics, JSON API
4. Documentation - How cloud providers could adopt this
5. Benchmarking - Compare accuracy vs. model-based approaches
6. Optional dashboard - Web UI for visualization

---

Long-term Vision

"vrapl: Reference implementation for VM power attribution that cloud providers could adopt as an industry standard"

By demonstrating feasibility and accuracy, vrapl could influence:

• Virtio specification additions
• Cloud provider metadata standards
• Kubernetes power-aware scheduling
• Green computing certifications
• Carbon accounting standards

---

Next Steps

• Enhance current implementation (see recommended enhancements above)
• Document accuracy vs. model-based approaches
• Create proposal for virtio-power device specification
• Engage with cloud provider open source communities
• Publish findings/whitepaper

[dipankardas011]

🔄 IMPORTANT CLARIFICATION

After further analysis, the framing of this issue needs an update. See Issue #5 for the correct understanding of vrapl's purpose.

What This Issue Got Wrong:

This issue positions vrapl as replacing model-based estimation tools, making it sound like vrapl competes with Kepler/Scaphandre/PowerJoular.

The Correct Understanding:

vrapl is a TRANSPORT MECHANISM that ENABLES all these tools to work accurately in cloud VMs.

❌ WRONG: "vrapl replaces Kepler/Scaphandre"
✅ RIGHT: "vrapl enables Kepler/Scaphandre to get accurate data"

The Real Vision (Corrected):

Problem:

• Cloud VMs have no RAPL access
• Kepler falls back to ML estimator (inaccurate)
• Scaphandre doesn't work (Issue Integrate power consumption estimation on public cloud virtual machines as a degraded mode hubblo-org/scaphandre#25)
• All tools use approximations

vrapl's Solution:

• Show cloud providers HOW to expose RAPL to guest VMs
• Reference implementation (serial port transport)
• Enable ALL existing tools to work with hardware-based data

Result:

Cloud Provider implements vrapl approach
           ↓
Guest VM gets RAPL data
           ↓
User installs:
  • Kepler (now uses real data instead of ML) ✅
  • Scaphandre (now works in cloud) ✅  
  • PowerJoular (now works in cloud) ✅
  • Any tool they want ✅

What's Still Valuable Here:

The analysis of what percentage of power can be measured (60-70% CPU, rest needs models) is still valid. The hybrid approach section is still correct.

The difference is:

• Old framing: vrapl is a measurement tool
• New framing: vrapl is a transport mechanism that enables measurement tools

Updated Vision Statement:

"vrapl: A reference implementation showing cloud providers how to expose RAPL data to guest VMs, enabling accurate power monitoring with any tool (Kepler, Scaphandre, or custom solutions)"

The Path Forward:

Phase 1: ✅ Demonstrate transport mechanism works (current vrapl)
Phase 2: Propose standard interface (virtio-power device)
Phase 3: Cloud provider adoption

Once adopted:

• ✅ 60-70% of power measured directly (not estimated)
• ✅ All tools work accurately
• ✅ Users choose their preferred tool
• ✅ No more reliance on ML models for basic metrics

See Issue #5 for the complete reframing.