Hardwarekonfiguration eindeutig dokumentieren

„Das ist ein DL360“ ist wie „das ist ein Auto“: stimmt, und nutzlos, sobald die Werkstatt fragt, welcher Motor.

Kurz gesagt

Damit jemand anderes genau erkennen kann, was du hast, hältst du jedes relevante Teil mit Modell, Firmware-Stand und den wichtigen Einstellungen fest und schreibst dazu, woher jeder Wert stammt und wann du ihn gelesen hast. Maschinenlesbare Quellen wie die SMBIOS-Tabelle (über dmidecode) und die Redfish-Schnittstelle des Management-Controllers eines Servers schlagen Gedächtnis und Aufkleber. Was du nicht weißt, trägst du als „unbekannt“ ein, nie als Vermutung.

So funktioniert’s

1. Lege fest, was die Konfiguration ausmacht. Teile (Prozessor, Speichermodule, Datenträger, Netzteil), Firmware-Stände (BIOS, Management-Controller) und Einstellungen (zum Beispiel Hyper-Threading oder ein Energieprofil) bilden zusammen die Konfiguration. SMBIOS, der Standard, mit dem ein Rechner dem Betriebssystem seine Hardware meldet, zeigt, wie weit das reicht: Sein Inhaltsverzeichnis führt Strukturen für System (Typ 1), Baseboard (2), Gehäuse (3), Prozessor (4), Steckplätze (9), Memory Device (17), Netzteil (39) und Firmware-Inventar (45).
2. Lies aus dem Betriebssystem mit `dmidecode`. Seine Handbuchseite sagt, dass das Werkzeug die Tabelle liest, die die Firmware bereitstellt, die Hardware nicht selbst abtastet und dass diese Angaben unzuverlässig sein können. Es meldet auch mögliche Ausbaustufen, etwa den schnellsten unterstützten Prozessor oder den maximalen Speicher. Trenne also, was eingebaut ist, von dem, was möglich wäre.
3. Lies aus dem Management-Controller mit Redfish. Die Redfish-Spezifikation (DMTF DSP0266) beschreibt eine REST-Schnittstelle mit einem Schema je Ressource. Mit dem Abfrageparameter $expand liefert ein einzelner GET-Aufruf die untergeordneten Ressourcen gleich mit; dessen Option $levels legt fest, wie viele Ebenen tief, etwa GET /redfish/v1/Systems/1?$expand=.($levels=3) für ein System samt Prozessoren und Speicher. Die Spezifikation erlaubt einem Dienst, einige dieser Optionen umzusetzen und andere nicht; welche er hat, steht im Wurzeldokument unter ProtocolFeaturesSupported, prüfe also zuerst, was deiner anbietet. Das Beispiel stammt aus der Spezifikation selbst und ist kein Versprechen, dass dein Controller es beherrscht: Die Redfish-Dokumentation von HPE sagt, dass OData-Abfrageoptionen in iLO 4 nicht umgesetzt sind, der Controller-Generation des DL360 Gen9, und dass schon iLO 5 $levels immer als 1 liest, egal welche Zahl du angibst. Im Schema ComputerSystem ist ProcessorSummary.Count die Zahl der physischen Prozessoren und MemorySummary.TotalSystemMemoryGiB der gesamte konfigurierte Speicher, auf den das Betriebssystem zugreifen kann. Eine Processor-Ressource beschreibt jeden Prozessor genauer.
4. Wisse, wessen Sicht du liest. In einer virtuellen Maschine zeigt lscpu die Konfiguration des Gastes, nicht die physische Hardware. Schreibe zu jedem Wert, ob er vom Host, vom Gast oder von einem Aufkleber stammt.
5. Vergleiche mit der Herstellerspezifikation. Das Dokument des Herstellers (beim DL360 Gen9 die HPE QuickSpecs) sagt dir, welche Optionen es gibt und welche Kombinationen nicht erlaubt sind. Es dokumentiert das Mögliche; deine Lesung dokumentiert, was du tatsächlich hast.
6. Schreibe Unbekanntes als unbekannt. Ein Feld, das du nicht lesen konntest, bekommt den Wert null und eine Notiz. Eine leere Tabellenzelle kann „keins“ oder „nicht nachgesehen“ heißen; null kann nur das Zweite heißen.
7. Gib jedem Stand einen Fingerabdruck. Dieser Schritt ist unsere eigene Methode und nicht Teil der Standards: Vereinheitliche die Werte (gleiche Einheiten, gleiche Schreibweise), sortiere die Einträge, schreibe sie in einem festen Format aus und berechne darüber einen SHA-256-Hash. Jedes geänderte Teil, jede geänderte Firmware und jede geänderte Einstellung ergibt dann einen anderen Hash, und „sind diese beiden Maschinen identisch?“ wird zum Vergleich zweier Zeichenketten. Lass Seriennummern aus allem weg, was du veröffentlichst.

