Info2soft verwendet Cookies, um Ihnen ein besseres und angenehmeres Surferlebnis auf unserer Website zu ermöglichen. Datenschutzerklärung
Wird geladen...
Von:
Eine Buildnummer ist die genaueste Möglichkeit, festzustellen, was tatsächlich auf Ihrem vCenter Server ausgeführt wird. Im Gegensatz zu Versionsbezeichnungen wie „Update 3“ geben Buildnummern den genauen Patch-Stand Ihrer Appliance an – einschließlich vorhandener Hotfixes, Sicherheitsaktualisierungen und API-Funktionalitäten.
Dieser Leitfaden erläutert die Bedeutung von vCenter-Buildnummern, wo Sie diese ermitteln und wie Sie sie für Upgrades, Kompatibilitätsprüfungen und Supportanfragen nutzen können.
Ein vCenter Server-Betrieb basiert auf mehreren Softwareebenen. Eine Buildnummer ist eine eindeutige, fortlaufende Kennung, die VMware einer bestimmten Kompilierung des vCenter-Codebasises zuweist. Der Abgleich mit der Versionszeichenfolge klärt genau, welcher Code in Ihrer Umgebung ausgeführt wird.
Buildnummer vs. Versionszeichenfolge
Eine Versionszeichenfolge ist der Marketing- oder Release-Name der Software, beispielsweise „8.0 Update 3b“. Eine Buildnummer ist eine spezifische sieben- bis achtstellige Zahlenfolge wie „24026615“.
Beide Kennungen sind erforderlich, um die Kompatibilität mit ESXi-Hosts, Sicherungsagenten und Speicher-Plugins zu prüfen.
Die drei Kennungen, denen Sie begegnen
Bei regulären Verwaltungsaufgaben arbeiten Administratoren mit drei unterschiedlichen Identifikatoren:
vpxd-Daemons. Sie erscheint in der vpxd.log, in Antworten der vSphere-REST-API und in PowerCLI-Ausgaben.Um den genauen Status Ihrer Bereitstellung zu ermitteln, müssen Sie Ihr System mit den offiziellen Build-Registries abgleichen.
Die nachfolgende Tabelle enthält wichtige Meilensteine jeder Hauptversionsreihe: die GA-Build-Version, das neueste verfügbare Patch sowie ausgewählte bedeutende Zwischenreleases. Sie hilft Ihnen, Ihre ungefähre Position im Release-Zeitablauf schnell zu finden.
Die vollständige Patch-Historie finden Sie in der Broadcom-KB 326316 unter folgendem Link: Broadcom KB 326316.
| Release-Bezeichnung | Veröffentlichungsdatum | Versionszeichenfolge | ISO-Build | Anwendungs-Build |
|---|---|---|---|---|
| vCenter Server 9.0.2 | 20.01.2026 | 9.0.2.0 | 25148086 | 25148086 |
| vCenter Server 9.0.1 | 29.09.2025 | 9.0.1.0 | 24957454 | 24957454 |
| vCenter Server 9.0 GA | 17.06.2025 | 9.0.0.0 | 24755230 | 24755230 |
| vCenter Server 8.0 Update 3j | 27.05.2026 | 8.0.3.00900 | 25413364 | 25413364 |
| vCenter Server 8.0 Update 3e | 11.04.2025 | 8.0.3.00500 | 24674346 | 24674346 |
| vCenter Server 8.0 Update 3 GA | 25.06.2024 | 8.0.3.00000 | 24022515 | 24022515 |
| vCenter Server 7.0 Update 3t | 21.10.2024 | 7.0.3.02200 | 24322018 | 24322018 |
| vCenter Server 7.0 Update 3 GA | 05.10.2021 | 7.0.3.00000 | 18700403 | 18700403 |
| vCenter Appliance 6.7 Update 3q | 08.02.2022 | 6.7.0.52000 | 19300125 | 19299595 |
| vCenter Appliance 6.7 GA | 17.04.2018 | 6.7.0.10000 | 8217866 | Nicht verfügbar |
| vCenter Server 6.5 Update 3w | 04.07.2024 | 6.5.0.43000 | 24045034 | 24045034 |
Ein weiterer Hinweis: Ab vSphere 7.0 hat VMware die Windows-basierte vCenter Server-Version eingestellt. Alle Einträge ab Version 7.0 beziehen sich ausschließlich auf die VCSA-Bereitstellung.
Administratoren können die Buildnummer über mehrere Schnittstellen abfragen – je nach Präferenz über grafische Konsole, Kommandozeile oder programmgesteuerten API-Zugriff.
Der direkteste Weg führt über die primäre Verwaltungskonsole.
Die VCSA-Verwaltungsschnittstelle (VAMI) liefert Konfigurations- und Statusinformationen auf Appliance-Ebene.
https://<vcenter-fqdn-oder-ip>:5480 auf.
Wenn die grafische Oberfläche nicht erreichbar ist oder Sie Shell-Zugriff benötigen, fragen Sie die Appliance direkt per SSH ab.
shell ein, um zur Bash zu wechseln.vpxd -v
VMware vCenter Server 8.0.3 build-25413364.Für Administratoren, die vSphere per PowerShell verwalten, liefert PowerCLI die Build-Details mit einem einzigen Befehl.
Connect-VIServer eine Verbindung zu Ihrer vCenter-Instanz her.$Global:DefaultVIServers | Select-Object Name, Version, Build
Um Build-Informationen programmgesteuert abzufragen, senden Sie eine GET-Anfrage an folgenden Endpunkt:
GET https://<vcenter-fqdn-oder-ip>/api/vcenter/system/version
Die JSON-Antwort enthält Felder für Version und Build, die Automatisierungsplattformen nutzen können, um die Einhaltung eines definierten Basisstands zu prüfen.
In großen Umgebungen ist die manuelle Prüfung jeder vCenter-Instanz zeitaufwendig. Die nachfolgenden Skripte sammeln Build-Informationen aller aktiven Verbindungen und exportieren sie für Planungs- und Compliance-Workflows.
PowerCLI-Automatisierungsskript
Dieses Skript durchläuft alle aktiven vCenter-Verbindungen und exportiert die Ergebnisse in eine CSV-Datei.
# Sammle Daten aller aktiven vCenter-Verbindungen
$vCenterReport = foreach ($server in $Global:DefaultVIServers) {
[PSCustomObject]@{
vCenterName = $server.Name
Version = $server.Version
BuildNumber = $server.Build
CheckDate = (Get-Date).ToString("yyyy-MM-dd")
}
}
# Exportiere gesammelte Daten in eine CSV-Datei
$vCenterReport | Export-Csv -Path "C:\temp\vCenter_Build_Report.csv" -NoTypeInformation
REST-API-Ansatz
Für Umgebungen ohne PowerCLI funktioniert ein direkter API-Aufruf per Invoke-RestMethod ohne VMware-Modul:
$vCenter = "vcenter.local"
$headers = @{ "vmware-api-session-id" = "IHR_SITZUNGSTOKEN" }
$response = Invoke-RestMethod -Uri "https://$vCenter/api/vcenter/system/version" -Method Get -Headers $headers -SkipCertificateCheck
$response | Select-Object version, build
Bei vSphere 5.x bis 8.x zeigt vCenter je nach genutzter Schnittstelle zwei unterschiedliche Buildnummern an. Das Verständnis des Unterschieds ist wichtig für korrektes Patchen, Kompatibilitätsprüfungen und Supportanfragen.
VMware hat die duale Build-Struktur entwickelt, um das Betriebssystem der virtuellen Appliance von dem darin ausgeführten Verwaltungsdienst zu trennen.
Wenn Sie ein vCenter-Update herunterladen, verfügt die ISO-Datei über eine eigene Buildnummer, die den kompilierten Gesamtzustand des Pakets darstellt: Photon OS, Systemabhängigkeiten und gebündelte Patches.
Der zentrale Verwaltungsdienst (vpxd) innerhalb dieses Betriebssystems besitzt eine separate Buildnummer, die den Kompilierungsstand der Verwaltungsengine selbst widerspiegelt.
Die folgende Tabelle zeigt, welche Buildnummer jede Schnittstelle anzeigt und welche Komponente sie repräsentiert.
| Schnittstelle oder Tool | Angezeigte Kennung | Zielkomponente |
|---|---|---|
| VAMI-Konsole (Port 5480) | ISO-Build | Appliance-Betriebssystem-Paket |
| vSphere Client (Dialog „Info“) | Anwendungs-Build | Laufender vpxd-Daemon |
| PowerCLI ($Global:DefaultVIServers) | Anwendungs-Build | Kern-API-Ebene |
| ESXi-Host-Verbindungsstatus | Anwendungs-Build | Interoperabilität des Verwaltungsagenten |
| Support-Shell (vpxd -v) | Anwendungs-Build | Verwaltungsengine |
Ab vSphere 9.0 stimmen ISO-Build und Anwendungs-Build auf allen Schnittstellen überein. Broadcom hat die Kompilierungspipeline der Appliance umstrukturiert, sodass Photon OS-Pakete und der vpxd-Dienst gemeinsam kompiliert werden. Es entsteht eine einheitliche Buildnummer, unabhängig davon, mit welchem Tool oder API Sie abfragen.
Allein eine Versionsbezeichnung reicht nicht für die Planung eines sicheren Upgrades. Buildnummern liefern die erforderliche Genauigkeit, um Kompatibilität zu prüfen, Aktualisierungen korrekt zu sequenzieren und blockierte Upgrade-Pfade zu vermeiden.
Release-Bezeichnungen wie „8.0 Update 3“ umfassen mehrere unabhängige Patch-Releases. Update 3 GA, Update 3c und Update 3j besitzen jeweils unterschiedliche Buildnummern und beheben abweichende Sicherheitswarnungen und Fehler.
Wenn Ihr Upgrade-Plan nur die Bezeichnung „Update 3“ verwendet, könnten Techniker einen älteren, anfälligen Build statt der vorgesehenen Release-Version installieren. Die Angabe der genauen Ziel-Buildnummer beseitigt diese Mehrdeutigkeit.
Bevor Sie jeglichen Lebenszyklusvorgang durchführen, gleichen Sie Ihre Quell- und Ziel-Buildnummern mit der VMware-Produktkompatibilitätsmatrix ab. Die Matrix listet unterstützte Upgrade-Pfade auf, benötigt aber genaue Build-Daten für korrekte Ergebnisse.
Ein zu prüfender Punkt ist die sogenannte Rückwärtsblockierung: Wenn Ihr aktueller vCenter-Build über einen höheren Sicherheits-Epochenwert verfügt als der Ziel-Build einer neueren Hauptversion, blockiert das Installationsprogramm das Upgrade. Die vorherige Prüfung der Buildnummern verhindert fehlgeschlagene Upgrade-Versuche.
Eine zentrale Regel des vSphere-Lebenszyklusmanagements: vCenter muss stets eine Version aufweisen, die der verwalteten ESXi-Hosts entspricht oder darüber liegt. Ein vCenter mit älterem Build kann API-Aufrufe neuerer ESXi-Hosts nicht interpretieren, wodurch die Kommunikation der Verwaltungsebene unterbrochen wird.
Die vorherige Prüfung der Buildnummern beider Komponenten bestätigt, dass Ihr vCenter mindestens den Build-Stand jedes verwalteten Hosts erreicht.
Virtualisierungsumgebungen arbeiten selten isoliert. Sicherungsplattformen, Überwachungstools, Speicherarrays und hyperkonvergente Infrastrukturlösungen wie VxRail besitzen Integrationsvoraussetzungen, die an spezifische Buildnummern statt allgemeine Versionsbezeichnungen gebunden sind.
Eine Sicherungsplattform erfordert beispielsweise vCenter Server 8.0.3 Build 24022515 oder höher, um eine bestimmte API-Funktion zu unterstützen. Die Prüfung des Ziel-Builds anhand dieser Anforderungen vor dem Upgrade verhindert Integrationsfehler und sichert die Gültigkeit von Supportverträgen mit Drittanbietern.
Die Bestätigung der Ziel-vCenter-Buildnummer und die Kompatibilitätsprüfung sind nur ein Teil der Arbeit. Die nächste Herausforderung ist die Migration der Workloads selbst.
Ob Sie von vCenter 7.0 auf 8.0 konsolidieren, zu einem anderen Hypervisor wechseln oder in die Cloud migrieren: Virtuelle Maschinen müssen oft Plattform- oder Formatgrenzen überwinden, die vMotion allein nicht bewältigt. Hier kommt i2Migration ins Spiel.
i2Migration ist eine vereinheitlichte Migrationsplattform für plattformübergreifende VM- und Datenmigration zwischen physischen, virtuellen und Cloud-Umgebungen.
Für Umgebungen, die nach der Migration einen dauerhaften Datenschutz benötigen, bietet i2Backup eine zentralisierte Sicherung virtueller, physischer und Cloud-Workloads. Für Hochverfügbarkeitsanforderungen liefert i2Availability Echtzeit-Replikation und automatisches Failover, um kritische Dienste während und nach größeren Infrastrukturänderungen am Laufen zu halten.
F1: Warum zeigt die VAMI eine andere Buildnummer als der vSphere Client an?
Die VAMI fragt die Paketdatenbank der Appliance ab und gibt den ISO-Build aus. Der vSphere Client fragt den laufenden vpxd-Dienst ab und liefert den Anwendungs-Build. Der obige Abschnitt „ISO-Build vs. Anwendungs-Build“ erläutert den Unterschied detailliert.
F2: Funktionierten ESXi-Buildnummern nach dem gleichen Prinzip?
Nein. ESXi nutzt eine einzelne Buildnummer, die den gesamten Zustand des Hypervisor-Images darstellt. Es gibt keine Trennung zwischen Betriebssystemebene und Verwaltungsagent, das Zwei-Nummern-Problem älterer vCenter-Versionen tritt hier nicht auf.
F3: Wo finde ich die offizielle Build-Liste nach der Übernahme von VMware durch Broadcom?
Die maßgebliche Quelle ist die Broadcom-KB 326316 unter diesem Link. Alte Links zur kb.vmware.com leiten automatisch auf dasselbe Portal um.
F4: Was hat sich bei den Buildnummern ab vSphere 9.0 geändert?
Ab vSphere 9.0 sind ISO-Build und Anwendungs-Build auf allen Schnittstellen identisch. Broadcom hat die Kompilierungspipeline vereinheitlicht, sodass beide Komponenten gemeinsam kompiliert werden. Dies vereinfacht Audits und beseitigt Abweichungen bei der Erstellung von Supportanfragen.
Eine vCenter-Buildnummer liefert ein präzises, eindeutiges Bild des Patch-Stands Ihrer Umgebung. Versionsbezeichnungen wie „Update 3“ dienen lediglich als Ausgangspunkt – die Buildnummer entscheidet über Upgrade-Berechtigung, Integrationskompatibilität und die Genauigkeit von Supportanfragen.
Die zentralen Erkenntnisse dieses Leitfadens: Prüfen Sie stets sowohl ISO-Build als auch Anwendungs-Build, bevor Sie einen Supportfall eröffnen oder ein Patch-Fenster planen; verwenden Sie stets die genaue Buildnummer statt der Release-Bezeichnung beim Abgleich mit der VMware-Produktkompatibilitätsmatrix; und aktualisieren Sie immer zuerst vCenter, bevor Sie die ESXi-Hosts bearbeiten.
Bei Umgebungen mit einem großen vCenter-Versionswechsel ist die Prüfung der Build-Kompatibilität nur ein Teil des Prozesses. Wenn Workloads Plattform- oder Hypervisor-Grenzen überwinden müssen, übernimmt i2Migration von Info2soft die plattformübergreifende VM-Migration – ohne gemeinsamen Speicher oder vMotion-Voraussetzungen.
· Unternehmenskunden und Mittelstand weltweit
· Unser Support-Team unterstützt Sie während der gesamten Testphase
· Starten Sie eine 60-tägige Testversion oder sehen Sie sich eine Demo an, um zu erfahren, wie Info2Soft Unternehmensdaten schützt.
