CPU-Virtualisierung

Was ist CPU-Virtualisierung?

Eine physische CPU kann nur eine Sache gleichzeitig tun – wie teilt man sie also fair auf mehrere VMs auf? Genau das ist die Aufgabe der CPU-Virtualisierung. Der Hypervisor verwaltet den Zugriff aller VMs auf die physischen CPU-Kerne und sorgt dafür dass jede VM das Gefühl hat eine eigene CPU zu besitzen – auch wenn sie sich diese in Wirklichkeit mit anderen teilt.

Physische CPU vs. vCPU

Eine vCPU (Virtual CPU) ist aus Sicht der VM ein vollwertiger CPU-Kern. In Wirklichkeit ist sie ein Zeitslot auf einem physischen Core – der Hypervisor verteilt die Rechenzeit des echten Kerns auf alle VMs die ihn nutzen.

Physischer Server: 1 CPU mit 8 Cores, Hyper-Threading → 16 Threads

Zuweisung:
VM 1 (Webserver):     2 vCPUs
VM 2 (Datenbank):     4 vCPUs
VM 3 (Mailserver):    2 vCPUs
VM 4 (Monitoring):    2 vCPUs
                     ──────────
Gesamt:              10 vCPUs auf 16 verfügbaren Threads → kein Overcommitment

CPU Overcommitment

Overcommitment bedeutet dass mehr vCPUs vergeben werden als physische Threads vorhanden sind. Das klingt problematisch – funktioniert in der Praxis aber oft gut, weil VMs selten alle gleichzeitig 100% CPU-Last haben.

Beispiel Overcommitment:
Physische Threads: 16

VM 1:  4 vCPUs
VM 2:  4 vCPUs
VM 3:  4 vCPUs
VM 4:  4 vCPUs
VM 5:  4 vCPUs
       ──────────
Total: 20 vCPUs auf 16 Threads → Overcommitment-Ratio 1,25:1

Typische Richtwerte:
- Verhältnis bis 2:1  → unkritisch
- Verhältnis bis 4:1  → akzeptabel bei gemischten Lasten
- Verhältnis über 4:1 → Vorsicht – Performance-Probleme möglich

Wann wird Overcommitment problematisch? Wenn mehrere VMs gleichzeitig Spitzenlast haben konkurrieren sie um die physischen Cores. Der Hypervisor muss dann priorisieren – VMs warten auf CPU-Zeit was zu CPU Ready führt: die VM ist rechenbereit aber bekommt keinen Core zugeteilt.

Hardware-Virtualisierungserweiterungen

Früher musste der Hypervisor jeden CPU-Befehl einer VM abfangen und übersetzen – das war langsam und aufwändig. Moderne CPUs haben deshalb spezielle Erweiterungen die Virtualisierung direkt in Hardware beschleunigen:

VT-x / AMD-V sind die Grundvoraussetzung für jeden modernen Hypervisor. Ohne diese Erweiterungen ist keine hardwarebeschleunigte Virtualisierung möglich. Im BIOS/UEFI müssen sie aktiviert sein – bei manchen Systemen sind sie standardmäßig deaktiviert.

BIOS-Einstellung prüfen:
Intel: "Intel Virtualization Technology" → Enabled
AMD:   "SVM Mode" oder "AMD-V" → Enabled

Linux – Prüfen ob VT-x/AMD-V aktiv ist:
grep -E 'vmx|svm' /proc/cpuinfo

vmx → Intel VT-x vorhanden
svm → AMD-V vorhanden

CPU-Ringmodell und Privilegien

Moderne CPUs kennen verschiedene Privilegierungsebenen (Ringe) die bestimmen welcher Code was darf:

Ring 0 – Kernel Mode:    Betriebssystem-Kernel (höchste Rechte)
Ring 1 – (selten genutzt)
Ring 2 – (selten genutzt)
Ring 3 – User Mode:      Anwendungen (eingeschränkte Rechte)

Das Problem bei der Virtualisierung: Der Guest-Kernel glaubt in Ring 0 zu laufen – darf es aber nicht wirklich, weil der Hypervisor Ring 0 belegt. Ohne Hardwareunterstützung musste der Hypervisor diese Befehle abfangen und emulieren (Binary Translation).

Mit VT-x/AMD-V gibt es einen neuen Ring-Modus (VMX Root / VMX Non-Root):

VMX Root Mode:     Hypervisor läuft hier (voller Zugriff)
VMX Non-Root Mode: Alle VMs laufen hier (eingeschränkt aber effizient)

→ VMs können privilegierte Befehle direkt ausführen
→ Bei kritischen Befehlen: VM-Exit → Hypervisor übernimmt → VM-Entry

PCIe-Durchleitung (Passthrough)

Mit VT-d / AMD-Vi (IOMMU) kann eine physische PCIe-Hardware direkt und exklusiv an eine VM durchgereicht werden – ohne Overhead durch den Hypervisor:

NUMA – Non-Uniform Memory Access

Bei Servern mit mehreren CPUs (Multi-Socket) ist nicht jeder RAM-Riegel gleich weit von jeder CPU entfernt. Dieses Konzept heißt NUMA:

Socket 0 (CPU 0)          Socket 1 (CPU 1)
├── Cores 0-7             ├── Cores 8-15
└── RAM Bank 0 (lokal)    └── RAM Bank 1 (lokal)
         ↕ (langsamer Zugriff über QPI/UPI)
         └── Zugriff auf fremden RAM möglich aber langsamer

Bei der VM-Konfiguration sollte darauf geachtet werden dass vCPUs und RAM einer VM aus dem gleichen NUMA-Knoten stammen – sonst entstehen Latenzen durch Remote-Speicherzugriffe.

CPU-Konfiguration in der Praxis

Beispiel: Proxmox VM-Konfiguration
Sockets: 1          → Anzahl simulierter CPU-Sockets
Cores:   4          → Cores pro Socket
vCPUs:   1 × 4 = 4  → Gesamt-vCPUs

Empfehlungen:
✓ CPU-Typ auf "host" setzen → VM bekommt echte CPU-Features
✓ NUMA-Topologie der Hardware nachbilden
✓ Overcommitment im Blick behalten (max. 4:1)
✗ Nie mehr vCPUs als physische Threads bei Hochlast-VMs

Zusammenfassung

• vCPUs sind virtuelle CPU-Kerne die der Hypervisor auf physische Threads verteilt

• Overcommitment bedeutet mehr vCPUs vergeben als physische Threads vorhanden sind

• Overcommitment bis 4:1 ist meist akzeptabel – bei gleichzeitiger Spitzenlast problematisch

• Intel VT-x und AMD-V sind Hardware-Erweiterungen die Virtualisierung beschleunigen

• Ohne VT-x/AMD-V ist keine moderne hardwarebeschleunigte Virtualisierung möglich

• VT-d/AMD-Vi (IOMMU) ermöglicht PCIe-Passthrough für native Hardware-Performance

• CPU Ready ist ein Zeichen für zu hohes Overcommitment

• NUMA-Topologie bei Multi-Socket-Systemen bei der VM-Planung berücksichtigen