vCPU-Überbuchung vs. dedizierte vCPU und RAM: was ein IaaS-Angebot garantiert und wie Sie es prüfen

Garantierte oder überbuchte vCPU und RAM im IaaS-Angebot

Garantierte vCPU und RAM in einem IaaS-Angebot bedeuten, dass die bestellte CPU-Kapazität und der bestellte Arbeitsspeicher für Ihre VMs vorgehalten werden und die Last anderer Mandanten sie Ihnen nicht nehmen kann. Überbuchung (Overcommitment) bedeutet, dass der Anbieter auf einem Host mehr vCPUs platziert, als dieser physische Kerne hat, oder mehr VM-Arbeitsspeicher, als der Host RAM hat, in der Erwartung, dass nicht alle VMs gleichzeitig ihre Spitze erreichen. Tritt das doch ein, teilt der Hypervisor die Kerne zwischen den wartenden vCPUs auf und holt sich Arbeitsspeicher von den VMs zurück, und die Last eines anderen Mandanten auf demselben Host, der Noisy Neighbour, bremst Ihre VMs.

Geteilte und dedizierte vCPU sind Begriffe aus Hosting-Angeboten; vSphere kennt keine Einstellung mit einem dieser Namen. Was Sie auf einer vSphere-Plattform erhalten, hängt vom Verhältnis von vCPU zu Kern auf den Hosts ab, von Reservierungen, Limits und Shares und davon, wie weit die Hosts Arbeitsspeicher zurückgewinnen müssen. Unser Vergleich von IaaS, Private Cloud und Hybrid zeigt, wann Hosts, die einer einzigen Organisation vorbehalten sind, besser passen, und unser Leitfaden zu vSphere as a Service in der EU, was ein gehosteter Dienst umfasst.

Unser IaaS bietet garantierte vCPU, RAM und Storage auf der vSphere-Plattform zu festen Monatskosten mit Abrechnung in Euro; CPU und RAM werden nicht mit anderen Kunden geteilt. Schicken Sie uns die VMs, die Sie umziehen würden, mit vCPU und RAM je VM.

vCPU-Überbuchung und das Verhältnis von vCPU zu Kern

Ist die CPU überbucht, teilt ein ESXi-Host, in der Dokumentation zu Version 9 ESX genannt, seine physischen Prozessoren in Zeitscheiben auf, sodass jede VM läuft, als hätte sie ihre konfigurierten vCPUs. Mit den Standardeinstellungen erhält jede VM je vCPU den gleichen Anteil an CPU (Broadcoms Dokumentation zu vSphere 8.0 und 9.1, Stand September 2026). Eine vCPU ist daher eingeplante Zeit auf einem physischen Prozessor und kein eigener Prozessor, und das Verhältnis von vCPU zu Kern, also die vCPUs der eingeschalteten VMs geteilt durch die physischen Kerne des Hosts, gibt an, wie viele vCPUs sich im Mittel einen Kern teilen.

Ein Broadcom-Dokument, das einen allgemeinen Zielwert für das Verhältnis festlegt, haben wir nicht gefunden. Laut Broadcoms Performance Best Practices for vSphere 9.0 (Revision 20250731) erlaubt ESX in den meisten Umgebungen erhebliches CPU-Overcommitment, ohne die Leistung der VMs zu beeinträchtigen, während ein Host mit gesättigter CPU einige oder alle seiner VMs erheblich verlangsamen kann. Für das Produkt GemFire empfiehlt Broadcoms KB 376609 einen physischen Kern je vCPU, um Steal Time zu verringern oder zu beseitigen. Wie Sie auf dem Host messen, ob ein Verhältnis zu hoch ist, beschreibt unser Leitfaden zu CPU Ready und dem Verhältnis von vCPU zu Kern.

