VCF Operations Rightsizing: überdimensionierte VMs, Rückgewinnung und was Sie vor einer Größenänderung prüfen

So funktioniert das Rightsizing in VCF Operations

VCF Operations Rightsizing vergleicht den prognostizierten Bedarf jeder VM mit ihrer Zuweisung und listet die VMs, die bei CPU oder Arbeitsspeicher überdimensioniert oder unterdimensioniert sind, jeweils mit einer vorgeschlagenen Größe für vCPU und Arbeitsspeicher. Eine zweite Ansicht, Reclaim, dient der Rückgewinnung: Sie listet Kapazität, die Sie zurückholen können, ohne etwas zu verkleinern, nämlich ungenutzte VMs, ausgeschaltete VMs, Snapshots und verwaiste Datenträger. In VCF Operations 9.1 öffnen Sie beide über Manage in der oberen Leiste, dann Capacity und Optimize im linken Bereich; klicken Sie auf ein Rechenzentrum und wählen Sie den Tab Rightsize oder Reclaim.

VCF Operations ist der Name des Produkts in 9.x, das zuvor Aria Operations und vRealize Operations (vROps) hieß. Dieser Leitfaden folgt den TechDocs-Seiten zu 9.1, aktualisiert zwischen dem 21. September und dem 15. Oktober 2026. Broadcoms Funktionsvergleich für VCF und VVF 9.1.1 vom 14. Oktober 2026 kennzeichnet Kostenmanagement mit Rückgewinnung für vSphere Foundation, VCF Edge und VCF. Seine Zeile für prädiktives Kapazitätsmanagement, einschließlich Rightsizing, trägt zwei Markierungen, ebenso die Zeile für Lifecycle-Management, das VVF-Kunden laut Tabelle mit vLCM abdecken. Lassen Sie sich unter vSphere Foundation den Lizenzanspruch schriftlich bestätigen.

Welche VMs Kapazität verschwenden und warum Snapshots zuerst kommen, steht in unserem Leitfaden dazu, wo in einer vSphere-Umgebung die Verschwendung sitzt.

Wie die Kapazitäts-Engine eine Empfehlung berechnet

Laut Broadcoms Seite zur Berechnung und Prognose der Kapazität, aktualisiert am 15. Oktober 2026, „erfasst die Engine alle fünf Minuten Datenpunkte und verarbeitet sie einmal in 24 Stunden, um Ausgabemetriken zu berechnen“. Standardmäßig arbeitet sie mit dem Bedarfsmodell; das Zuweisungsmodell mit seinen Overcommitment-Verhältnissen gilt nur, wenn Sie es in der Richtlinie einschalten. Die Prognose ist ein Bereich, der nach Broadcoms Worten „90 % der künftigen Datenpunkte abdeckt“.

Die Engine behandelt Spitzen auf drei Arten. Eine kurzzeitige Spitze ist ein einmaliges Ereignis und ändert die Prognose nicht. Eine anhaltende Spitze ändert sie, und ihr Gewicht nimmt mit der Zeit ab, sofern sie nicht wiederkehrt. Eine periodische Spitze, etwa eine tägliche Sicherung oder ein Lauf zum Monatsende, nimmt nicht ab und hat das größte Gewicht. Sie können den Beginn der Historie verschieben oder bis zu sechs Zeiträume ausschließen, etwa eine Migration, die die Daten verzerrt hat.

Die empfohlene Größe ist „die maximale prognostizierte Auslastung für den Zeitraum von jetzt bis 30 Tage über den Warnschwellenwert für die verbleibende Zeit hinaus“. Beim Standard-Warnschwellenwert von 120 Tagen ist das die höchste prognostizierte Auslastung der nächsten 150 Tage. Die Risikostufe der Richtlinie entscheidet, welcher Rand des Bereichs zählt. Conservative nutzt die obere Grenze, und die Seite zur Richtlinie empfiehlt diese Stufe „für Produktions- und geschäftskritische Workloads“ und „für VMs mit Auslastungsspitzen“. Aggressive nutzt den Mittelwert aus oberer und unterer Grenze und ist für unkritische Workloads gedacht. Die Stufe ist ein Schieberegler auf der Karte Capacity der Richtlinie, unter Operate, Administration, Configurations und der Kachel Policy Definition.

