Ops Notes

HPE iLO 6 REST API Tutorial: From Redfish Rookie to Automation Ninja

Infrastructure Visualization

Stop Clicking the Web UI. The iLO 6 REST API Is Where Real Productivity Lives

I’m going to be blunt: if you’re still logging into the iLO web interface to check fan speeds or mount an ISO one server at a time, you’re wasting your life. I’ve seen ops guys with 200 ProLiant boxes literally clicking through browser tabs for an entire shift. It’s painful to watch.

HPE iLO 6’s RESTful API is built on the Redfish standard. This isn’t some HPE-proprietary hack — it’s a DMTF industry standard. Under the hood, it’s just HTTP verbs (GET, PUT, POST, DELETE, PATCH) talking JSON. Nothing fancy, but incredibly powerful when you chain them together.

Last month, a teammate needed to update BIOS settings on 30 DL380 Gen10s. Manual estimate: a full day. I wrote a Python script hitting the iLO 6 REST API. It finished before lunch. He spent the afternoon doing actual engineering work.

This tutorial skips the fluff. I’ll walk you through the real-world setup, the gotchas that’ll bite you, and the automation patterns that actually work in production.

Prerequisites: Don’t Skip This or You’ll Waste an Hour

Three things. Miss any one and you’re dead in the water:

  1. iLO Firmware: Must be iLO 6 version 2.00 or later. Older versions have different API paths and fewer endpoints. Check the version in the top-right of the iLO web UI.
  2. License: iLO Standard works for most basic operations. Advanced features like remote console recording or power monitoring need iLO Advanced or above. Check your license: GET /redfish/v1/Managers/1/LicenseService
  3. Network: Your management machine needs TCP/443 to reach the iLO management port. Sounds obvious, but I’ve debugged “API not responding” for 20 minutes only to find a firewall rule blocking the port.

Step 1: Hello World — Grab System Info

Fire up your terminal. iLO 6 has HTTPS enabled by default. Use -k to skip cert validation for testing (get a real cert for production).

curl -k -u "admin:your_password" \
  https://your-ilo-ip/redfish/v1/Systems/1

You’ll get a JSON blob back with the server model, serial number, CPU count, memory, etc. Something like:

{
  "Id": "1",
  "Name": "ProLiant DL380 Gen10",
  "Manufacturer": "HPE",
  "Model": "ProLiant DL380 Gen10",
  "SerialNumber": "USE1234ABC",
  "ProcessorSummary": {
    "Count": 2,
    "Model": "Intel(R) Xeon(R) Gold 6248R"
  },
  "MemorySummary": {
    "TotalSystemMemoryGiB": 384
  }
}

Gotcha: Don’t put the password directly in curl command history. Use -u "admin:$(cat /etc/iLO_pass)" or a .netrc file. Your future self (and your security auditor) will thank you.

Step 2: Understanding the iLO 6 API Structure

The API root is /redfish/v1/. Here are the resource nodes you’ll use most:

PathPurposeCommon Operations
/Systems/1Server system infoGET (view), PATCH (change boot order)
/Managers/1iLO self-managementGET (firmware version), PATCH (network config)
/Chassis/1Chassis hardwareGET (power, fans, temperature)
/Managers/1/VirtualMediaVirtual media drivesGET, POST (mount ISO)
/Managers/1/ActiveHealthSessionActive health checkGET (generate report)
/AccountService/AccountsUser account managementGET, POST, DELETE

Key insight: iLO 6’s Redfish API is session-based for stateful operations. You POST to create a session, get an X-Auth-Token back, and use that for subsequent requests. Don’t pass credentials every time.

Step 3: Session-Based Authentication — The Right Way

Passing username and password with every request is amateur hour. Here’s the proper flow:

# 1. Create a session, extract the token
TOKEN=$(curl -sk -X POST https://your-ilo-ip/redfish/v1/SessionService/Sessions \
  -H "Content-Type: application/json" \
  -d '{"UserName": "admin", "Password": "your_password"}' \
  | jq -r '.Token')

# 2. Use the token for subsequent requests
curl -sk https://your-ilo-ip/redfish/v1/Systems/1 \
  -H "X-Auth-Token: $TOKEN"

# 3. Delete the session when done
SESSION_URI=$(curl -sk https://your-ilo-ip/redfish/v1/SessionService/Sessions \
  -H "X-Auth-Token: $TOKEN" | jq -r '.Members[0]."@odata.id"')
curl -sk -X DELETE "$SESSION_URI" \
  -H "X-Auth-Token: $TOKEN"

Note: Default session timeout is 30 minutes of inactivity. You can tweak this under Managers/1/NetworkService.

Step 4: Real Work — Remote ISO Mount and OS Install

This is the killer use case. Mount an ISO from a network share, set the server to boot from it once, and power cycle.

import requests
import json

ILO_IP = "192.168.1.100"
USER = "admin"
PASS = "your_password"
ISO_URL = "http://192.168.1.200/iso/debian-12.iso"

# 1. Create session
session = requests.Session()
session.verify = False
resp = session.post(f"https://{ILO_IP}/redfish/v1/SessionService/Sessions",
                    json={"UserName": USER, "Password": PASS})
token = resp.headers.get("X-Auth-Token")
session.headers.update({"X-Auth-Token": token})

