Monitor HPE iLO with VCF Operations and Redfish

Compatibility

The design was built for best-effort iLO 4 through iLO 7 Redfish compatibility, but it has only been tested on an HPE ProLiant DL360 Gen9 with iLO 4 firmware 2.82. iLO 5, 6 and 7 mappings were reviewed against HPE emulator data and could not be verified on physical hardware. iLO 1 through 3 and non-Redfish firmware are outside scope. This is a community project, not an HPE or Broadcom certified management pack.

What it collects

• Server model, serial, UUID, BIOS, health, power, processor and memory summaries
• iLO controller firmware, identity, license and state
• Processors and DIMMs with capacity, speed and health data
• Storage controllers, logical drives and physical drives
• Fans, temperature sensors and power supplies
• Installed firmware components and versions
• Integrated Management Log and iLO Event Log mappings, subject to the event limitations below

Topology design

Many iLO component responses do not repeat the ComputerSystem UUID. The pack uses a constant relationship match within its single-server collection model. Configure one iLO endpoint per adapter account. The revised live topology linked all 91 components to the server. This single-account result does not establish multi-server aggregation or cross-account isolation.

Deployment

1. Download the reviewed Builder JSON and read the deployment guide. It is not a standalone .pak.
2. Import it under Build > Developer Center > Management Pack Builder. Builder rejects duplicate design names; preserve and update an existing design in place instead of uninstalling it merely to resolve a name conflict.
3. Configure the collector, hostname, HTTPS port and dedicated credentials with the minimum required Redfish read access.
4. Keep TLS verification enabled and fix CA trust, SAN matching and DNS if validation fails.
5. Test every request, then run a full Builder collection and inspect the log, objects and server relationships.
6. Install or upgrade the pack and configure one runtime account per iLO endpoint.
7. Confirm that scheduled timestamps continue to advance before relying on monitoring.

Operational cautions

Missing data is unknown, not healthy. Gate temperature alerts on sensor state and validity: the tested server exposed a physical-drive reading of 255 C with a maximum of 0 C, which appears to be an unavailable-value sentinel and should not be treated as confirmed overheating. Do not alert on zero fan speed without power and health context, and do not treat an absent redundant power-supply bay as an automatic failure.

Collection health remains a limitation. When Fan Health was omitted, Operations retained the previous Critical value and alert. Data receiving and zero no-data counts did not reliably expose partial endpoint failures. Check current timestamps, metric counts and request errors before treating a stored health value as current.

What the latest tests established

Controlled tests changed response copies delivered to the existing native collector through a temporary relay. They did not damage hardware, change the hardware logs or prove detection of a physical failure. HTTP 503, HTTP 404, timeout and changed untrusted-certificate cases were exercised, followed by collection recovery. The account is back on direct HTTPS with verification enabled, and the test relay has been stopped.

The fan test produced one correctly associated Critical alert without a duplicate server alert, then became Inactive after three healthy collections. The absent power-supply guard and offline-temperature handling and recovery passed. Basic IML event creation, unchanged-delivery deduplication and explicit-repair clearing also passed; the repaired event canceled after three cycles.

Alerts and dashboard

Nine hardware-health alert definitions and an HPE dashboard with six collection diagnostic charts were configured separately in the lab. Fan and temperature health alerts require Warning or Critical health together with Enabled state; the power-supply rule also uses an Enabled-state guard. Maintenance suppression was verified.

These alerts and the dashboard are not bundled in the Builder JSON. Chrome blocked the native content export, so separate content import and rollback were not verified. Downloading the design does not install this additional operational content.

Known limitations at this checkpoint

• Collection and alerts: explicit unknown or stale health handling remains incomplete. Scheduled server power-off/transition testing and certificate hostname-mismatch rejection remain unverified. Rejecting a changed untrusted certificate does not establish hostname validation.
• Release content: native dashboard and alert export/import and rollback remain unverified. The download is a Builder design, not a standalone package or complete content bundle.
• IML lifecycle: missing Repaired metadata caused a test event to be omitted in two collections. Changing Created alone did not distinguish a new event generation. One later labeled synthetic test event remained uncanceled after four direct recovery cycles; its cause is unproven. Hardware logs were untouched.

An SDK feasibility prototype passed seven offline tests, but no SDK pack or cloud proxy was deployed. Durable event storage, native SDK behavior, and preservation of the existing account, objects and history during SDK migration remain unverified. The SDK work was investigation only and is not part of the published download.

The validation summary on GitHub records the completed checks and remaining limitations. Further work is paused; these limitations are not commitments to future development.