v1.1.7

Enhancements

• proliant ilo inventory commands (firmware, memory, network, storage, servers) now fetch each group of components in a single request instead of one request per component — for example firmware inventory drops from 30 requests to 2 per server. Output is unchanged; the benefit is far less load on the iLO and a much lower chance of a command stalling on an iLO that intermittently pauses for several seconds. Automatically falls back to the previous behaviour on iLOs that don't support expanded queries.

---

v1.1.6

New Features

• proliant ilo network list/network describe <server name>, proliant oneview network list/network describe <server name>, proliant com network list/network describe <server name>: new fleet-wide and per-server host NIC inventory — location, port, MAC, link status, speed, and LLDP neighbor (where exposed) — matching the existing storage command pattern across all three modules.
• servers describe (ilo/oneview/com): now embeds a Network section (per-adapter, per-port host NIC detail) alongside the existing Storage section, best-effort — silently omitted if network inventory isn't available for that server.
• proliant ilo servers describe: also embeds a compact iLO NIC section (iLO's own dedicated management port: MAC, link, IPv4, DNS, LLDP) so the standalone --ilo-nic flag is no longer needed for a quick look.

Enhancements

• Consolidated iLO's previously inconsistent NIC entry points (nic-host, nic, nic-ilo, servers describe --ilo-nic, network set) into a single, storage-aligned pair: network (host NICs, list/describe) and network-ilo (iLO's own dedicated NIC, list/describe/set). Breaking change: nic-host, nic, nic-ilo, network set ..., and servers describe --ilo-nic have all been removed — use network list/network describe, network-ilo list/network-ilo describe/network-ilo set ..., and servers describe (Network/iLO NIC sections are now always shown) instead.

---

v1.1.5

New Features

• proliant com storage list/storage describe <server name>: new fleet-wide and per-server RAID controller / direct-attached disk inventory for COM-managed servers, matching proliant ilo storage and proliant oneview storage. Reads COM's own cached /servers/{id}/inventory mirror of each server's Redfish Storage data — no direct iLO network reachability or per-server iLO credentials required, only an authenticated proliant com login session.
• proliant com servers describe / proliant oneview servers describe: both now embed the same per-controller / per-disk Storage section (RAID Controller vs. Direct/HBA classification) that proliant ilo servers describe already showed — no need to run a separate storage describe to see disk detail. Best-effort: silently omitted if storage inventory isn't available for that server.

Bug Fixes

• storage list (all of ilo/oneview/com): fixed a N x ? phantom disk group showing up for empty/unpopulated drive bays — some Redfish Storage resources report a stub Drive entry (Status.State: "Absent") for a bay with nothing installed; these are now filtered out before counting/classifying disks.
• storage describe (all of ilo/oneview/com): the per-disk Capacity column now shows decimal GB (matching storage list) instead of GiB.

Enhancements

• storage list columns renamed: Disks Behind Controller → RAID Attached, Disks Direct-Connected → Direct Attached, matching standard industry terminology (DAS = Direct-Attached Storage). Disk group formatting simplified from (N x SIZE TYPE) to plain N x SIZE TYPE.
• storage list (all of ilo/oneview/com): when a server has more than one RAID/HBA controller, the Storage Controller and RAID Attached columns now line up one controller per row, so it's clear which disks sit behind which controller instead of merging them into one combined group.
• storage list: when a controller (or the direct-attached group) has multiple distinct disk sizes/types (e.g. an MR408i-o with 4x3201GB + 3x1920GB + 1x1600GB NVMe), each size/type now gets its own line instead of one long comma-joined line, so wide fleets stay readable in a narrow column.
• storage list output is now unified across ilo/oneview/com: all three now render the same plain fixed-width table (no title line, no box borders) that ilo storage list originally used — oneview/com previously used a bordered Rich table.

---

v1.1.4

New Features

• proliant oneview storage list/storage describe <server name>: new fleet-wide and per-server RAID controller / direct-attached disk inventory for OneView-managed servers, matching proliant ilo storage. Reads OneView's localStorageV2 sub-resource, which proxies the same Redfish Storage schema as iLO, so classification and formatting are identical across both modules.

Bug Fixes

