VMware-Kosten pro VM: ein Showback-Modell für vSphere nach Broadcom aufbauen

Wie Sie die VMware-Kosten pro VM berechnen

Die VMware-Kosten pro VM sind die jährlichen Plattformkosten, verteilt auf das, was jede VM belegt. Um die Kosten einer virtuellen Maschine unter VMware zu berechnen, addieren Sie die jährlichen Kosten der Plattform, teilen sie durch die Kapazität, die Sie in einer Verrechnungseinheit vergeben können, und multiplizieren den so ermittelten Satz mit dem, was jede VM zugewiesen hat oder nutzt. Zu den Plattformkosten gehören das VVF- oder VCF-Abonnement auf den lizenzierten Kernen, der Support, wo er eine eigene Position ist, die Abschreibung der Hardware, Speicher, Netzwerk, Strom und Fläche sowie der Betriebsaufwand des Teams, das die Plattform betreibt. Die Verrechnungseinheit ist eine vCPU, ein GB Arbeitsspeicher oder der gemessene Bedarf in GHz und GB.

Showback weist diesen Wert Abteilungen und Anwendungsverantwortlichen aus, ohne interne Budgets zu verschieben; Chargeback, die interne Kostenverrechnung, stellt ihn in Rechnung. Dieser Artikel rechnet die Methode in Einheiten und Platzhaltern durch, da die Sätze Ihre eigenen sind.

Kostenkategorien, Kostentreiber und Datenquellen

Erfassen Sie die Kategorien je Cluster, denn Cluster unterscheiden sich in Hardwaregeneration, Speicherstufe und Lizenzstufe, und auch VCF Operations berechnet seine Basissätze je Cluster.

Kategorien nach den Kostentreibern in Broadcoms Dokumentation zu VCF Operations 9.1 (Overview of Cost Drivers, aktualisiert am 21. September 2026), die Zeilen zu vSAN und Backup von uns ergänzt; Kernregel aus Broadcoms KB 313548.

Halten Sie direkte Kosten vom gemeinsamen Pool getrennt. Eine Lizenz für ein Gastbetriebssystem oder eine Backup-Position, die zu einer VM gehört, wird dieser VM zugeordnet und nicht auf den Cluster verteilt; VCF Operations behandelt Arbeitskosten für Betriebssysteme, Arbeitskosten für VMs und bestimmte Desktop-Lizenzen ebenso und zieht sie von den Compute-Kosten ab, bevor es die Basissätze berechnet. Auch Speicher wird getrennt bepreist, je GB und je Stufe, damit eine VM auf einem schnellen Datastore nicht den Satz einer VM auf Kapazitätsplatten erhöht.

Warum Abonnements pro Kern das Ergebnis verändern

Mit Dauerlizenzen konnte ein Kostenmodell den Hypervisor weglassen, sobald die Lizenz bezahlt war, weil nur der Support wiederkehrend anfiel. Seit VVF und VCF Abonnements sind, ist die Lizenz wieder ein jährlicher Kostenblock. Laut Broadcoms KB 313548 „basiert die Kernlizenzierung von VCF und VVF auf der Gesamtzahl der physischen CPU-Kerne aller ESXi-Hosts, die Sie lizenzieren wollen“, mit mindestens 16 Kernen je CPU, auch wenn eine CPU weniger hat. Derselbe Artikel verlangt „Kernlizenzen für alle physischen CPU-Kerne auf jeder CPU, auf der die Software läuft“, und bittet darum, für den Lauf seines Zählskripts alle Kerne zu aktivieren, da deaktivierte Kerne das Ergebnis ungenau machen können.

