Updated Updated: September 14, 2026

Server Inventory Methodology#

Purpose#

This method is used to create a complete, insurance-focused physical hardware inventory for every server. Every server must use the same collection order, the same checks, and the same note structure. A server is not considered complete because one source was inspected; all three methods must be attempted.

The inventory covers the physical server and its replaceable or insurable components only. Virtual machines, containers, software configuration, operating-system runtime metrics, temperatures, link state, drivers, PCI addresses, and firmware details are excluded unless they directly identify an insurable hardware component.

Required order#

  1. iLO or equivalent out-of-band management interface
  2. Read-only SSH hardware inspection
  3. Proxmox MCP read-only inspection

The order matters: iLO is the authoritative source for HPE chassis and component identity; SSH provides host-level confirmation and details unavailable in iLO; Proxmox provides virtualization-host and storage context and acts as a cross-check. Conflicting values must be recorded only after comparing the sources, with the manufacturer-rated or component-identifying value preferred for insurance.

Method 1 — iLO / out-of-band management#

1.1 Access and identity#

Open the server’s iLO address and confirm the target hostname before collecting anything. Record:

  • Product name and server model
  • Manufacturer
  • Server serial number
  • Product number / SKU
  • UUID, when useful for identity
  • iLO hostname and IP address
  • iLO firmware and license type
  • Physical location

1.2 Required iLO pages#

Inspect every relevant page, not only the Overview page:

  • Information → Overview: identity, serial, product number, overall health, power state, TPM and internal media presence
  • Information → System Information → Summary: subsystem health, fan redundancy, power redundancy, storage status, and energy-pack status
  • Information → System Information → Processors: every socket, CPU model, cores, threads, and identifiers exposed
  • Information → System Information → Memory: every populated DIMM slot, capacity, type, speed, manufacturer, part number, serial number, and ECC status
  • Information → System Information → Network: physical network adapters and ports, model, MAC addresses, and identifiers exposed
  • Information → System Information → Device Inventory: embedded devices, PCIe cards, controllers, graphics, and other physical components
  • Information → System Information → Storage: every physical drive, bay, model, capacity, interface, serial number, controller, and backplane information
  • Power & Thermal → Server Power: power state only; do not press any power controls
  • Power & Thermal → Power: every PSU, position, model, wattage, serial number, and redundancy state
  • Power & Thermal → Fans: fan assemblies and redundancy; omit RPM and transient operating readings
  • Power & Thermal → Temperatures: use only if needed to identify a hardware component; omit routine temperature readings
  • Information → iLO Event Log / Integrated Management Log: inspect only for persistent hardware identity or component fault information relevant to insurance

No buttons that change power, settings, firmware, configuration, or logs may be pressed.

1.3 iLO completeness rule#

Do not leave a section blank until the corresponding iLO page has been inspected. If the page exposes no value, leave the field blank. Do not write comments such as “confirmed via iLO” in inventory tables.

After every navigation action, verify that the expected page title and content are visible before recording results. A click or navigation attempt that leaves the previous page displayed does not count as an inspection. For HPE iLO, use the page’s System Information and Power & Thermal tabs, including the nested page content, rather than relying on the Overview page alone.

The energy-pack row in the System Information Summary is a required check. If it is present, inspect the Power page or the corresponding detailed component view and record its model, spare part number, serial number, capacity/type, and firmware when exposed.

Method 2 — read-only SSH hardware inspection#

Connect to the server as root using a non-interactive, bounded SSH session. Commands must be read-only and must not start tests, install packages, modify configuration, reboot, power-cycle, or change storage.

2.1 Identity, chassis, CPU, memory, storage, and PCIe commands#

Use the following command as the baseline, replacing the address. The output must be verified for errors before using it. Shell quoting or platform-specific awk behavior may cause one subsection to fail; a failed subsection is not a completed check.