• proliant oneview storage list: the Server column now shows the full server name (e.g. Enclosure-01, bay 1) instead of the shortened display form, so it can be copy-pasted directly into storage describe <name> without a "not found" error.
• Bash/zsh tab completion (Linux, macOS, WSL): completing a server/resource name with spaces or commas when multiple candidates still share a common prefix no longer inserts ugly \ / \, backslash-escapes — the shell now completes it as a single quoted token instead. Windows PowerShell completion was unaffected (already quoted correctly).

Enhancements

• proliant ilo storage list / proliant oneview storage list: disk sizes now shown in decimal GB (e.g. 2981GiB → 3201GB) instead of GiB, matching drive-vendor labeling, with (N x SIZE TYPE) spacing for readability. Storage controller names are trimmed to just the part number (e.g. HPE NS204i-u Gen11 Boot Controller → NS204i-u Gen11).

---

v1.1.3

Bug Fixes

• proliant ilo storage/servers (list, describe): fixed a misclassification where direct-attached NVMe drives were incorrectly reported as sitting behind a "RAID Controller" — HPE's Redfish Storage resources always expose a StorageControllers entry, even for direct-attached drives, describing the drive's own embedded NVMe controller chip rather than a real RAID/HBA product. Classification now uses the Redfish resource's Id prefix (DE* = genuine RDE-capable controller, DA* = Direct Attached) as the primary signal, with the old heuristic kept only as a fallback for older iLO firmware. Controller/firmware fields are no longer populated with a drive's own misleading part number for direct-attached disks, and controller counts shown in servers list ("N ctrl") and storage describe ("N controller(s)") now only count real RAID controllers.

Enhancements

• proliant ilo storage list: reworked into a fleet-wide table with Storage Controller, Disks Behind Controller, and Disks Direct-Connected columns per server, making it easy to see at a glance which servers have a real RAID/boot controller (with model) versus pure direct-attached NVMe/SSD storage.

---

v1.1.2

New Features

• proliant ilo storage describe <server name>: new focused storage command showing full per-controller / per-disk detail for a single server — RAID Controller vs. Direct/HBA classification, capacity, media type, protocol, model, serial, firmware, and health per drive. Previously this detail was only visible buried inside the much larger servers describe output; it's now also available on its own, mirroring the existing list/describe pattern used by servers and license.
• proliant ilo servers list: new Storage column showing a compact per-server summary (e.g. 2 ctrl, 8 disks: 6x1920GiB SSD(RAID), 2x480GiB SSD(Direct)), so fleet-wide storage layout is visible at a glance without needing to describe each server individually. Degrades gracefully to — if storage data can't be fetched for a given server.
• proliant ilo servers describe: now includes a Storage section per controller with the same full per-disk detail as storage describe.

Bug Fixes

• proliant version self-update: fixed a NameError: name 'headers' is not defined crash during the download step of the auto-update flow, plus a latent NameError: name 'urllib' is not defined that would have crashed immediately afterward. Both were caused by variables/imports that only existed in a separate helper function and didn't carry over into _run_update.

---

v1.1.1

New Features

• proliant ilo/com/oneview reports memory: added a Vendor P/N column showing each DIMM's raw manufacturer part number (e.g. HMA82GR7CJR4N-WM), alongside the existing HPE-branded part number — useful when a DIMM's HPE part number shows as Unknown (e.g. on a server with broken inventory collection that was never HPE-branded), since the vendor's own part number is still available and lets you identify the actual module. Rows are now also grouped by the combination of HPE + vendor part number, so distinct physical modules that both happen to show Unknown for their HPE part number are no longer merged into a single misleading row.
• proliant ilo/com/oneview reports memory and proliant ilo/com servers describe: added a Status column showing each DIMM's health (OK, or a flagged state like Degraded/ConfigurationError/MapOutError in red). HPE's iLO Redfish implementation does not expose the standard MemoryMetrics resource (confirmed via a live 404 probe), so no live correctable/uncorrectable ECC error count is available through Redfish or OneView on this hardware — DIMMStatus is the closest available health signal, so this surfaces it instead of silently discarding it as before. The fleet report groups by part number, so a flagged group shows which distinct problem status(es) occurred and which server(s) had them.
• proliant ilo servers describe / proliant com servers describe (direct-iLO only — not reachable for OneView/Synergy-managed servers, whose compute-module iLOs only expose a link-local management address): added a Memory Events (IML) section listing any memory-related entries from the iLO's Integrated Management Log, newest first. This is the actual mechanism HPE uses to record discrete corrected/uncorrected memory-error events (e.g. "Corrected Memory Error (Processor 1, DIMM 3)"), and is the closest real substitute for a live ECC error count.