Die Lizenz ist ein Kostenfaktor des Hosts. Ein Host mit zwei 24-Kern-CPUs trägt 48 lizenzierte Kerne, ob er 20 VMs betreibt oder 60; der Lizenzanteil je vCPU sinkt also mit steigender Konsolidierungsrate und steigt, wenn ein Cluster ungenutzte Reserve vorhält. Hosts mit CPUs mit wenigen Kernen tragen aufgerundete Kerne, die sie nicht haben, und diese Aufrundung landet im Satz jeder VM. Wie gezählt wird und was das für kleine Cluster bedeutet, steht in unserem Leitfaden zur VMware-Lizenzierung nach Broadcom; welche Stufe die Umgebung braucht, behandelt unser Leitfaden zur Verlängerung mit Standard, VVF oder VCF.

Die Verrechnungseinheit wählen

Die Einheit entscheidet, wer für freie Kapazität bezahlt und wie oft sich der Wert einer Abteilung ändert. Das Modell in diesem Artikel nutzt zwei Einheiten zugleich, vCPU und GB Arbeitsspeicher, und teilt den Compute-Pool über ein Verhältnis zwischen beiden auf. VCF Operations macht dasselbe mit einem Cluster-Kostenverhältnis zwischen CPU und Arbeitsspeicher, das in den Kosteneinstellungen für beide jeweils auf einen Wert von 1 bis 10 gesetzt wird.

Unser Vergleich; Verhalten bei Bedarfsverrechnung nach Broadcoms Seite zu VCF Operations 9.1 Editing Cluster Cost Calculation Methods, aktualisiert am 5. Oktober 2026.

Sätze auf Basis der Zuweisung lasten die Kosten einer VM mit 16 GB ihrem Eigentümer an, auch wenn sie 4 GB nutzt, was Eigentümern einen Grund gibt, eine richtige Dimensionierung zu akzeptieren. An dieser Stelle stützen sich Showback und die Bereinigung aus unserem Leitfaden zur Verschwendung in vSphere-Umgebungen gegenseitig. Bedarfsbasierte Sätze folgen der Nutzung, sind aber schwerer zu planen, da sich der Wert einer Abteilung ändert, wenn andere VMs ruhiger werden.

Kosten und Showback in VCF Operations 9.1

VCF Operations berechnet Kosten aus Kostentreibern. Broadcoms Dokumentation zu 9.1 nennt Server-Hardware (traditionell und hyperkonvergent), Speicher, Lizenz, Wartung, Arbeitskosten, Netzwerk, Rechenzentrum und zusätzliche Kosten, dazu Anwendungskosten. Broadcom schreibt, dass die Referenzkosten, die VCF Operations einträgt, „möglicherweise nicht zutreffen“. Server-Hardware wird je Server als gekauft oder geleast erfasst, mit Kaufdatum und Anschaffungskosten je Server. Für ESX 8.0 und später wird der Lizenztreiber je Kern berechnet, und laut Dokumentation werden die gesamten Lizenzkosten auf alle Hosts im Rechenzentrum verteilt, wobei die Option Customize License Assignment die Kosten je Host ändert. Prüfen Sie diese Aufteilung, wenn sich die Hosts in der Kernzahl unterscheiden. Speicher wird als monatliche Kosten je GB und Datastore erfasst, nach Storage-Tag und Typ.

Basissätze werden je Cluster berechnet. Die Basissätze für CPU und Arbeitsspeicher teilen die CPU- und Arbeitsspeicherkosten des Clusters durch die Kapazität, anteilig nach der erwarteten Auslastung. Zwei Methoden für die Clusterkosten sind dokumentiert. Bei Cluster Usable Capacity After HA and Buffer ergeben sich die Basissätze aus den Gesamtkosten des Clusters und seiner nutzbaren Kapazität nach HA und Puffer. Sie ändern sich nicht mit der Auslastung, und die Differenz zwischen nutzbarer Kapazität und Nutzung wird als nicht zugeordnete Kosten berechnet. Bei Cluster Actual Utilization folgen die Sätze der durchschnittlichen Auslastung seit Monatsbeginn, die nicht zugeordneten Kosten bleiben nahe null, und Broadcom merkt an: „Basissätze und Kosten virtueller Maschinen können sich je nach Auslastung des Clusters häufig ändern.“ Bei einem Zuweisungsmodell sind die Kosten einer VM die zugewiesenen vCPU mal dem vCPU-Basissatz des Clusters, plus der zugewiesene vRAM mal dem Basissatz für Arbeitsspeicher, plus Speicher und direkte Kosten, und das Overcommitment-Verhältnis lässt sich je Cluster festlegen.