Fragen Sie, ob der Anbieter physische Kerne oder Hyper-Threads zählt. Laut Broadcoms Dokumentation zu vSphere 8.0 kann eine Anwendung auf einem logischen Prozessor eines ausgelasteten Kerns „etwas mehr als die Hälfte des Durchsatzes“ erwarten, den sie allein auf einem Kern ohne Hyperthreading erreichen würde, und bei zwei Threads je Kern fällt ein gegen Threads gezähltes Verhältnis halb so hoch aus wie dieselbe Last, gegen Kerne gezählt. Bezeichnet ein Angebot eine vCPU als dediziert, fragen Sie, ob damit reservierte Kapazität gemeint ist, ein Host ohne andere Mandanten oder eine an einen Kern gebundene vCPU; Broadcom rät von manueller CPU-Affinität ab, die die Fähigkeit des Hosts beeinträchtigen kann, die Reservierungen und Shares einer VM einzuhalten.

RAM-Überbuchung: Page Sharing, Ballooning, Memory Compression, Swapping

Broadcoms Dokumentation zu vSphere 8.0 und 9.1 (September 2026) verwendet den Begriff auf zwei Arten. Ihr Beispiel bezeichnet einen Host mit 2 GB RAM und vier VMs mit je 1 GB als überbucht, wie es auch dieser Artikel tut, während ihre Definition die Überbuchung daran knüpft, dass der „kombinierte Arbeitsspeicher-Footprint“ der VMs den Arbeitsspeicher des Hosts übersteigt. Die Performance Best Practices for vSphere 9.0 beschreiben fünf Mechanismen, die den physischen Arbeitsspeicher verringern, den jede VM braucht: Page Sharing, Ballooning, Memory Compression, Swapping in einen Host-Cache und reguläres Swapping; die letzten vier kommen nacheinander zur Speicherrückgewinnung zum Einsatz, wenn der Arbeitsspeicher des Hosts knapp wird.

Transparent Page Sharing entfernt doppelte Speicherseiten, seit vSphere 6.0 und in Patches für einige ältere Versionen standardmäßig aber nur innerhalb jeder VM. Broadcoms KB 323624 erklärt, dass der Salt jeder VM standardmäßig ihre eindeutige vc.uuid ist; VMs teilen Seiten daher nur, wenn ein Administrator ihnen einen gemeinsamen Salt gibt oder die Host-Einstellung Mem.ShareForceSalting ändert. Die Dokumentation zu vSphere 8.0 und 9.1 führt Sicherheitsbedenken an. Die Best Practices für 9.0 ergänzen, dass ESX große Seiten (Large Pages) nicht teilt; mit großen Seiten beginnt das Sharing daher unter Umständen erst, wenn der Arbeitsspeicher so weit überbucht ist, dass ESX sie in kleine Seiten aufteilt.

Der Balloon-Treiber vmmemctl bringt das Gastbetriebssystem dazu, die Seiten freizugeben, die es für am wenigsten wertvoll hält, und sie bei Bedarf auf seine eigene virtuelle Festplatte auszulagern; wo Arbeitsspeicher überbucht ist, verlangt Broadcom daher einen Swap-Bereich im Gast, der mindestens so groß ist wie der konfigurierte Arbeitsspeicher der VM abzüglich ihrer Reservierung. Bevor der Host eine Seite auslagert, versucht er, sie zu komprimieren, und behält Seiten, die sich auf 2 KB oder weniger komprimieren lassen, in einem Cache im Arbeitsspeicher; Memory Compression ist standardmäßig aktiviert. Das Auslagern auf Host-Ebene, das Host-Swapping, geschieht dann ohne Zutun des Gastes. Die Best Practices für 9.0 raten davon ab, Arbeitsspeicher so weit zu überbuchen, dass Host-Swapping aktive Seiten auslagert, und halten fest, dass eine Reservierung des gesamten Arbeitsspeichers einer VM das Host-Swapping für diese VM ausschließt.

Die Dokumentation zu vSphere 9 beschreibt außerdem Memory Tiering over NVMe, das lokale NVMe-Geräte als langsamere Speicherschicht hinter dem DRAM nutzt. Die Funktion ist standardmäßig deaktiviert, und die Dokumentation zu vSphere 9.1 (29. September 2026) begrenzt die NVMe-Schicht standardmäßig auf die Größe des DRAM, bis zu 4 TB. Auf einem solchen Host können Reservierungen auf DRAM und NVMe aufgeteilt werden, wenn die reservierten VMs mehr Arbeitsspeicher verbrauchen, als der DRAM fasst; eine Reservierung allein bedeutet also nicht DRAM.

Reservierungen, Limits und Shares in vSphere

