Broadcoms Skript zur Kernzählung für VVF und VCF: KB 313548 Schritt für Schritt ausführen

Was KB 313548 ist, Stand September 2026

Der Artikel 313548 der Broadcom-Wissensdatenbank, „Counting Cores for VMware Cloud Foundation and vSphere Foundation and TiBs for vSAN“, ist Broadcoms eigene Referenz für die Zählung. Sein erklärtes Ziel ist, die Kern- und TiB-Lizenzen zu ermitteln, die „für die ordnungsgemäße Lizenzierung von VMware vSphere Foundation, VMware Cloud Foundation und VMware vSAN Add-on erforderlich“ sind. Seine alte VMware-Nummer, 95927, leitet inzwischen auf ihn weiter, seine Umgebungsliste umfasst ESXi 6.0, ESXi 7.0 und ESXi 8.0, dazu VCF 4.5 und VCF 5.1, und dieser Leitfaden folgt der Seite, so wie wir sie am 28. September 2026 gelesen haben.

Die KB bietet zwei Wege. Für kleinere Umgebungen einen manuellen: die Kerne je Sockel jedes Hosts, abgelesen unter „Host“, „Hardware“, „CPU Processors“. Für „größere, von vCenter verwaltete Umgebungen“ ein PowerCLI-Tool, das „Informationen über die Anzahl der Kernlizenzen (mit einem Minimum von 16 Kernen je physischer CPU) und der TiB-Lizenzen, die für jeden mit einer vCenter-Instanz verbundenen Host erforderlich sind, sammelt und zusammenführt“. Der manuelle Weg endet bei den Kernen: Laut KB kann die Produktoberfläche die gesamte Rohkapazität, die ein vSAN-Cluster beansprucht, nicht anzeigen, und eine manuelle Berechnung der vSAN-TiB über die Oberfläche ist „NICHT empfohlen und nicht genau“.

Angehängt sind zwei Module. FoundationCoreAndTiBUsage.psm1 ist dasjenige, das die KB dokumentiert und dieser Leitfaden verwendet; das zweite, MultiVcCoreAbdTiBUsage.psm1 (so auf der Seite geschrieben), kommt ohne Anleitung. Für 8.0 Update 3 verweist die KB auf KB 400416, die ein geändertes Modul mitliefert: Das ursprüngliche ruft eine vSAN-API auf, die „in vSAN 8.0 U3 nicht existiert“. Ein eigenes Skript für VCF Edge oder 9.x haben wir nicht gefunden. Für 9.x vermerkt die KB, dass die Lizenzierung von Hosts und vSAN-Clustern eine Instanz von VCF Operations und eine vCenter-Instanz erfordert, und VCF Operations 9.1 zeigt die Lizenznutzung auf seiner Seite „Usage Analytics“. Die Lizenzmechanik von 9.x steht in unserem Leitfaden zur VMware-Verlängerung, die Termine für 8.x in unserem Leitfaden zum Supportende von vSphere 8.

Die angewandte Regel und die Mindestzahl an Kernen für VVF

Broadcoms aktuelle Programmdokumentationen für VVF und VCF, beide vom Juni 2026, verwenden denselben Wortlaut: Die Software ist „licensed on a per Core license metric with a minimum licensing requirement of 16 Cores per Processor“, und „Each Core on the Server where Software is installed must be licensed, including Cores deactivated by the BIOS.“ Ein Kern ist „a single physical computational unit of the Processor“, Hyperthreads werden also nicht gezählt. Das eigene Beispiel der KB: Ein Host mit zwei 8-Kern-CPUs und ein Host mit zwei 24-Kern-CPUs werden als 2 × 16 plus 2 × 24 lizenziert, also mit 80 Kernen. Die Programmdokumentation für vSphere Standard vom Mai 2026 legt dasselbe Minimum fest, ohne vSAN-Kapazität.

VCF Edge weicht ab. Seine eigene Programmdokumentation (Juni 2026) sieht ein Minimum von 8 Kernen je Prozessor vor, mindestens 10 Edge Locations innerhalb des ersten Jahres und höchstens 256 Kerne je Edge Location. Die KB dokumentiert als Deployment-Typen nur VCF und VVF, mit 16 je CPU; zählen Sie Edge-Hosts deshalb anhand ihrer Spalten für Sockel und Kerne nach.

Weder die KB noch die Programmdokumentationen für VVF und VCF legen ein Minimum pro Bestellung fest. Der Fachhandel meldete im März 2025 ein Minimum von 72 Kernen pro Bestellung, und Distributoren sowie das deutsche Fachmagazin iX meldeten im April, es sei zurückgenommen worden; dennoch zeigt Broadcoms Website vmware.com weiterhin ein undatiertes Video mit dem Titel „Broadcom’s New 72-Core Order Minimum Explained“. Lassen Sie sich das auf Ihr Angebot angewandte Minimum schriftlich geben; die Regeln und diese Geschichte stehen ausführlich in unserem Leitfaden zur VMware-Lizenzierung.

Bevor Sie das Skript ausführen