Zwei Grenzen beschränken jede Empfehlung. „VCF Operations begrenzt eine überdimensionierte empfohlene Größe auf 50 % der aktuell zugewiesenen Ressourcen“, eine Verkleinerung nimmt also höchstens die Hälfte weg, und eine unterdimensionierte auf 100 %, eine Vergrößerung fügt also höchstens die aktuelle Zuweisung hinzu. Eine VM mit 16 vCPU, deren Spitze bei drei liegt, erhält daher eine Empfehlung von nicht weniger als 8 vCPU und erreicht ihre richtige Größe über mehrere Runden. VMwares VCF-Blog riet am 12. August 2025, „6 Monate (oder mehr) an historischen Daten“ zu prüfen, bevor man sich auf die Prognosen verlässt.

Was die Tabs Rightsize und Reclaim zeigen

Der Tab Rightsize hat zwei Listen, Oversized VMs und Undersized VMs, nach Cluster gruppiert, mit der vorgeschlagenen Änderung in vCPU und GB Arbeitsspeicher. Wenn Sie eine VM aufklappen, sehen Sie ihren Auslastungsverlauf über einen bis 12 Monate, die Prognose und die Empfehlung. Beide Listen enthalten ungenutzte VMs und VMs mit Snapshots, eine VM kann also zugleich in Rightsize und in Reclaim erscheinen. Der Tab Reclaim ordnet seine Kandidaten in vier Kategorien.

Broadcom TechDocs, VCF Operations 9.1: Calculating and Forecasting Capacity (15. Oktober 2026), Using Rightsize to Adjust Resource Allocation und Using Reclaim to Free Up Resources (15. Oktober 2026); Broadcom KB 438023 und KB 445643.

Broadcoms KB 445643, geschrieben für Aria Operations, definiert eine ungenutzte VM als eine, deren „CPU-Verbrauch in jedem 24-Stunden-Zeitraum während 100 % der Zeit unter 100 MHz liegt“, und sagt über die vCLS-VMs, die DRS und HA brauchen: „Gewinnen Sie diese VMs nicht zurück und löschen Sie sie nicht“. In 9.1 öffnen sich die Reclamation Settings über das Zahnradsymbol neben der Seitenüberschrift und gelten für alle Rechenzentren; altersbasierte Ausschlüsse finden Sie unter Operate, Administration, Global Settings.

Die Bereiche Total Reclaimable Capacity und How much you can potentially save rechnen die Listen in Kapazität und Kosten um. Die Kosten stammen aus den Kostentreibern, deren Referenzkosten laut Broadcom „möglicherweise nicht zutreffen“, bis Sie Ihre eigenen eintragen; wie Sie diese setzen, steht in unserem Leitfaden zu VMware-Kosten pro VM und Showback.

Was Sie prüfen, bevor Sie eine Empfehlung anwenden

Diese Prüfungen erfassen Fälle, in denen eine korrekte Bedarfsprognose trotzdem eine falsche Größe ergibt.

Broadcom KB 438023 (Leitfaden zum Rightsizing unter ESXi 8.0) und KB 321931 (vNUMA und vCPU-Hotplug, ESXi 7.x und 8.x); die übrigen Zeilen sind unsere Checkliste.

Beim Arbeitsspeicher vergleicht KB 438023 aktiven und verbrauchten Arbeitsspeicher mit der Zuweisung: „Ein dauerhaft niedriges Verhältnis von aktivem zu zugewiesenem Arbeitsspeicher deutet auf Überdimensionierung hin.“ Ballooning ungleich null bedeutet, dass der Host sich Arbeitsspeicher vom Gast zurückgeholt hat, und „aktives Paging im Gast deutet darauf hin, dass die VM selbst für ihren Workload unterdimensioniert ist“. Eine Kürzung des Arbeitsspeichers auf einem Host, der bereits Ballooning oder Swapping betreibt, verschärft den Druck, wie unser Leitfaden zu Arbeitsspeicher-Overcommitment, Ballooning und Swapping in vSphere erklärt.

