VMware-Lizenzierung nach der Broadcom-Umstellung: Wie Sie richtig zählen

Was sich tatsächlich geändert hat

Zwei Dinge – besprochen wird meist nur eines. Sichtbar ist die Umstellung auf Abonnements: Es gibt keine Dauerlizenz mehr zu kaufen, und die Verlängerung ist die vollen Kosten, nicht ein Supportanteil auf einen Besitz, den Sie ohnehin schon haben.

Die leisere Änderung ist die Paketierung. Aus einer langen Produktliste wurde eine kurze Liste von Bündeln, und das Bündel, in dem Sie landen, bestimmt, wofür Sie zahlen – ob Sie es nutzen oder nicht. Die vier, die auf einem Angebot auftauchen:

Inhalte und Laufzeiten haben sich seit 2024 mehrfach bewegt – das hier ist die Form, Ihr Angebot ist die Tatsache. vSphere 9.x gibt es nur in VVF und VCF.

Die praktische Folge: Die interessante Frage lautet nicht mehr „welche Funktionen lizenzieren wir“, sondern „wie viele Kerne legen wir der Rechnung vor – und haben wir das so gewollt“.

Wie die Kernzahl berechnet wird

Die Regel von Broadcom ist kurz. Sie lizenzieren jeden physischen Kern in jedem Host, auf dem das Produkt läuft, und mindestens 16 physische Kerne je CPU-Sockel – unabhängig davon, wie viele Kerne die CPU wirklich hat. Hyperthreading spielt keine Rolle, logische Prozessoren werden nicht gezählt.

Das Minimum trifft kleine Umgebungen. Es rundet je Sockel auf, jedes Mal:

Mindestens 16 Kerne je physischer CPU, je Sockel angewandt und dann über alle Hosts summiert

Lesen Sie die letzte Zeile noch einmal, denn sie kommt in echten Umgebungen vor. Vier ältere Sockel mit wenigen Kernen werden mit 64 Kernen verrechnet. Dieselbe Rechenleistung auf zwei modernen 16-Kern-Sockeln ergibt 32. An der Last hat sich nichts geändert, die Rechnung hat sich halbiert.

Die 72-Kern-Geschichte – und warum man nicht nach Schlagzeilen plant

Ende März 2025 meldete der Fachhandel, Broadcom hebe die Mindestbestellmenge zum 10. April auf 72 Kerne je Bestellung und Produkt an. Zwei Wochen später meldeten dieselben Kanäle die Rücknahme, unter den ersten das deutsche Fachmagazin iX. Broadcom erklärte gegenüber der Presse, man habe keine Preisänderung angekündigt. Berichten zufolge erreichte die Regel zudem manche Regionen und andere nicht.

Was davon übrig bleibt, ist eine stabile Tatsache: Die dokumentierte Regel lautet 16 physische Kerne je CPU, veröffentlicht in Broadcoms eigener Wissensdatenbank. Alles darüber hinaus hat sich nach Kanal, Region und Quartal bewegt.

Der praktische Rat ist unspektakulär: Bauen Sie kein Budget auf einem Artikel auf – auch nicht auf diesem. Lassen Sie sich von Ihrem Reseller die Kernzahl, die er anbieten will, schriftlich geben, samt der Mindestregel, die er anwendet. Ist die Zahl größer als Ihre physische Kernzahl, hat die Differenz einen Namen – und er kann ihn nennen.

Was enthalten ist – und die Zusatzposition, die überrascht

Die Foundation-Bündel enthalten vSAN-Kapazität, und die Menge skaliert mit den lizenzierten Kernen, nicht mit dem vorhandenen Speicher:

Gerechnet wird gegen die rohe physische Kapazität, die Hosts in vSAN-Cluster einbringen – nicht gegen die nach Richtlinien nutzbare Kapazität

Zwei Details verursachen die meisten Überraschungen. Erstens wird gegen die rohe Kapazität gerechnet, also gegen die physischen Datenträger – nicht gegen den Platz, der nach RAID oder Erasure Coding übrig bleibt. Eine Umgebung, die zu passen scheint, liegt roh gerechnet manchmal darüber. Zweitens kaufen Sie zusätzliche vSAN-TiB als eigene Position, und die steht im ersten Angebotsentwurf selten drin.

Wenn Sie vSAN betreiben: Zählen Sie Ihre Rohkapazität vor dem Verlängerungsgespräch, nicht währenddessen.

