VMware-Lizenzierung nach Broadcom: das 16-Kern-Minimum und wie Sie die Kerne richtig zählen

VMware-Lizenzierung pro Kern und das 16-Kern-Minimum

Unter Broadcom sind VMware vSphere Foundation (VVF) und VMware Cloud Foundation (VCF) Abonnements, lizenziert pro physischem Kern mit einer Mindestanzahl von 16 Kernen je CPU: Ein Host mit zwei 8-Kern-CPUs wird mit 32 Kernen lizenziert. Eine Dauerlizenz gibt es nicht mehr zu kaufen, daher deckt die Verlängerung die vollen Lizenzkosten ab, wo früher eine Supportgebühr auf Lizenzen anfiel, die Sie bereits besaßen. Wir liefern VMware-Lizenzen und empfehlen Edition und Laufzeit für Ihren Einsatzzweck. Fragen Sie uns, welches Bündel zu Ihrer Umgebung passt, unser Team hilft Ihnen weiter.

Die zweite Änderung betrifft 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; wie sich beide unterscheiden, zeigt unser Vergleich von VVF und VCF.

Bei der Verlängerung zählt die Kernzahl im Angebot mehr als die Funktionsliste; prüfen Sie daher, ob sie zu den Kernen passt, die Ihre Hosts melden.

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 hat. Hyperthreading spielt keine Rolle, logische Prozessoren werden nicht gezählt. Broadcom KB 313548 („Counting Cores for VMware Cloud Foundation and vSphere Foundation and TiBs for vSAN“) stellt ein PowerCLI-Skript bereit, das die Kerne je Host zählt; wie Sie es ausführen und die Ausgabe lesen, zeigt unser Leitfaden zum Core-Count-Skript von Broadcom (KB 313548).

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

Mindestens 16 Kerne je physischer CPU (bei VCF Edge 8), je Sockel angewandt und dann über alle Hosts summiert

Die letzte Zeile ist in älteren Umgebungen häufig. Vier Sockel mit wenigen Kernen werden mit 64 Kernen verrechnet. Tragen zwei aktuelle 16-Kern-CPUs dieselbe gemessene Last, werden für den Host 32 Kerne verrechnet, also die Hälfte der lizenzierten Kerne.

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. Im April meldeten Distributoren und das deutsche Fachmagazin iX, die Änderung sei zurückgenommen worden, und ein Broadcom-Sprecher sagte gegenüber iX, Broadcom habe keine Preisänderung angekündigt und das im Dezember 2023 festgelegte Minimum von 16 Kernen sei unverändert. Berichten zufolge erreichte die Regel damals manche Regionen und andere nicht. Das Minimum von 72 Kernen stützt sich nur auf diese Presse- und Handelsberichte: Ein Broadcom-Dokument, das es festlegt, haben wir nicht gefunden, und Broadcom KB 313548 (Counting Cores for VMware Cloud Foundation and vSphere Foundation and TiBs for vSAN) nennt nur das Minimum von 16 physischen Kernen je CPU.

Was davon übrig bleibt, ist eine stabile Tatsache: Die dokumentierte Regel lautet 16 physische Kerne je CPU, veröffentlicht in Broadcoms eigener Wissensdatenbank. Berichte über alles, was darüber hinausgeht, fielen je nach Kanal und Region unterschiedlich aus.

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. Vor der Unterschrift vergleicht unser Umgebungs- und Lizenz-Audit die Kerne im Angebot mit den Kernen, die Ihre Hosts melden, und mit dem, was die Workloads nutzen. Schicken Sie uns die Kernzahl aus Ihrem Angebot, und unser Team prüft sie gegen Ihre Hosts.

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, wenn Sie das Kontingent überschreiten; verlangen Sie diese Position deshalb schon im ersten Angebotsentwurf.

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. Viele kleine Hosts mit wenigen Kernen je CPU sind unter einer Pro-Kern-Regel mit Sockel-Untergrenze die teuerste denkbare Form. Bei Lizenzierung pro Kern verändert eine Konsolidierung die Lizenzposition ebenso wie die Kapazitätsplanung.

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 tun, ist eine Frage für einmal im Jahr, und sie wird selten gestellt; ab Version 9 lässt sich unter einem mit VCF lizenzierten vCenter keine VVF-Lizenz zuweisen, auch nicht als Override.

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 heute jedes Jahr Lizenzkerne kostet. 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 Broadcoms Artikel zum Kernzählen warnt, dass dessen Skript bei deaktivierten Kernen ungenaue Ergebnisse liefern kann. Weniger Kerne vorlegen kann nur, wer einen kleineren Prozessor oder weniger Hosts einsetzt.

Unser Umgebungs- und Lizenz-Audit prüft diese vier Muster Host für Host und legt die Konsolidierungsvarianten mit den jeweils lizenzierten Kernen vor. Nennen Sie uns die Zahl Ihrer Hosts und den Termin Ihrer Verlängerung.

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, wobei die Kapazität eines Hosts weiterhin für HA reserviert bleibt: 144 physische Kerne und 144 verrechnete Kerne, weil jeder Sockel ü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. Wie weit sich ein Cluster unter HA und den Mindest-Hostzahlen von vSAN verkleinern lässt, zeigt unser Leitfaden zur Host-Konsolidierung bei Lizenzierung pro Kern.

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. In anderen Umgebungen ist es besser, die Hosts zu behalten und das Bündel zu ändern. Führen Sie Serverkosten und Lizenzänderung über die Laufzeit des Abonnements in derselben Budgetposition.

Was wir tun

Eurokommerz führt Infrastruktur-Audits als Festpreisprojekte durch, und die VMware-Optimierung beginnt mit einem technischen Assessment, dessen Preis vor Arbeitsbeginn feststeht: Wir zählen die Kerne, die Ihr heutiger Aufbau zur Lizenzierung vorlegt, vergleichen sie mit dem, was die Lasten brauchen, und legen Ihnen die Konsolidierungsvarianten mit der jeweiligen Änderung der lizenzierten Kerne vor. Umgesetzt wird vom Team unseres Engineering-Partners Vixen.UNO unter einem europäischen Vertrag mit uns.

Gibt es nichts zu optimieren, sagen wir das, und manche Umgebungen sollten bleiben, wo sie sind, und richtig gezählt werden. Siehe VMware-Optimierung und Infrastruktur-Audit.

FAQ