Auf der CPU-Seite wertet KB 438023 Co-Stop unter etwa 3 % je vCPU als normal und liest anhaltend höhere Werte als mehr vCPUs, als die VM nutzen kann. Der Artikel warnt außerdem: „Anhaltend hohe Ready-Zeit signalisiert in der Regel CPU-Konkurrenz auf Host-Ebene statt einer Unterdimensionierung der einzelnen VM.“ Bei einer unterdimensionierten VM mit hoher Ready-Zeit lesen Sie Ready und Co-Stop je vCPU, wie unser Leitfaden zu CPU Ready beschreibt.

KB 321931 schreibt, dass CPU Hot Add vNUMA auf virtueller Hardwareversion 19 oder älter deaktiviert, und rät, es in Vorlagen für Produktions-VMs zu deaktivieren, „sofern die Größenänderung im laufenden Betrieb keine streng validierte betriebliche Anforderung ist“; KB 438023 ergänzt, dass vNUMA ab Hardwareversion 20 unter ESXi 8.0 bei aktiviertem CPU Hot Add erhalten bleibt. VMwares VCF-Blog vom 12. August 2025 beschreibt eine Größenänderung „mit aktiviertem Hot-Add, ohne Neustart“, doch Hot Add vergrößert eine VM nur, und KB 438023 hält fest, dass Änderungen an der Zahl der vCPUs, an der Speichergröße oder an der CPU-Topologie eine ausgeschaltete VM voraussetzen. Planen Sie jede Größenänderung für ein Wartungsfenster.

Im Rahmen der VMware-Optimierung prüft unser Engineering-Partner Vixen.UNO die tatsächliche Ressourcennutzung der Umgebung und nimmt Änderungen in vereinbarten Wartungsfenstern mit Rollback-Plan vor. Schicken Sie uns den Rightsize-Export für einen Cluster und die geschäftlichen Spitzen, die er womöglich nicht zeigt.

Rightsizing in Wartungsfenstern umsetzen

Für eine Größenänderung aus VCF Operations heraus braucht es vorab eine Einstellung: „Operational Actions müssen in der Instanz des vCenter-Cloud-Adapters aktiviert sein.“ Der Arbeitsbereich Resize VM(s) schlägt für jede ausgewählte VM die Änderung an vCPU und Arbeitsspeicher vor, und Sie können jeden Wert vor der Ausführung bearbeiten. Broadcom lässt Sie per Kontrollkästchen bestätigen, dass „einige Arbeiten unterbrochen werden können, da Workloads für die Größenänderung neu starten müssen“. Schedule Action führt dieselbe Änderung später aus, als Job, der in Automation Central verwaltet wird.

1. Exportieren Sie die Listen mit Export All und notieren Sie die aktuellen vCPU- und Arbeitsspeicherwerte jeder VM; diese Werte sind Ihr Rollback.
2. Schicken Sie jedem Eigentümer Verlauf und Empfehlung seiner VMs und schließen Sie die VMs aus, die er ablehnt, mit Tags, wo eine ganze Anwendung betroffen ist.
3. Gruppieren Sie die freigegebenen Änderungen nach Wartungsfenster und ändern Sie je VM und Fenster nur eine Dimension, CPU oder Arbeitsspeicher, damit eine Beschwerde auf eine einzige Änderung zeigt.
4. Führen Sie die Größenänderung im Arbeitsbereich Resize VM(s) aus oder planen Sie sie mit Schedule Action für das Fenster ein.
5. Prüfen Sie nach dem Neustart die Anwendung, danach Ready und Co-Stop je vCPU und das Paging im Gast über die nächste geschäftliche Spitze.
6. Verschlechtert sich die Anwendung, stellen Sie die notierten Werte in einem vereinbarten Fenster wieder her und schließen Sie die VM aus, bis der Eigentümer sie geprüft hat.
7. Lassen Sie VCF Operations einen vollen Geschäftszyklus erfassen, bevor die nächste Runde beginnt, da eine Empfehlung höchstens die Hälfte der Zuweisung entfernt.