Die Kosteneinstellungen enthalten außerdem die Abschreibung der Server-Hardware für alle vCenter-Instanzen, mit zwei Modellen, „Straight line“ und „Max of Double or Straight“. Broadcoms Seite Cost Settings zu 9.1 nennt zwei Bereiche für den Zeitraum. Ihre Anleitung unter Cost Settings for Financial Accounting Model fordert dazu auf, „die Depreciation Years zwischen zwei und sieben auszuwählen“, während ihr Abschnitt Configuring Depreciation Preferences festhält: „Sie können den Abschreibungszeitraum auf zwei bis fünf Jahre festlegen“. Prüfen Sie, welchen Bereich das Feld in Ihrer Installation akzeptiert. Für Showback machen Preiskarten aus Kosten einen Preis je VM.

1. Ersetzen Sie die Referenzkosten in jedem Kostentreiber durch Ihre eigenen Werte.
2. Wählen Sie die Methode für die Clusterkosten unter Administration, Configurations, Cluster Cost und setzen Sie für die tatsächliche Auslastung den Cluster Utilization Ceiling Factor unter Global Settings, Cost/Price.
3. Legen Sie das Cluster-Kostenverhältnis zwischen CPU und Arbeitsspeicher sowie Abschreibungszeitraum und Abschreibungsmodell fest und starten Sie dann die Kostenberechnung.
4. Erstellen Sie eine Preiskarte unter Policy Definitions, VC Pricing: kostenbasiert (Kosten mal Faktor) oder satzbasiert (ein Satz je vCPU, je GB Arbeitsspeicher und je GB Speicher), mit einem Abrechnungszeitraum von stündlich bis monatlich.
5. Legen Sie fest, ob VMs „Always“ oder „Only When Powered On“ berechnet werden, und ergänzen Sie, wo zutreffend, Sätze für Gastbetriebssysteme, Tag-basierte Gebühren und Einrichtungsgebühren.
6. Weisen Sie die Karte vCenter-Instanzen oder Clustern zu; die Preise werden alle 24 Stunden neu berechnet.

Cost Analysis vergleicht anschließend Kosten- und Preismetriken über benutzerdefinierte Gruppen hinweg; mit eigenen Gruppen für jede Abteilung oder Anwendung entsteht so die Showback-Sicht.

Rechenbeispiel: 24 Hosts in drei Clustern

Die folgenden Werte beschreiben eine Beispielumgebung für ein Unternehmen mit etwa 1.500 Beschäftigten, mit Platzhaltern für jeden Satz. S ist das jährliche Abonnement je lizenziertem Kern, H die Anschaffungskosten je Host, F die Rechenzentrumskosten je Host und Jahr, N der Netzwerkanteil je Host und Jahr und E der jährliche Betriebsaufwand des Teams.

Beispielwerte, keine Empfehlung; HA-Abzug wie in Broadcoms Methoden für die Clusterkosten in VCF Operations 9.1, vCPU-Zahl als Kerne mal Overcommitment-Verhältnis wie auf Broadcoms Seite zum Zuweisungsmodell (8. Oktober 2026); Kernregel aus KB 313548.

