z/VM is designed to run far more virtual machines than the underlying hardware resources would normally allow. It achieves this through sophisticated overcommitment of CPU, memory, and I/O, while still keeping performance predictable.

Here’s how it works:

🔷 1. What Overcommitment Means in z/VM

Overcommitment =

• Allocating more virtual resources than physically available
• Relying on the fact that not all workloads peak at the same time

👉 Example:

• 100 physical CPUs → 500 virtual CPUs
• 1 TB RAM → 3–5 TB virtual memory

🔷 2. CPU Overcommitment (Time Sharing + Dispatching)

🔹 Virtual CPUs (vCPUs)

• Each VM is assigned one or more virtual CPUs

🔹 Hypervisor Scheduling

z/VM:

• Schedules vCPUs onto real CPUs
• Uses time slicing and priority-based dispatching

🔹 Share System

• Each VM gets a share value
• Determines how much CPU it receives under contention

👉 Result:

• Idle VMs consume almost no CPU
• Active VMs get more CPU dynamically

🔷 3. Memory Overcommitment (Core Strength)

z/VM is especially powerful in memory overcommitment:

🔹 a) Virtual Memory Model

• Each VM thinks it has full dedicated memory
• z/VM maps it to real memory dynamically

🔹 b) Paging & Swapping

• When memory is overcommitted:
  • Inactive pages → moved to disk (paging)
  • Active pages → kept in RAM

👉 Smart paging minimizes performance impact

🔹 c) Memory Overcommit Ratios

• Can safely exceed physical memory by 2x–5x or more
• Depends on workload behavior

🔹 d) Page Sharing (Deduplication)

• Identical memory pages across VMs are shared

👉 Example:

• Many Linux VMs → same OS pages → stored once

🔹 e) Ballooning (Cooperative Memory Reclaim)

• VMs can release unused memory back to z/VM

🔷 4. I/O Overcommitment

🔹 Virtual I/O Devices

• z/VM presents:
  • Virtual disks (minidisks)
  • Virtual network interfaces

🔹 Multiplexing

• Many VMs share the same physical I/O channels

👉 Backed by:

• IBM Z channel subsystem → very efficient I/O handling

🔷 5. Workload-Aware Optimization

z/VM continuously monitors:

• CPU usage
• Memory usage
• I/O patterns

And dynamically adjusts:

• Scheduling priorities
• Memory allocation
• Paging behavior

🔷 6. Performance Controls

To avoid overload:

🔹 Share and Limit Settings

• Guarantee minimum CPU
• Cap maximum usage

🔹 Resource Pools

• Group VMs into pools with quotas

🔹 Workload Isolation

• Critical workloads protected from noisy neighbors

🔷 7. Why Overcommitment Works Well on IBM Z

Overcommitment is more effective here because:

🔹 Large Memory Capacity

• Systems have huge RAM → less paging pressure

🔹 Fast I/O Subsystem

• Paging is fast due to channel subsystem

🔹 Predictable Workloads

• Enterprise workloads are stable and well-understood

🔹 Efficient Scheduler

• z/VM scheduler is optimized for thousands of VMs

🔷 8. Comparison with x86 Hypervisors

🔷 🔥 Simple Analogy

Think of a hotel:

• Rooms (VMs) > actual beds (hardware)
• Not all guests use beds at the same time

z/VM:

• Tracks usage
• Reassigns resources dynamically
• Ensures important guests always get priority

🔷 🚀 Bottom Line

z/VM handles overcommitment by:

✔ Time-sharing CPUs with intelligent scheduling
✔ Using advanced memory techniques (paging, sharing, ballooning)
✔ Multiplexing I/O efficiently
✔ Dynamically adjusting resources based on workload

👉 This allows massive consolidation (1000s of VMs) on a single IBM Z system while maintaining stability.