Die KB nennt drei Voraussetzungen: VMware PowerCLI 13.3 oder höher, PowerShell 7.4.6 oder höher und das angehängte Skript, heruntergeladen und entpackt. Seit Version 9.0 heißt das Tool VCF PowerCLI; Broadcom bezeichnet 9.0 als „eine Fortsetzung von VMware PowerCLI 13.3“, die niedrigere Nummer ist also das neuere Release. KB 393240, geschrieben für einen Fehlschlag des Skripts unter vSAN 8.x, verlangt PowerShell 7.5.0 oder höher; 7.5.0 oder neuer erfüllt also die Anforderungen beider Artikel.

Klären Sie vorher vier Dinge. Die KB nennt keine vCenter-Rolle; Broadcoms Sicherheitshandbuch zu vSphere sagt, dass ein Benutzer mit „No Access“ auf einem Objekt „das Objekt in keiner Weise anzeigen oder ändern kann“. Führen Sie das Skript also mit einem Konto aus, dessen Berechtigungen jeden Host und jeden Cluster in diesem vCenter abdecken. Die KB warnt, dass das Skript bei Kernen, die „in den BIOS-Einstellungen oder auf andere Weise“ deaktiviert wurden, „ungenaue Ergebnisse liefern kann“, und verlangt, dass beim Lauf alle physischen Kerne aktiv sind. Im Abschnitt zur Fehlerbehebung nennt sie „von vCenter getrennte ESX-Server“ und PDL-Geräte unter den Ursachen von Fehlern, die die Zahl der TiB-Lizenzen verändern können; verbinden Sie die Hosts also zuerst wieder. Und verweigert PowerShell das Laden des Moduls, weil es nicht digital signiert sei, besteht die Abhilfe der KB in Set-ExecutionPolicy mit -Scope Process und -ExecutionPolicy Bypass, einer Änderung, die nur die aktuelle PowerShell-Sitzung betrifft.

Die Ausführung, Schritt für Schritt

Das Verfahren der KB hat drei Schritte. Ersetzen Sie die Platzhalter der KB, vCenter_Server, Cluster_Name und name.csv, durch Ihre Werte.

Erstens verbinden Sie sich mit dem vCenter: Connect-VIServer -Server vCenter_Server. Zweitens importieren Sie das Modul aus dem Ordner, in den Sie es entpackt haben: Import-Module, gefolgt von .\FoundationCoreAndTiBUsage.psm1 oder, unter 8.0 Update 3, von der geänderten Datei aus KB 400416 unter ihrem eigenen Dateinamen. Drittens führen Sie Get-FoundationCoreAndTiBUsage mit -DeploymentType VCF oder -DeploymentType VVF aus. Standardmäßig, so heißt es in der KB, „durchläuft das Skript alle vSphere-Cluster“.

Drei Parameter verändern den Lauf. -ClusterName "Cluster_Name" beschränkt ihn auf einen Cluster. -CSV schreibt die Ergebnisse in Dateien, und -Filename "name.csv" legt den Namen fest. Die KB weist darauf hin, dass Sie dann „zwei Dateien erhalten“: Die Datei mit angehängtem -vsan enthält die TiB-Werte, die andere die Kernwerte.

In jedem Beispielpaar der KB ist die Kernzahl für beide Deployment-Typen gleich; was sich ändert, ist das vSAN-Kontingent, 1 TiB je Kern für VCF und 0,25 TiB für VVF. Nehmen Sie die Kernzahl aus einem Lauf ohne -ClusterName, denn ein auf einen Cluster beschränkter Lauf lässt Hosts aus, die zu keinem Cluster gehören. Sollen manche Cluster als VCF und andere als VVF lizenziert werden, ergänzen Sie für die vSAN-Werte je Cluster einen Lauf mit -ClusterName und dem Typ dieses Clusters.

Die Ausgabe lesen

Die Ausgabe hat drei Teile. Host Information hat eine Zeile je Host: CLUSTER, leer, wenn der Host nicht Teil eines Clusters ist; VMHOST, laut KB die IP-Adresse des Hosts; NUM_CPU_SOCKETS; NUM_CPU_CORES_PER_SOCKET; FOUNDATION_LICENSE_CORE_COUNT, die Kernlizenzen, die der Host mit angewandtem Minimum von 16 Kernen braucht; und vSAN_LICENSE_TIB_COUNT, die TiB, die diese Kernlizenzen mitbringen. Ein Host mit zwei 8-Kern-CPUs zum Beispiel sollte 2, 8 und 32 zeigen. Cluster Information liefert REQUIRED_VSAN_TIB_CAPACITY, die TiB, die für jeden Cluster zu lizenzieren sind. Bei den Summen ist „Total Required Licenses“ die Summe der Kernspalte. „Total Required vSAN Add-on Licenses“ ist der TiB-Bedarf abzüglich der TiB aus dem Foundation-Produkt: Null oder ein negativer Wert bedeutet kein Add-on, und die KB ergänzt, dass „überschüssige Kapazität aggregiert werden kann“; ein positiver Wert ist das zu kaufende Add-on.

Zwei durchgerechnete Beispiele aus der KB zeigen das Minimum und die vSAN-Rechnung:

Broadcom KB 313548, Beispielszenarien, Stand 28. September 2026.

Die Rohkapazität zählt in ganzen TiB, aufgerundet: Von 184,32 TiB bleiben nach Abzug der 144 enthaltenen 41 zu kaufen. Broadcoms Lizenzseite zu vSAN 8 rundet genauso: Bei 14,1 TiB „wird die Lizenznutzung auf 15 TiB aufgerundet“, und die KB gibt die 0,25 TiB je Kern bei VVF als „auf das nächste TiB aufgerundet“ an.

Mehrere vCenter und die Summe im Abgleich mit dem Angebot

Die KB dokumentiert das Modul mit einer einzigen vCenter-Verbindung und ohne Verfahren für mehrere; das folgende ist unseres. Führen Sie alle drei Schritte, und die Umgehung der Ausführungsrichtlinie, falls Sie sie gebraucht haben, einmal je vCenter aus, jedes Mal in einer neuen PowerShell-Sitzung, mit -CSV und einem anderen Dateinamen. Addieren Sie dann die Kernlizenzen aller Läufe, getrennt nach Produktlinie, wenn die Umgebung VVF und VCF mischen wird, sowie die TiB Rohkapazität jedes vSAN-Clusters, und stellen Sie die TiB dem Kontingent der Kerne der jeweiligen Produktlinie gegenüber. Auch die KB summiert in ihrer eigenen Berechnung die Rohkapazität aller Hosts „in jedem Cluster“, und Broadcoms FAQ zu VVF 9.1 bestätigt, dass „das vSAN-Kontingent über Cluster hinweg aggregiert werden kann“; die Programmdokumentationen erlauben das nur über Kerne desselben Produkts hinweg.

Gleichen Sie dann das Angebot mit Ihrer Zählung ab. Die Kernzahl jeder Produktlinie sollte Ihrer Summe für die Hosts entsprechen, die sie abdecken soll; eine höhere Zahl braucht eine schriftliche Erklärung, sei es ein übersehener Host, ein bei manueller Zählung vergessenes Minimum oder ein Bestellminimum. Die vSAN-Add-on-Position sollte der Rohkapazität Ihrer vSAN-Cluster entsprechen, aufgerundet auf ganze TiB (vSAN 8 rundet jeden Cluster auf), abzüglich des Kontingents: 0,25 TiB je VVF-Kern, aufgerundet auf das nächste TiB, oder 1 TiB je VCF-Kern. Unsere Checkliste zum Verlängerungsangebot geht den Rest des Dokuments Position für Position durch.

Zeigt die Zählung mehr Hosts, als die Workloads brauchen, lesen Sie, wo die Verschwendung sitzt. Für einen Aufbau, den es noch nicht gibt, bietet Broadcoms KB 312202 einen Rechner, Get-VCFandVVFCalculator, der eine CSV-Zeile je geplantem Cluster entgegennimmt und die benötigten Kernlizenzen und vSAN-TiB ausgibt. Fehlen diese Daten vor dem Zeitfenster der Verlängerung, beginnt unsere VMware-Optimierung mit einem Audit der Umgebung und ihrer Lizenzen und stimmt danach die Editionen auf die realen Workloads ab.

Prüfungen, die eine falsche Zählung aufdecken

Sechs Prüfungen aus der KB und verwandten Artikeln von Broadcom, bevor die Zahl in ein Angebot geht:

Broadcom KB 313548, 393240 und 400416; Programmdokumentationen zu VVF und VCF vom Juni 2026.

Zwei weitere KB-Artikel erklären vSAN-Werte, die falsch aussehen: In KB 381817 zählt ein ausgefallener Datenträger auf einem vSAN-OSA-Host, gezogen, aber nie entfernt, weiter zur Kapazität; in KB 387458 zeigt ein Cluster mit unter vSAN 7.x eingerichteten Datenträgern auf All-Flash-Hosts, die auf ESXi 8.0 aktualisiert wurden, 0 TB Lizenznutzung, und das Skript meldet den Fehler „stale PDL devices“. Beides wird auf den Hosts behoben, bevor die Zählung wiederholt wird.

Was wir tun

Eurokommerz liefert VMware/Broadcom-Lizenzen gemeinsam mit unserem Engineering-Partner Vixen.UNO: Audit, Lizenzierung und Deployment unter einem europäischen Vertrag. In der VMware-Optimierung auditiert das Vixen.UNO-Team die Umgebung und ihre Lizenzen, stimmt Editionen und Abonnements innerhalb der aktuellen Broadcom-Lizenzlogik auf die realen Workloads ab und erstellt einen Maßnahmenplan vor Verlängerung und Supportende, mit Terminen. Die Modernisierung von vSphere, vSAN, NSX und VCF folgt in vereinbarten Wartungsfenstern mit Rollback-Plan, danach Support unter einem vereinbarten SLA. Der erste Schritt ist ein kostenloses Erstgespräch; das technische Assessment ist kostenpflichtig, sein Preis steht vor Arbeitsbeginn fest, und unser Infrastruktur-Audit deckt die Umgebung über VMware hinaus ab.

FAQ