Das Verhältnis von 4 vCPU je Kern ist ein Beispiel; prüfen Sie Ihren eigenen Wert anhand von CPU Ready je vCPU, wie unser Leitfaden zu CPU Ready erklärt. Der jährliche Compute-Pool ist C = 1.152 × S + 24 × H ÷ 5 + 24 × (F + N) + E, wobei die Hardware linear über fünf Jahre abgeschrieben wird, was beide Abschreibungsbereiche zulassen. Speicher und Backup bleiben außerhalb von C und erhalten einen eigenen Satz je GB und Stufe. Das Beispiel nimmt eine Aufteilung von 40 zu 60 zwischen CPU und Arbeitsspeicher an, eine Richtlinienentscheidung innerhalb des Bereichs von 1 bis 10, den VCF Operations für beide akzeptiert. Der monatliche Satz je vCPU ist dann 0,4 × C ÷ 12 ÷ 4.032 und der monatliche Satz je GB 0,6 × C ÷ 12 ÷ 19.354. Eine VM mit 4 vCPU, 16 GB und 200 GB auf der ersten Speicherstufe weist das Vierfache des vCPU-Satzes aus, das 16-Fache des GB-Satzes und das 200-Fache des Speichersatzes dieser Stufe, dazu ihre direkten Kosten wie eine Lizenz für das Gastbetriebssystem.

C deckt alle 24 Hosts ab, während die Sätze durch die nutzbare Kapazität teilen; der HA-Host und der Arbeitsspeicherpuffer stecken also bereits in den Sätzen. Die zugewiesenen 3.300 vCPU und 15.800 GB belegen etwa 82 % dessen, was die Cluster vergeben können. Für die übrige Kapazität wird keiner VM etwas berechnet; weisen Sie ihre Kosten daher als eigene IT-Position aus, statt den Satz jeder VM anzuheben, um sie aufzufangen.

Unser technisches Assessment einer VMware-Umgebung endet mit einem Bericht, einem TCO- und ROI-Modell und einem Maßnahmenplan vor dem Renewal. Schicken Sie uns Ihre Hostliste, den Aufbau der Cluster und Ihr Verlängerungsdatum über das Formular unten.

Ein Horizont von drei bis fünf Jahren und Entscheidungen zur Verlängerung

Erstellen Sie das Modell über drei bis fünf Jahre, mit der Abonnementlaufzeit aus Ihrem Angebot, der Abschreibung jeder Hostbeschaffung und der Bedarfsprognose aus unserem Leitfaden zur Kapazitätsplanung für vSphere. Jedes Jahr hat dann sein eigenes C, seine eigene Zahl lizenzierter Kerne und seine eigene Kapazität.

Dieselben Sätze beantworten die Fragen zur Verlängerung. Ein Stufenwechsel verändert S, eine Erneuerung der Hosts verändert H, die Kernzahl und die Kapazität, und eine Host-Konsolidierung bei Lizenzierung pro Kern verändert die Zahl der lizenzierten Kerne. Wird ein gehostetes Angebot je vCPU, GB und Speicherstufe bepreist, stehen die Sätze des Modells in denselben Einheiten daneben; was ein gehostetes VMware-IaaS umfasst, behandelt unser Leitfaden zu vSphere as a Service in der EU.

Unser Infrastruktur-Audit vergleicht Szenarien zu Modernisierung, Cloud und Hybrid über einen Horizont von 3 bis 5 Jahren. Beschreiben Sie die Szenarien, die Sie vor der Verlängerung abwägen, im Formular unten, mit der Zahl der Hosts und der Laufzeit aus Ihrem Angebot.

Was wir tun

Unsere VMware-Optimierung umfasst ein Audit von Umgebung und Lizenzen: Versionen, Abonnements, tatsächliche Ressourcennutzung, Risikoprofil und TCO, mit einer unabhängigen Reifegradbewertung und Handlungsoptionen. Es zeigt, wofür Sie heute bezahlen und wie viel davon genutzt wird, also die Grundlage, die Kosten pro VM brauchen. Das technische Assessment liefert einen Bericht, ein TCO- und ROI-Modell und einen Maßnahmenplan vor dem Renewal, und sein Preis steht vor Beginn fest. Das Engineering liefert unser Engineering-Partner Vixen.UNO, mit Änderungen in vereinbarten Wartungsfenstern und einem Rollback-Plan. Wo die Entscheidung über VMware hinausgeht, deckt unser Infrastruktur-Audit die gesamte Umgebung ab.

FAQ