Zu verwaisten Datenträgern schreibt Broadcoms Seite zu 9.1: „Verwaiste Datenträger können Sie nicht über die Benutzeroberfläche zurückgewinnen“. Exportieren Sie die Liste, prüfen Sie jedes gemeldete VMDK und entfernen Sie die bestätigten von Hand. Ungenutzte und ausgeschaltete VMs gehen zuerst an ihre Eigentümer; ungenutzte VMs werden danach ausgeschaltet, und beide werden vor dem Löschen eine Aufbewahrungsfrist lang behalten.

Rechenbeispiel: ein Cluster mit 30 Hosts und 1.200 VMs

Die Zahlen dienen der Veranschaulichung und sind kein Kundenfall. Ein Cluster mit 30 Hosts, jeder mit zwei CPUs zu 32 Kernen und 1.024 GB Arbeitsspeicher, ergibt 1.920 Kerne und 30.720 GB. Er betreibt 1.200 VMs, denen 6.000 vCPU und 26.400 GB zugewiesen sind, etwa 3,1 vCPU je Kern. Die Richtlinie nutzt die Risikostufe Conservative und sechs Monate Historie.

Beispielwerte; Obergrenzen und Risikostufe wie auf Broadcoms Seite Calculating and Forecasting Capacity zu VCF Operations 9.1 (15. Oktober 2026).

Die vorgeschlagenen Änderungen bleiben innerhalb beider Obergrenzen. Nach einer Runde sind im Cluster 4.930 vCPU zugewiesen, etwa 2,6 je Kern, und 22.940 GB. Broadcom merkt an, dass die empfohlene Größe „die Kapazität nicht enthält, die vSphere HA für Failover reserviert“. Ob der Cluster nun weniger Hosts braucht, hängt vom gemessenen Bedarf bei einem ausgefallenen Host ab, von HA Admission Control und unter vSAN vom Host-Minimum der Speicherrichtlinie; die Zuweisungswerte sind also eine Eingabe für die Host-Konsolidierung bei Lizenzierung pro Kern und nicht ihr Ergebnis.

Angepasste und zurückgewonnene Kapazität berichten

Ein Bericht, den Eigentümer und Finanzabteilung akzeptieren, zeigt jeden Cluster vorher und nachher: zugewiesene vCPU und GB, geänderte VMs, ausgeschlossene VMs mit Grund sowie Speicher, der aus Snapshots, verwaisten Datenträgern und stillgelegten VMs zurückgewonnen wurde. Berichten Sie Zuweisung und gemessenen Bedarf nebeneinander, denn die Zahl der Hosts folgt dem Bedarf.

Showback-Sätze je vCPU und je GB auf Basis der Zuweisung lasten die Kosten einer überdimensionierten VM ihrem Eigentümer an, was Eigentümern einen Grund gibt, die Empfehlung zu akzeptieren.

Die Ergebnisse des Rightsizing fließen in das kostenpflichtige technische Assessment unserer VMware-Optimierung ein, das einen Bericht, ein TCO- und ROI-Modell und einen Maßnahmenplan vor dem Renewal liefert. Beschreiben Sie Ihre Cluster, die Zahl der VMs und Ihren Verlängerungstermin im Formular unten.

Was wir tun

Unsere VMware-Optimierung beginnt mit einem Audit von Umgebung und Lizenzen: Versionen, Abonnements, tatsächliche Ressourcennutzung, Risikoprofil und TCO, mit Handlungsoptionen. Die Lizenz- und Kostenoptimierung stimmt Editionen und Abonnements auf Ihre realen Workloads ab und umfasst Host- und Cluster-Konsolidierung, wo die richtig dimensionierte Umgebung sie zulässt. Das Engineering liefert unser Engineering-Partner Vixen.UNO, der alle Änderungen in vereinbarten Wartungsfenstern mit einem Rollback-Plan für jede Etappe vornimmt und Support unter einem vereinbarten SLA leistet. Gibt es nichts zu optimieren, sagen wir das. Das erste Gespräch ist kostenlos; der Preis des technischen Assessments steht vor Beginn fest.

FAQ