Wo die Zahl größer wird als nötig

Vier Muster erklären den größten Teil der Lücke zwischen dem, was eine Umgebung zahlt, und dem, was sie zahlen müsste. Keines davon verlangt einen Plattformwechsel.

1. Viele Hosts auf alten Sockeln. Oben beschrieben und eine Wiederholung wert: viele kleine Hosts mit wenigen Kernen je CPU sind unter einer Pro-Kern-Regel mit Sockel-Untergrenze die teuerste denkbare Form. Konsolidierung war früher ein Kapazitätsargument. Heute ist sie eine Rechnungsposition.

2. Entwicklung, Test und DR auf dem Produktions-Paket. Sie laufen auf demselben Hypervisor und erben deshalb standardmäßig dasselbe Bündel. Ob ein kleineres Paket abdeckt, was diese Hosts wirklich tun, ist eine Frage für einmal im Jahr – und sie wird selten gestellt.

3. Cluster-Reserve, die niemand neu hergeleitet hat. Ein Cluster, der beim Aufbau auf N+2 ausgelegt wurde und dessen Lasten seither richtig dimensioniert wurden, trägt vielleicht einen ganzen Host an Reserve, die sich heute jedes Jahr in Lizenzkernen bezahlt macht. Die Reservepolitik sollte der heutigen Last folgen, nicht der von vor drei Erneuerungszyklen.

4. Kerne, die eingeschaltet sind und nichts tun. Manche Plattformen erlauben es, Kerne in der Firmware zu deaktivieren. Das senkt die Lizenzzahl nicht: Broadcoms Programmdokumentation legt fest, dass jeder Kern im Server lizenziert werden muss – auch im BIOS deaktivierte Kerne –, und warnt, dass das eigene Zählskript bei deaktivierten Kernen zu wenig zählt. Weniger Kerne vorlegen kann nur, wer einen kleineren Prozessor oder weniger Hosts einsetzt.

Ein durchgerechnetes Beispiel

Eine mittelgroße Umgebung betreibt sechs Hosts mit je zwei 10-Kern-CPUs. Physische Kerne: 120. Verrechnete Kerne: 192, weil jeder der zwölf Sockel auf 16 aufrundet. Bezahlt werden 72 Kerne, die gar nicht vorhanden sind.

Die Lasten dieser sechs Hosts passen, über einen Monat gemessen, in drei moderne Hosts mit je zwei 24-Kern-CPUs – 144 physische Kerne und 144 verrechnete Kerne, weil jeder Sockel deutlich über dem Minimum liegt. Das sind 48 lizenzierte Kerne weniger als vorher, bei mehr Rechenleistung, weniger Strom, weniger Höheneinheiten und drei Hosts weniger im Patch-Zyklus.

Ob sich der Tausch rechnet, ergibt nur Ihre eigene Rechnung: die Lizenzdifferenz über die Abolaufzeit gegen die Server, den Migrationsaufwand und die Restlebensdauer der vorhandenen Hosts. Manchmal ist es eindeutig. Manchmal lautet die ehrliche Antwort, die Hosts zu behalten und stattdessen das Bündel zu korrigieren. Der Punkt ist: Unter einem Pro-Kern-Abo sind Hardware- und Lizenzfrage dieselbe Frage geworden – und wer beide Budgets noch getrennt führt, zahlt am meisten.

Was wir tun

Eurokommerz führt Infrastruktur-Audits und VMware-Optimierung als Festpreisprojekte durch: Wir zählen die Kerne, die Ihr heutiger Aufbau der Rechnung vorlegt, messen, was die Lasten tatsächlich brauchen, und legen Ihnen die Konsolidierungsvarianten mit der jeweiligen Lizenzdifferenz vor. Umgesetzt wird von unserem Engineering-Partner Vixen.UNO – VMware Premier Partner und Mitglied der Broadcom Technology Alliance, zwölf Ingenieure mit aktueller VCP- und vier mit VCAP-Zertifizierung* – unter einem europäischen Vertrag mit uns.

Wir sind kein Lizenzbasar und wir werden Ihnen nicht erzählen, dass Ihre Plattform falsch ist. Die meisten Umgebungen, die wir sehen, sollten bleiben, wo sie sind – und richtig gezählt werden. Siehe VMware-Optimierung und Infrastruktur-Audit.

*Kennzahlen des Vixen.UNO-Engineering-Teams

FAQ