Ressourcenzuweisung: CPU, RAM, Storage, Netzwerk
Eine der wichtigsten Aufgaben in der Virtualisierung ist die sinnvolle Zuweisung von Ressourcen an VMs. Zu wenig Ressourcen: VM ist langsam und Benutzer beschweren sich. Zu viel: Ressourcen liegen brach und stehen anderen VMs nicht zur Verfügung. Die Kunst liegt im richtigen Gleichgewicht – und im Verstehen wie Übercommitment funktioniert.
Übercommitment (Overcommitment) ist ein Kernkonzept der Virtualisierung: Die Summe der zugewiesenen Ressourcen aller VMs kann größer sein als die physisch vorhandenen Ressourcen. Das funktioniert weil nicht alle VMs gleichzeitig ihre maximalen Ressourcen benötigen. Der Hypervisor verwaltet die tatsächliche Zuteilung dynamisch.
1) CPU, RAM, Storage und Netzwerk
Ressourcentypen – Tab wählen
🔲 CPU
💾 RAM
💿 Storage
🌐 Netzwerk
vCPU (Virtual CPU)
Jeder VM werden vCPUs zugewiesen. Der Hypervisor schedulet die vCPUs auf physische CPU-Kerne. Ein physischer Kern kann mehrere vCPUs bedienen – CPU-Overcommitment bis 4:1 üblich und unproblematisch.
⚠ Zu viele vCPUs für eine VM die sie nicht nutzt erzeugt Scheduling-Overhead (co-scheduling). Nur so viele vCPUs wie nötig.
CPU-Reservierung
Garantierte Mindest-CPU-Leistung (in MHz). Andere VMs können diese Kapazität nicht belegen. Für kritische VMs wie Datenbankserver sinnvoll. Unbelegte Reservierungen vergeuden Kapazität.
CPU-Limit
Maximale CPU-Nutzung einer VM (in MHz). VM kann nie mehr als das Limit nutzen – selbst wenn Kapazität frei ist. Sinnvoll um einzelne VMs zu drosseln die andere beeinflussen.
CPU-Shares/Priority
Relative Priorität bei CPU-Engpass. High=2000, Normal=1000, Low=500. Bei vollem Host bekommt „High"-VM doppelt so viel CPU wie „Normal". Kein absoluter Wert – nur bei Ressourcenknappheit relevant.
vCPU-Empfehlung: Für die meisten Dienste reichen 2-4 vCPUs. Datenbanken und rechenintensive Anwendungen 8-16. Niemals mehr vCPUs als physische Kerne (ohne guten Grund). CPU-Overcommitment 2:1 bis 4:1 ist normal.
RAM-Zuweisung
Feste RAM-Zuweisung: VM bekommt garantierten Speicher. Sicherste Option, aber keine Flexibilität. Dynamischer Speicher (Hyper-V) / Memory Ballooning (VMware): VM-RAM wird je nach Bedarf vergrößert oder verkleinert.
Memory Overcommitment
Summe der VM-RAM-Zuweisungen > physischer RAM. Hypervisor nutzt Techniken: Ballooning (VM gibt freien RAM zurück), Memory Sharing (identische Seiten zusammenlegen), Swap (selten genutzter RAM auf Disk auslagern).
✗ Disk-Swap für VM-RAM = massive Performance-Einbuße. Vermeiden!
RAM-Reservierung
Garantierter physischer RAM für diese VM – kein Ballooning, kein Swap. Für Echtzeit-Anwendungen, Datenbanken und kritische Dienste. Kostet physischen RAM „dauerhaft" – kann anderen VMs nicht gegeben werden.
NUMA-Awareness
Moderne Mehrprozessor-Server haben NUMA-Knoten (CPU + lokaler RAM). Hypervisor versucht VM-RAM auf dem NUMA-Knoten der vCPUs zu platzieren. Falsch konfiguriert → Remote-NUMA-Zugriffe → Performance-Einbußen.
Thick Provisioning
Gesamter angeforderter Speicher wird sofort auf dem Datastore reserviert. 100-GB-Disk: sofort 100 GB belegt. Predictable Performance, kein Kapazitätsproblem. Für Produktions-VMs und Datenbanken empfohlen.
Thin Provisioning
Disk wächst mit den Daten – 100-GB-Disk belegt anfangs nur 10 GB wenn die VM 10 GB nutzt. Spart Platz, ermöglicht höheres Storage-Overcommitment. Risiko: Datastore volllaufen wenn viele VMs gleichzeitig wachsen.
✗ Datastore-voll = alle VMs auf dem Datastore pausieren!
Storage I/O Control
Prioritätssteuerung für Disk-I/O. Verhindert dass eine VM durch intensive Disk-Aktivität andere VMs ausbremst (I/O-Starvation). Ähnlich wie CPU-Shares – aber für Storage-Throughput.
Disk-Controller-Typen
SCSI (LSI Logic, paravirtualisiert) für beste Performance. NVMe für maximale Speed. IDE veraltet (Kompatibilität). VirtIO unter KVM für beste Linux-Performance. Immer paravirtualisierte Treiber wo möglich.
Virtueller Switch (vSwitch)
Softwareimplementierung eines Netzwerk-Switches im Hypervisor. VMs verbinden sich mit dem vSwitch, dieser ist mit physischen Netzwerkkarten (Uplinks) verbunden. Standard vSwitch oder Distributed vSwitch (über mehrere Hosts).
VM-Netzwerkadapter-Typen
VMXNET3 (VMware) oder VirtIO-net (KVM): Paravirtualisierte Adapter, beste Performance. E1000/E1000e: Emulierter Intel-Adapter, breite Kompatibilität, weniger Performance. Immer paravirtualisiert wählen wenn Treiber vorhanden.
Netzwerk-Modi
Bridged (VM im gleichen Netzwerk wie Host), NAT (VM hinter Host-IP), Internal/Host-Only (nur VM-zu-VM oder VM-zu-Host). Für Produktions-VMs immer Bridged mit eigenem IP im Unternehmensnetz.
Bandwidth/QoS
Traffic Shaping: Begrenzt und garantiert Bandbreite für VMs. Average/Peak/Burst konfigurierbar. Verhindert dass eine VM die gesamte NIC-Kapazität beansprucht.
Sizing-Faustregel: Lieber konservativ anfangen und bei Bedarf skalieren als zu großzügig zu beginnen und Ressourcen zu verschwenden. Modernes Monitoring (vCenter, Grafana + Prometheus) zeigt die tatsächliche Auslastung und hilft beim Rightsizing.
Zusammenfassung
CPU: vCPUs, Overcommitment 2-4:1 OK, Reservierung für kritische VMs, nie mehr vCPUs als nötig. RAM: Thin vs. Thick (Ballooning), Reservierung für Datenbanken, RAM-Swap vermeiden. Storage: Thick Provisioning für Produktion, Thin spart Platz (Risiko: Datastore voll). Netzwerk: Paravirtualisierte Adapter (VMXNET3/VirtIO) für beste Performance, vSwitch als virtueller Netzwerkvermittler.