Eine Reservierung, in vSphere die Einstellung Reservation, ist die „garantierte Mindestzuteilung“ für eine VM, angegeben in MHz und MB. vCenter Server oder ESXi schaltet eine VM nur ein, wenn genügend nicht reservierte Kapazität ihre Reservierung deckt, und der Host hält diese Menge auch unter hoher Last verfügbar. Reservierte Kapazität, die eine VM nicht nutzt, steht anderen weiter zur Verfügung.

Ist der Arbeitsspeicher überbucht, erhält jede VM eine Menge zwischen ihrer Reservierung und ihrem Limit, bestimmt durch ihre Shares (Anteile) und ihr aktuelles Working Set; fest vorgehalten wird für sie also nur die Reservierung. Broadcoms Best Practices für 9.0 ergänzen, dass Reservierungen die Zahl der VMs verringern, die ein System betreiben kann.

Broadcom TechDocs: vSphere 8.0 Resource Management (aktualisiert vom 2. bis 16. September 2026) und vSphere 9.1 Resource Management (29. September 2026).

Laut Broadcom ist in den meisten Fällen kein Limit nötig, und esxtop zählt die Zeit, in der eine VM an ihrem CPU-Limit festgehalten wird, als Teil ihrer Ready-Zeit.

Ressourcenpools, Expandable Reservation und Admission Control

Ein Anbieter, der mehrere Mandanten auf einem Cluster betreibt, kann jedem einen Ressourcenpool geben, eine Partition der CPU und des Arbeitsspeichers des Clusters mit eigener Reservierung, eigenem Limit und eigenen Shares; laut Broadcom verhindert das, dass Änderungen der Zuteilung in einem Pool unbeteiligte Pools unfair beeinträchtigen. Eine Pool-Reservierung hält Kapazität für den Mandanten als Ganzes vor, nicht für eine einzelne VM, und die VMs darin konkurrieren über ihre Shares darum.

Beim standardmäßigen Reservierungstyp Expandable, der erweiterbaren Reservierung, prüft Admission Control den Pool und den übergeordneten Pool und kann rekursiv bei erweiterbaren übergeordneten Pools leihen, was laut Broadcom mehr Flexibilität ermöglicht, aber „weniger Schutz bietet“. Ein Pool vom Typ Fixed lässt eine VM nur aus seiner eigenen nicht reservierten Kapazität zu. Jedes Einschalten wird gegen die nicht reservierte Kapazität geprüft, Overhead-Arbeitsspeicher eingeschlossen, und reicht diese nicht aus, zeigt vSphere die Warnung Insufficient Resources an, statt die VM zu starten. vSphere HA Admission Control, eine eigene Cluster-Einstellung, die Kapazität für den Neustart von VMs nach einem Hostausfall vorhält, erklärt unser Leitfaden zur Host-Konsolidierung.

Steal Time: wie ein Mandant Konkurrenz in einer Linux-VM erkennt

Linux meldet CPU-Zeit, die der Hypervisor einem Gast entzieht, als Steal Time. Die Kernel-Dokumentation zu /proc/stat nennt sie „unfreiwilliges Warten“, und die procps-Werkzeuge top und vmstat zeigen sie als st an.

Für vSphere schreibt Broadcoms KB 376609, verfasst für das Produkt GemFire, dass die Meldung der Steal Time „nicht automatisch aktiviert“ ist, und nennt die VM-Option stealclock.enable = "TRUE". Solange der Anbieter diese Option nicht bestätigt, belegt eine Null in der Spalte st nicht, dass Ihre VMs nie gewartet haben. Dieselbe KB behandelt CPU Ready als den Namen, den vSphere für Steal Time verwendet; fragen Sie den Anbieter daher nach den Ready-Werten des Hosts.