ssh -o BatchMode=yes -o ConnectTimeout=10 root@10.1.1.13 'printf "[system]\\n"; dmidecode -t system -t chassis -t baseboard; printf "[cpu]\\n"; lscpu | awk -F: "/Model name|Socket\\(s\\)|Core\\(s\\) per socket|Thread\\(s\\) per core/ {gsub(/^ +/,"",$2); print $1": "$2}"; printf "[memory]\\n"; dmidecode -t memory | awk -F: "/Memory Device|Size:|Type:|Speed:|Manufacturer:|Part Number:|Serial Number:/ {gsub(/^ +/,"",$2); print $1": "$2}"; printf "[disks]\\n"; lsblk -d -o NAME,MODEL,SERIAL,SIZE,ROTA,TRAN; printf "[pci]\\n"; lspci -nn | egrep -i "ethernet|network|raid|sas|scsi|nvme|fibre|display|vga|serial bus"'

Replace the address with the target server. Collect and normalize:

  • DMI system, chassis, and baseboard manufacturer, model, serial, SKU, UUID, form factor, rack height, and power-cord count
  • CPU socket count, model, cores, threads, and rated speed
  • Every populated DIMM, including capacity, type, speed, ECC, manufacturer, part number, and serial
  • Every physical disk, including manufacturer, model, marketed capacity, interface, serial, and drive type
  • Storage controllers, HBAs, RAID adapters, cache-protection hardware, and backplanes
  • Physical network adapters and graphics adapters
  • PCIe expansion cards, but omit PCI bus addresses from the inventory note

Run the affected subsection separately if the combined command reports an error:

ssh -o BatchMode=yes -o ConnectTimeout=10 root@SERVER_IP 'lscpu | egrep "Model name|Socket|Core.*socket|Thread.*core"'
ssh -o BatchMode=yes -o ConnectTimeout=10 root@SERVER_IP 'dmidecode -t memory'
ssh -o BatchMode=yes -o ConnectTimeout=10 root@SERVER_IP 'dmidecode -t 39'
ssh -o BatchMode=yes -o ConnectTimeout=10 root@SERVER_IP 'ip -o link show'

The separate commands are required for CPU, memory, power-supply, and MAC-address confirmation when the combined command fails. dmidecode -t 39 is specifically required for PSU model, wattage, serial, status, and hot-replaceable information.

2.2 Additional read-only checks#

Use these only when a field is missing and the command is available. Do not install tools to obtain it:

dmidecode -t processor
dmidecode -t memory
dmidecode -t system -t chassis -t baseboard
lsblk -d -o NAME,MODEL,SERIAL,SIZE,ROTA,TRAN
lspci -nn

MAC addresses may be collected when they are needed as the device identifier, but interface names, drivers, link state, and firmware details are not inventory requirements.

The disk check must include all physical media exposed by the host, including SATA, SAS, NVMe, USB, and external/removable drives. Exclude virtual block devices such as zd*, VM disks, bridges, and tap interfaces from the physical inventory.

2.3 Capacity normalization#

Use manufacturer-rated decimal capacity in the inventory. For example, a disk reported by Linux as approximately 10.9T is a manufacturer-rated 12 TB drive. Do not replace marketed capacity with the operating system’s TiB-style display. Record the model and serial so the capacity can be verified.

Method 3 — Proxmox MCP#

Use only read-only Proxmox MCP tools after SSH. The MCP is a cross-check and source for Proxmox node identity, node status, storage inventory, bridges, and VM/container context. It is not a substitute for the physical inventory gathered from iLO and SSH.

3.1 Required read-only calls#

Use the target server’s own MCP namespace and node name. Do not substitute another server’s MCP namespace.

The read-only calls used during this inventory work include:

mcp__proxmox_hp1__proxmox_list_nodes({})
mcp__proxmox_hp1__proxmox_node_status({"node":"HP3Proxmox"})
mcp__proxmox_hp2__proxmox_list_nodes({})
mcp__proxmox_hp2__proxmox_node_status({"node":"HP2"})
mcp__proxmox_hp2__proxmox_list_storage({})
mcp__proxmox_hp2__proxmox_list_bridges({"node":"HP2"})
mcp__proxmox_hp2__proxmox_list_vms({"node":"HP2"})
mcp__proxmox_hp3__proxmox_list_nodes({})
mcp__proxmox_hp3__proxmox_node_status({"node":"HP3"})
mcp__proxmox_hp3__proxmox_list_storage({})
mcp__proxmox_hp3__proxmox_list_bridges({"node":"HP3"})
mcp__proxmox_hp3__proxmox_list_vms({"node":"HP3"})

MCP results must be classified accurately:

  • A successful node listing confirms that the MCP connection is available.
  • A node-status permission error means the MCP is connected but lacks the required permission; it is not an unavailable node.
  • An empty storage, bridge, or VM result is a valid empty result only when the call succeeds without an error.
  • A hostname-resolution or connection error means that call failed and must not be reported as successful data collection.

HP3 was initially queried through the HP1 MCP and failed because the wrong namespace was used. Once the HP3 namespace was available, proxmox_list_nodes and proxmox_node_status({"node":"HP3"}) succeeded. HP2 node listing succeeded, while its node-status call returned a permission error. These outcomes must be recorded in the work report, not silently omitted.

When the correct MCP connection is available for a target server, inspect:

  • Node identity and status
  • Physical storage and storage-controller presentation
  • Proxmox storage inventory
  • Network bridges only to identify physical network participation
  • VM/container inventory only as context; do not add virtual devices to the physical hardware inventory

Never use MCP tools that start, stop, reboot, migrate, clone, resize, delete, configure, update, or otherwise change a VM, container, node, storage pool, network, or host.

Identical note structure#

Every server note must contain the same headings and tables, even when fields are blank:

  1. Asset Summary
  2. Server Chassis
  3. Processors
  4. Memory
  5. Storage Drives
  6. Storage Controller / HBA
  7. PCIe Expansion Cards
  8. Network Hardware
  9. Power Supplies
  10. Cooling and Thermal Hardware
  11. Included Accessories
  12. Other Physical Devices
  13. Insurance Valuation
  14. Notes

Do not create a different table layout for one server. If detail is unavailable, retain the same columns and leave the value empty. Use manufacturer-rated capacity, not OS-reported TiB-style capacity. Do not add source/provenance comments inside component lists.

Identical means the same headings, table columns, row categories, and accessory fields. A summary row must not replace individual DIMM or drive rows when the source exposes individual components. If a source does not expose a value, keep the row and leave only that field blank. Before completion, compare the target note against the HP1 note section-by-section.

Completion checklist for each server#

  • Correct server and management address confirmed
  • iLO / equivalent Overview inspected
  • iLO System Information Summary inspected
  • Processors page inspected
  • Memory page inspected slot-by-slot
  • Network page inspected
  • Device Inventory page inspected
  • Storage page inspected drive-by-drive
  • Power Supplies page inspected PSU-by-PSU
  • Fans and relevant physical cooling information inspected
  • Read-only SSH DMI inventory completed
  • Read-only disk inventory completed
  • Read-only PCIe inventory completed
  • Proxmox MCP read-only calls attempted
  • Correct per-server MCP namespace and node name used
  • MCP success, empty results, and permission/connection failures classified correctly
  • Conflicts between sources resolved or left blank
  • PSU model, wattage, serial, redundancy, and hot-replaceable status checked
  • Smart Storage Energy Pack checked and recorded when present
  • Every physical SATA, SAS, NVMe, USB, and external drive accounted for
  • Accessory table matches the reference note exactly
  • All physical hardware sections populated or explicitly left blank
  • No virtual devices included as physical hardware
  • No hardware tests, benchmarks, stress tests, or power actions run
  • Target note compared field-by-field with the reference note
  • Note structure matches every other server note
Backward Network Equipment DockDash - App Release and Updates Forward