# 2. Insert virtual media
media_url = f"https://{ILO_IP}/redfish/v1/Managers/1/VirtualMedia/1/Actions/VirtualMedia.InsertMedia"
payload = {
    "Image": ISO_URL,
    "Inserted": True
}
resp = session.post(media_url, json=payload)
print(f"Insert media: {resp.status_code}")

# 3. Set one-time boot from virtual CD
boot_url = f"https://{ILO_IP}/redfish/v1/Systems/1"
boot_payload = {
    "Boot": {
        "BootSourceOverrideTarget": "Cd",
        "BootSourceOverrideEnabled": "Once"
    }
}
resp = session.patch(boot_url, json=boot_payload)
print(f"Set boot override: {resp.status_code}")

# 4. Force restart
reset_url = f"https://{ILO_IP}/redfish/v1/Systems/1/Actions/ComputerSystem.Reset"
reset_payload = {"ResetType": "ForceRestart"}
resp = session.post(reset_url, json=reset_payload)
print(f"Reset: {resp.status_code}")

# 5. Clean up
session.delete(f"https://{ILO_IP}/redfish/v1/SessionService/Sessions")

Critical gotcha: BootSourceOverrideTarget is case-sensitive. In iLO 6, Cd means virtual CD/DVD, Usb means virtual USB. I’ve seen people write CD (uppercase) and wonder why it didn’t work. It’s Cd, not CD.

Step 5: Bulk Hardware Health Check

When you manage 100 machines, you don’t log into each iLO individually. Script it.

#!/bin/bash
HOSTS=("ilo-01.example.com" "ilo-02.example.com" "ilo-03.example.com")
PASS="your_ilo_pass"

for host in "${HOSTS[@]}"; do
    echo "=== $host ==="
    # Power supply status
    curl -sk -u "admin:$PASS" \
      "https://$host/redfish/v1/Chassis/1/Power" \
      | jq '{PowerSupply: [.PowerSupplies[] | {Name, Status}]}'
    
    # Temperature sensors
    curl -sk -u "admin:$PASS" \
      "https://$host/redfish/v1/Chassis/1/Thermal" \
      | jq '{Temperatures: [.Temperatures[] | {Name, ReadingCelsius, Status}]}'
done

Real-world lesson: The Chassis/1/Power endpoint’s Status.State field can show Absent if a PSU is physically unplugged, even if the other PSU is fine and Status.Health shows OK. We had an alert that only checked Health == OK. One server had its second power cord dangling unplugged for three months. The health was still OK because the first PSU handled the load. We added a check on PowerSupplies[].Status.State == "Enabled" and caught it immediately.

Best Practices Quick Reference

ScenarioDo ThisDon’t Do This
AuthenticationCreate session, use TokenPass credentials with every request
Bulk operationsUse Python/Go with controlled concurrencySerial requests — painfully slow
Error handlingCheck HTTP status + parse error fieldAssume 200 means success
Virtual mediaUse HTTP direct URL for ISOUpload via iLO web UI (slow, flaky)
Firmware updatesUse UpdateService.SimpleUpdateManual download + upload
Audit loggingRegularly GET /Managers/1/LogServices/IEL/EntriesNever check logs until something breaks
SecurityInstall a proper certificate, use HTTPSSkip cert verification in production
Session managementDELETE when done, set reasonable timeoutCreate and forget — session leak

FAQ

Q: What’s the relationship between iLO 6 REST API and Redfish?

A: Redfish is the DMTF standard for RESTful server management. iLO 6 implements that standard. You can use generic Redfish clients (like redfishtool) or HPE’s ilorest CLI. They’re the same thing under the hood.

Q: How do I call the iLO 6 API from Python?

A: HPE provides python-ilorest-library, but honestly, I find it over-engineered. I prefer plain requests. The ISO mount example above shows the pattern. If you must use the official library: pip install python-ilorest-library. But I’d argue rolling your own is more maintainable.

Q: What’s the default port for the iLO RESTful API?

A: HTTPS defaults to 443. iLO 6 also supports a REST API over SSH (port 22), but that’s an HPE-proprietary protocol, not standard Redfish. Stick with HTTPS.

Q: How do I reset the iLO admin password if I’m locked out?

A: Physical access required. Press F8 during POST to enter the iLO System Configuration Utility, or boot from an HPE SPP (Service Pack for ProLiant) ISO and use the iLO configuration tool. Via API, if you have another admin account, PATCH /AccountService/Accounts/admin. If all admins are locked, there’s no API escape — you’re walking to the datacenter.

Wrapping Up

The iLO 6 REST API isn’t rocket science. It’s HTTP and JSON. But using it well separates the ops guys who spend their days clicking from the ones who write a script and go home early.

The most impressive thing I’ve seen? Someone wired iLO API calls into their CI/CD pipeline. Every deployment triggered an automatic ISO mount, PXE boot override, and OS reinstall. Zero human touch.

Stop clicking. Start scripting. Let the machines manage themselves.

References & Community Insights

The following authoritative resources were referenced for architectural best practices and specifications:

Elvin Hui

About the Author: Elvin Hui

Elvin is a Senior Infrastructure Engineer with 10+ years of experience spanning data centers, cloud-native architecture, and network security. Certified in CCNA and AWS Solutions Architecture, I focus on turning real-world production "war stories" into actionable, hardcore technical guides.