In der Praxis

Lies die Quellen aus (die Befehle sind Beispiele; für diesen Artikel wurde nichts davon ausgeführt):

sudo dmidecode -t system        # Modell und Systemdaten aus der SMBIOS-Tabelle
sudo dmidecode -t bios          # BIOS-Hersteller, -Version, -Datum
sudo dmidecode -t processor     # Prozessor-Einträge
sudo dmidecode -t memory        # ein Eintrag je Steckplatz und Modul
lscpu                           # was das Betriebssystem sieht (auf einer VM die Sicht des Gastes)

Den Management-Controller kannst du mit Redfish abfragen; liste zuerst die angebotenen Systeme auf und öffne von dort eines. Ob die iLO des Bytearium-DL360-Gen9 Redfish-Abfragen beantwortet, mit welcher Firmware-Version und mit welchen Optionen, haben wir nicht geprüft; auf eigener Hardware haben wir nichts ausprobiert. Laut HPE-Dokumentation wurde iLO 4 mit Firmware 2.30 konform zu Redfish 1.0, und eine Abfrageoption, die sie nicht umsetzt, wird stillschweigend verworfen; eine Abfrage mit $expand kann also unerweitert zurückkommen.

Ein Snapshot für den DL360 Gen9 aus dem Bytearium-Inventar (Lesung vom 14. Okt. 2026) könnte so aussehen. Alles, was das Inventar nicht erfasst, steht als null:

snapshot:
  id: null                  # SHA-256 über den vereinheitlichten Inhalt, siehe Schritt 7
  taken: 2026-10-14         # Datum der Inventar-Lesung
system:
  model: "HPE ProLiant DL360 Gen9"
  bios: "P89 (29.08.2024)"
  hypervisor: "VMware ESXi 7.0 Update 3, Profil ESXi-7.0U3n-21930508-standard, Build 21930508"
processor:
  model_as_displayed: "Xeon E5-2699v4 @2,20GHz"
  logical_cpus_as_displayed: 44
  sockets_populated: null
  hyper_threading: null
memory:
  total_as_displayed: "223,87 GB"
  modules: null
power:
  supplies_installed: null
  power_profile: null

Zum DL380 Gen10 verzeichnet das Inventar nur, dass er existiert und welche iLO-Adresse bestätigt ist; ob Windows direkt darauf oder unter einem Hypervisor läuft, ist weiter offen. Ein Snapshot dort würde mit dieser Frage als erstem null beginnen.

Prüfliste

• Halte zu jedem Teil Modell, Firmware-Stand und relevante Einstellungen fest, und zu jedem Wert Quelle und Lesedatum.
• Nimm Werte aus maschinenlesbaren Lesungen (dmidecode, Redfish) und nutze Aufkleber und Datenblätter nur zum Gegenprüfen.
• Halte auseinander, was eingebaut ist und was die Maschine höchstens aufnehmen könnte.
• Notiere zu jedem Wert, ob er vom Host oder von einem Gast stammt.
• Schreibe unbekannte Werte als null und sage, was fehlt.
• Lege nach jeder Änderung an Teil, Firmware oder Einstellung einen neuen Snapshot an und behalte den alten.
• Lass Seriennummern, Adressen und Zugangsdaten aus allem weg, was du veröffentlichst.