Bug Fixes

• proliant ilo reports memory/cpu/gpu: dropped the redundant list action these needed (e.g. proliant ilo reports memory list) — every other proliant ilo/com/oneview fleet report runs directly as reports <name> with no extra action layer, since a report has nothing else it could do. proliant ilo reports memory (optionally with a single server name or --hosts-from FILE) now works the same way proliant com reports memory and proliant oneview reports memory always have.
• proliant oneview reports memory: the "Servers" column now shows each server's assigned server profile name first, falling back to the OneView hardware bay label (e.g. Enclosure-01, bay 6) only when no profile is assigned — confirmed live: one server showed as a literal localhost (its OS was never given a real hostname beyond the install default) and another showed a raw bay label instead of its actual profile name bay7-6820-cna. The report previously used each server's own OS-reported serverName, which can be blank or a meaningless default and doesn't match how the OneView GUI or the rest of the CLI identify a server.

---

v1.1.0

New Features

• proliant oneview activity: shows OneView's Activity feed — the named operations it ran (/rest/tasks: firmware updates, refreshes, background inventory collection) merged with health/condition alerts (/rest/alerts), newest first, mirroring the OneView GUI's Activity page (Name, Resource, Date, Duration, State, Owner). This is where a firmware update's real per-phase progress and, crucially, its actual failure reason show up. By default the feed lists only top-level operations (matching the GUI, which hides each operation's subtask tree behind an expander) and shows a live running-duration for in-progress tasks. Drill into an operation's nested subtask tree — the exact hierarchy the GUI shows when you expand a row, with each subtask's own state/percent and live phase text (e.g. "Stage firmware 80% completed", "Initiating loading of images on the interconnect / reboot") — with --tree [NAME], or live-follow a running operation until it finishes with --watch (refresh interval --interval SECONDS). This is the CLI equivalent of watching the GUI Activity page during a firmware rollout, so a multi-minute "Logical enclosure firmware update" no longer looks stuck at the parent task's flat 0% while its interconnects actually flash underneath. Filter the feed with --resource NAME (substring, e.g. LE01), --state STATE (e.g. Error), --limit N, --all-tasks (include subtasks), or restrict to --tasks-only/--alerts-only; --json for scripting. Inline resource references embedded in task/alert text are shown by name instead of raw {"name":…,"uri":…} JSON.
• proliant oneview update enclosure --concurrency N (--scope shared-infra-and-profiles only): submits up to N server-profile firmware updates at once instead of always one at a time. Default is 1 (unchanged, fully sequential) — researched against HPE's own tooling first: no official OneView REST API, PowerShell library, Python SDK, or Ansible collection updates server-profile firmware in bulk either, they all loop one profile at a time, so sequential remains the safe default. Profiles are submitted in waves of up to N; each wave's requests are polled to completion before the next wave starts. A failed/blocked/unverified profile does not stop later waves — each profile targets an independent physical server, so one server's firmware trouble has no bearing on whether the rest of the batch can still update safely (see the Bug Fixes entry below for why this matters even at the default N=1). The confirmation panel now also warns how many compute modules will power-cycle simultaneously when N > 1, and the live progress display shows one bar per in-flight profile instead of a single reused bar.
• proliant oneview server-profiles reapply <NAME>: the CLI equivalent of the OneView GUI's server-profile "Reapply configuration" action — fetches the profile's current, already-stored configuration and PUTs it straight back unmodified, making OneView reconcile whatever is actually out of sync on the live hardware (network/storage settings, BIOS, boot order, firmware consistency). This is what clears alerts like "Server hardware has been inserted into the enclosure bay — Resolution: Reapply the server profile" (e.g. after a hardware re-insertion or an eFuse power-cycle) without changing any profile setting. Prompts with a type-to-confirm safety gate before touching live hardware (skip with --yes); shows a live progress bar for the underlying task, same as update enclosure.
• proliant oneview update enclosure --scope profiles-only: updates just the targeted logical enclosure's server-profile compute firmware and skips the logical-enclosure/interconnect step entirely — no GUI equivalent (the GUI's "Update firmware" dialog always bundles shared infra in). Added after a live rollout got stuck with shared infra reporting "unverified" (OneView said the interconnect update completed, but it hadn't actually installed), which blocked all 6 pending server-profile firmware updates behind it indefinitely under the existing shared-infra-first ordering. A server-profile firmware PUT is its own independent OneView operation — not HPE-documented as depending on the LE rollout finishing — so profiles-only lets compute firmware proceed on its own schedule while the shared-infra issue is investigated separately.
• proliant oneview server-profiles update <NAME>: rolls out an SSP firmware baseline to one named server profile's compute module directly, without requiring (or touching) its logical enclosure at all — narrower than update enclosure --scope profiles-only, which still updates every profile under a given LE. Useful for bringing a single server current (e.g. right after an efuse/reapply) without waiting on or affecting its enclosure-mates. Shows the plan and applies directly (no separate --execute flag, unlike update enclosure) — gated by a plain yes/no confirm prompt (skip with --yes), plus the same baseline/install-type/force flags as update enclosure.

Bug Fixes

• proliant oneview update enclosure --scope profiles-only / --scope shared-infra-and-profiles: fixed a batch of server-profile firmware updates silently stopping after the first profile that failed/blocked/unverified, never even attempting the rest of the targeted profiles — confirmed live: a 6-profile profiles-only batch stopped dead after the first server's drive firmware hung and failed, leaving 5 completely unrelated servers untouched with no indication they'd been skipped. Each server profile targets an independent physical server, so one server's firmware trouble has no bearing on whether the others can still update safely — every targeted profile is now always attempted, and the result summary reports each failed/blocked/unverified profile individually (not just whichever one happened to be last) alongside how many succeeded normally. This applies at any --concurrency, including the default of 1.
• proliant oneview update enclosure --execute: a failed firmware update now shows OneView's own actionable error reason and remediation inline instead of an unhelpful "Check the OneView UI / 'proliant oneview reports'" (a command that has nothing to do with firmware). For example, forcing an update through a non-redundant fabric with --activation-mode parallel while the enclosure's compute modules are still powered on now reports OneView's real error — "…servers are currently powered on. Firmware update cannot be initiated until the listed servers within the logical enclosure are powered off." plus its "Power off the listed servers and retry" recommended action — pulled from the task's own taskErrors, and points you at the new proliant oneview activity for the full task detail.
• proliant oneview interconnects describe: fixed a misleading "Firmware baseline" line that showed the logical enclosure's assigned/target SSP as if it were already installed, even when the update had actually failed or was blocked (confirmed live: a blocked SY-2025.10.01 rollout kept showing as "Firmware baseline" long after the interconnect had never left its real SY-2023.05.01 baseline). Always shows the same three plain fields as the GUI's own "General" page — "Firmware baseline", "Firmware version from baseline", and "Installed firmware version" — with no separate "target"/"not yet applied" concept invented on top, now sourced from the Logical Interconnect's own actually-installed SPP tracking instead of the logical enclosure's request-only pointer; any mismatch between the baseline's version and what's installed is simply visible by comparing those two lines, exactly like the GUI.
• proliant oneview update enclosure --execute: fixed garbled/overlapping terminal output that could appear around the validation-warning "Proceed anyway despite this warning?" prompt and between targets. The live progress bar was being torn down and rebuilt from scratch for every target and every validation-warning retry; it's now a single persistent bar reused (reset in place) across the whole run and only actually stopped for the interactive prompt, matching Rich's supported pattern and avoiding the terminal corruption some terminals showed under the old repeated stop/start churn. Each finished target now also prints a permanent "✓ NAME updated." line so you have a written record even though the bar itself gets reused for the next target.
• proliant oneview update enclosure --execute: fixed a false "SSP apply complete. Updated N target(s)." reported for a logical-enclosure firmware update that OneView actually blocked and never applied. OneView reports this case as a Warning task at 100% ("firmware update was successful with warning") when a non-redundant fabric would be disrupted by the update — the CLI treated Warning as success unconditionally. It now re-checks whether the update actually landed before declaring success; the first pass of this fix compared the enclosure's own target-baseline pointer (which OneView sets immediately on request and never rolls back, so it still read "changed" even when blocked — the same root cause as the plan-phase bug below), so it's now cross-checked against each Logical Interconnect's actual installed SPP instead, same as the plan check. When they disagree, the CLI now shows OneView's real warning/resolution text and prompts to proceed anyway (see below) instead of silently reporting success.
• proliant oneview update enclosure: split "proceed through the non-disruptive-fabric validation warning" from "force-reinstall firmware" into two independent knobs (they were previously conflated, so confirming the warning always set forceInstallFirmware too). Clearing only the validation guard (validateIfLIFirmwareUpdateIsNonDisruptive) is the guard-only "proceed"; --force independently forces a reinstall and bypasses the guard up front. This is what makes the on-the-spot A/B choice below possible — proceed...

v1.0.36

New Features

• proliant oneview upgrade run: upload and stage an appliance software update image (.bin), then optionally install it. Pick an image interactively from a directory/share with --from-dir, or point at one with --image. Staging is the default; the reboot-inducing install is gated behind --execute plus a typed confirmation, and blocked when the readiness verdict is FAIL (override with --force).
• proliant oneview upgrade pending: show the currently staged appliance update.
• proliant oneview upgrade cancel: remove a stuck or aborted staged update.
• proliant oneview appliances describe [NAME]: show an appliance's General page — the active/standby Composer HA pair and their connection state, model, memory, per-node start time and uptime, firmware version/date, and the Composable Infrastructure Appliances inventory. Defaults to the active appliance; --json for scripting.
• proliant oneview firmware apply: roll out an SSP (Synergy Service Pack) firmware baseline that OneView orchestrates — shared infrastructure (logical enclosure: interconnects + frame link modules) and/or compute (server profiles), applied in that order. Pick a baseline with --baseline (defaults to the newest registered SSP) and a scope with --logical-enclosure/--all-enclosures and/or --server-profile/--all-profiles. The plan shows a source-backed OneView↔SSP compatibility note — whether the chosen SSP is recommended, supported, or not listed for the running OneView version (per HPE's Synergy Software Releases matrix), and warns before an unsupported apply. Default is a non-destructive plan; the hardware-rebooting apply is gated behind --execute plus a typed confirmation. The confirmation is scope-aware — an infrastructure-only apply states that no server profiles are included and compute modules will not be power-cycled. During --execute a live per-target progress bar tracks the underlying OneView task to completion, showing the current stage (e.g. "Update logical interconnect") and percent instead of returning the instant it starts.
• proliant oneview interconnects describe <name>: single-interconnect detail page matching OneView's GUI — General (logical interconnect, firmware baseline vs. installed version, management interface, stacking, IP addresses), Hardware (product, location, MAC, WWN, serial/part numbers, health), Interconnect Link Ports, Uplink Ports (type, speed, uplink set, connector, connected-to — showing the remote switch's actual hostname from LLDP, not just its chassis MAC like the GUI does), Downlink Ports (server hardware, adapter port, server profile — resolved from live port-neighbor wiring, not just profile assignment), live Utilization (CPU/memory/power/temperature), and Remote Support state.

Bug Fixes

• proliant oneview upgrade run --execute: fixed a false "Upgrade complete" that printed immediately when an install started. Progress is now read only from the appliance's own update-status feed, and completion is confirmed by the appliance actually rebooting onto the target build — not by a stale 100% left over from a prior firmware task.

Enhancements

• proliant oneview upgrade run: live progress display during long operations — a byte-level progress bar (size, speed, ETA) while the multi-GB image uploads, and a phase/percent bar while the appliance installs and reboots (e.g. "Swap active/standby nodes").
• proliant setup: adding a OneView appliance now prompts for a friendly alias (like the iLO flow), defaulting to the auto-generated oneview/oneview-2/… name so pressing Enter keeps the previous behavior.
• proliant ilo: removed the --raw flag (it had drifted inconsistent — a genuine unprocessed Redfish dump for some resources, but a no-op alias of the normal output for servers, serial, and license). --json is now the one consistent automation flag across ilo/com/oneview.

---

v1.0.35

Enhancements

• proliant oneview and proliant ilo: tab completion and --help now list each command only once. Removed the duplicate singular/plural and short-form aliases (e.g. server, repo, repositories, mem, check, appliance) that cluttered the completion menu — use the canonical command names shown in --help.

---