Ballooning kann den Gast dazu bringen, auf seine eigene Festplatte auszulagern, was vmstat in den Spalten si und so zeigt, während Host-Swapping dort nicht erscheint. Broadcoms KB 438023 für ESXi 8.0 wertet Ballooning ungleich null als Speicherdruck auf dem Host und Host-Swapping als Konkurrenz, die in der Regel schwerwiegend genug ist, um die Leistung zu beeinträchtigen, und merkt an, dass ESXi das eigene Auslagern des Gastes nicht sehen kann. Wo der Host diese Statistiken bereitstellt, zeigt VMware Tools sie im Gast an: Laut dem Quellcode von VMwares open-vm-tools geben vmware-toolbox-cmd stat balloon und vmware-toolbox-cmd stat swap den per Ballooning zurückgeholten Arbeitsspeicher der VM und den vom Host ausgelagerten Arbeitsspeicher aus. Broadcoms KB 375842 verwendet vmware-toolbox-cmd stat memres und vmware-toolbox-cmd stat cpures, um die Arbeitsspeicher- und die CPU-Reservierung einer VM auszugeben. Eine Reservierung von null beweist keine Überbuchung, denn ein Anbieter kann freie Kapazität auch über die Dimensionierung seiner Hosts vorhalten.

Was Sie einen IaaS-Anbieter zu vCPU und RAM fragen sollten

Broadcom TechDocs zu vSphere 8.0 und 9.1 (August und September 2026); Performance Best Practices for VMware vSphere 9.0 (Revision 20250731); Broadcom KB 323624, 376609 und 438023; Quellcode von VMwares open-vm-tools; Dokumentation zum Linux-Kernel und zu procps-ng (Oktober 2026).

So prüfen Sie ein Angebot, bevor Sie unterschreiben:

1. Fragen Sie nach dem Verhältnis von vCPU zu Kern auf Ihren Hosts, gezählt gegen physische Kerne, und nach dem konfigurierten Arbeitsspeicher im Verhältnis zu ihrem RAM.
2. Fragen Sie, ob Reservierungen je VM oder je Pool Ihre vCPU und Ihren RAM vorhalten, wie viele MHz je vCPU sie abdecken, ob der Pool Fixed oder Expandable ist und ob Limits gelten.
3. Fragen Sie bei Hosts mit vSphere 9, ob Memory Tiering aktiv ist und ob der RAM des Angebots DRAM ist.
4. Fragen Sie, welche Werte zur Konkurrenz Sie sehen werden, etwa Ready-Zeit je vCPU sowie per Ballooning zurückgeholten und ausgelagerten Arbeitsspeicher je VM, in welchem Intervall, ob stealclock gesetzt ist und ob die Statistiken von VMware Tools den Gast erreichen.
5. Prüfen Sie im Service Level Agreement, ob es nur die Verfügbarkeit abdeckt oder auch die Zuteilung von CPU und Arbeitsspeicher, und wie eine Unterschreitung gemessen wird.
6. Betreiben Sie vor der Migration ein repräsentatives System unter Spitzenlast auf der Plattform und vergleichen Sie Steal Time, wo sie gemeldet wird, das Auslagern im Gast und die Antwortzeiten mit Ihrer heutigen Plattform.

Kapazität wird je VM bestellt, daher behält eine überdimensionierte VM ihre überzähligen vCPUs und ihren überzähligen RAM auch nach dem Umzug; wie Sie solche VMs finden, zeigt unser Leitfaden zur Verschwendung in vSphere-Umgebungen.

Vor der Migration stellen wir einen Testzugang zur Plattform bereit. Nennen Sie uns die Systeme, die Sie zuerst testen würden, und die Kennzahlen, die Sie heute vergleichen.

Was wir tun

Im Rahmen unserer EU-Cloud hosten wir garantierte Rechenleistung oder eine Private Cloud in Baltnetas Tier-3-Rechenzentren in Litauen, und Daten und Backups bleiben in der EU. Die Option IaaS läuft auf der VMware-vSphere-Plattform mit Self-Service-Portal, Snapshots und Veeam-Backup; CPU und RAM sind garantiert, nicht mit anderen Kunden geteilt. Eine Konfiguration mit garantierten Ressourcen hat feste Monatskosten mit Abrechnung in Euro, die sich nur ändern, wenn Sie selbst die Konfiguration ändern. Unser Engineering-Partner Vixen.UNO zieht Systeme Schritt für Schritt um, in vereinbarten Wartungsfenstern mit Rollback-Plan, und der Support läuft unter SLA. Das erste Gespräch ist kostenlos; der Preis des technischen Assessments steht vor Beginn fest.

FAQ