The HPE ProLiant DL380 Gen10 was HPE’s flagship 2U rack server through the 10th generation lifecycle (2017-2020), succeeding the DL380 Gen9 and continuing the line’s position as one of the highest-volume enterprise server platforms in the world. DL380 Gen10 systems deployed during that window are now 6-9 years old — not as deep into the failure curve as Gen9, but increasingly common in our caseload as the fleet ages and as NVMe-era components reach their wear thresholds.
The DL380 Gen10 represents a meaningful architectural shift from Gen9. The Smart Array controllers are an entirely different generation (MR-derived P408i-a / P816i-a / E208i-a rather than the P440ar lineage), iLO 4 was replaced by iLO 5 with Silicon Root of Trust security, NVMe became a default configuration rather than an optional add-on, and Intel Optane Persistent Memory introduced a new class of recoverable storage that lives on DIMMs rather than drives. This page covers what we see in DL380 Gen10 cases and what to do if yours is down.
DL380 Gen10-Specific Failure Patterns
Smart Array P408i-a controller behavior and metadata
The DL380 Gen10 most commonly shipped with the HPE Smart Array P408i-a embedded controller, a Broadcom MegaRAID-derived design that’s fundamentally different from the P440ar that preceded it. P408i-a metadata format, rebuild behavior, foreign configuration handling, and firmware update interactions all differ from earlier Smart Array generations. A common scenario: customers familiar with P440ar behavior assume the same troubleshooting steps work on P408i-a, and they don’t — the controller can produce subtly different states that look similar on the surface.
The P408i-a uses the term “Import Configuration” or “Foreign Configuration” rather than the older “Configuration Detected on Drives” phrasing. The destructive action is the same — clearing the foreign configuration permanently destroys array metadata — but customers who’ve worked with P440ar may not recognize the equivalent state.
NVMe failures and PCIe link errors
NVMe drives are the default storage tier in many DL380 Gen10 configurations — up to 24 U.2 NVMe drives in the densest SKUs. NVMe failure modes are different from spinning disks or SATA SSDs: PCIe link training failures, controller firmware bugs, namespace corruption, U.2 connector wear, and lane configuration mismatches that produce intermittent drive drops without obvious drive-level failure indicators. iLO 5 reports these through a different event family than traditional SAS / SATA failures, and customers troubleshooting NVMe issues sometimes don’t realize they’re looking at the wrong logs.
Common NVMe-specific symptoms on DL380 Gen10: drives intermittently disappearing from the OS, “PCIe Training Error” entries in the iLO IML, namespace UUIDs changing unexpectedly, or NVMe drives that show as present but unable to enumerate properly.
Silicon Root of Trust lockouts after firmware events
HPE Silicon Root of Trust is a Gen10-class security feature that verifies firmware integrity at boot — iLO, BIOS, Smart Array firmware, and other components are cryptographically signed and the SRT chain rejects unsigned or rolled-back firmware. When a firmware update goes wrong — failed SPP installation, rollback attempt, certificate issues, or an inconsistent state across components — SRT can lock the server from booting entirely. The data on the drives is unaffected, but the chassis itself becomes unable to boot until the firmware integrity issue is resolved.
This is a Gen10-specific scenario that didn’t exist in Gen9. The recovery workflow doesn’t care — we extract the drives and recover independently of the server’s ability to boot — but customers experiencing SRT lockouts often don’t realize the data itself is fine.
Persistent Memory (Optane DCPMM) recovery scenarios
The DL380 Gen10 supports Intel Optane DC Persistent Memory modules (DCPMM) in DIMM slots, in either Memory Mode (acts as large RAM) or App-Direct Mode (presents as persistent storage byte-addressable to applications). In App-Direct Mode, PMem-aware applications — SAP HANA, Redis Persistent Memory edition, certain databases, custom workloads — write data directly to the PMem modules. When the server fails, that data lives on the DIMMs rather than on the drives.
Recovery from a DL380 Gen10 with Optane in App-Direct Mode requires capturing the PMem state separately from the drives. If your DL380 Gen10 ran any PMem-aware workload, identify it upfront in the consultation — without the PMem modules, the drive contents alone may be inconsistent with the application’s expected state.
P408i-a firmware-related rebuild and import issues
The P408i-a firmware went through multiple revisions during the DL380 Gen10’s active production. Specific revisions have documented issues around rebuild handling, foreign configuration imports, and the interaction between Smart Array firmware and iLO 5. A common scenario: an array operating normally for years suddenly has issues after an SPP firmware update — logical drives not appearing correctly, rebuilds initiating but not completing, or unexpected foreign configuration prompts. Combined with Silicon Root of Trust verification, these issues can compound — a partial firmware update can leave both SRT and the Smart Array in inconsistent states.
iLO 5 federation and credential drift
iLO 5 introduced iLO Federation, allowing groups of servers to share authentication and management state. While this simplifies day-to-day operations, it creates new failure modes during recovery scenarios: federated authentication can fail when the federation master is unreachable, REST API tokens can expire unexpectedly, and credential drift across federated nodes can lock administrators out of individual servers. Active Directory integration issues compound the problem — an AD outage during business hours can produce iLO 5 lockouts across an entire federated fleet simultaneously.
Mixed SAS / SATA / NVMe array configurations
DL380 Gen10 chassis support mixed drive types in different sections of the front bezel — some SKUs ship with SAS drives in one section and NVMe in another, or SAS for primary storage with NVMe for caching. When failures occur on systems with mixed drive types, the recovery workflow needs to handle each tier separately. Customers sometimes don’t realize their server has mixed drive types until something fails on the NVMe tier and they discover the recovery process needs to account for it.
Critical DL380 Gen10 Error Conditions
Smart Array P408i-a / P816i-a POST and iLO Error Messages
| Error / Message | What it means | Data loss risk |
|---|---|---|
| Logical Drive in Interim Recovery Mode | One drive failed; redundancy is gone | Moderate — high if second drive fails before rebuild |
| Logical Drive Failed | More drives failed than RAID level can tolerate | Critical |
| Foreign Configuration Found / Import Configuration | Controller detected RAID metadata not matching current config — common after controller swap, drive migration, firmware update | Critical — wrong choice is irreversible |
| Rebuild Failed | Rebuild encountered unreadable sectors on surviving drives | Critical — data in affected stripes at risk |
| Cache Module Status: Permanent Error | Smart Array energy pack (battery/supercap) cannot reliably back up write cache | Moderate — data loss risk during power events |
| Energy Pack Status: Failed | Energy pack module replacement required to restore write-back cache | Moderate |
| PCIe Training Error (NVMe) | NVMe drive cannot establish PCIe link with controller | Moderate to High depending on drive role |
| NVMe Drive Removed / Not Present | NVMe drive disappeared from controller view — may be U.2 connector, link failure, or actual drive failure | Moderate to High |
| Silicon Root of Trust Verification Failed | Firmware integrity check failed at boot — server will not POST until resolved | Low directly — data on drives unaffected, but server unusable until SRT resolved |
| Persistent Memory Module: Uncorrectable Error | Optane DCPMM module reported uncorrectable error — PMem state may be inconsistent | Critical for PMem-aware workloads |
DL380 Gen10 Drive Carrier LED Patterns
The DL380 Gen10 uses updated drive carrier designs with revised LED behaviors. SAS / SATA carriers and NVMe carriers have slightly different LED conventions; this table covers both.
| LED Pattern | SAS / SATA meaning | NVMe meaning |
|---|---|---|
| Steady green | Drive online and active | Drive online and active |
| Slow flashing green (1 Hz) | Drive activity, or rebuild in progress — do not remove | Drive activity |
| Off | Drive ready for removal OR not detected | Drive ready for removal OR not detected |
| Steady amber | Drive has failed | Drive has failed or PCIe link error |
| Slow flashing amber | Predictive failure (SMART) — back up before replacing | Predictive failure / wear threshold approached |
| Alternating amber and green | Drive identify / locator activated | Drive identify / locator activated |
| Steady blue | Drive selected by management interface | Drive selected by management interface |
iLO 5 Integrated Management Log (IML) Events to Watch
| Event source | Meaning |
|---|---|
| Smart Storage — Logical Drive Status Change | Logical drive transitioned to Degraded, Failed, or Rebuilding |
| Smart Storage — Physical Drive Status Change | Drive transitioned to Failed, Predictive Failure, or Removed state |
| Smart Storage — Energy Pack Status | Energy pack (battery/supercap) state change |
| Smart Storage — Surface Analysis Error | Bad block detected during background surface scan |
| Smart Storage — Rebuild Failed | Rebuild attempt aborted due to errors |
| NVMe — PCIe Training Error | NVMe drive could not establish PCIe link |
| NVMe — Drive Removed | NVMe drive removed from PCIe enumeration |
| Security — Silicon Root of Trust Event | SRT firmware integrity verification result |
| Memory — Persistent Memory Module Error | Optane DCPMM module reported an error |
| System Environment — Fan / Temperature Threshold | Thermal or fan failure event |
The Active Health System (AHS) log in iLO 5 is significantly more detailed than the iLO 4 equivalent — it captures NVMe-specific events, Silicon Root of Trust verification history, persistent memory state, and federation activity in addition to the traditional storage and environmental data. For DL380 Gen10 recovery cases, the AHS log is often the deciding artifact in distinguishing between similar-looking failure modes. Download it from iLO 5 before doing anything else when possible.
How We Recover Failed DL380 Gen10 Servers
DL380 Gen10 recoveries follow our standard ProLiant recovery process with adaptations for the Gen10 architecture: free consultation, temporary hardware repairs in our ISO 5 cleanroom, write-blocked forensic imaging of every drive (including NVMe drives via appropriate U.2 imaging hardware), RAID or software-defined storage reconstruction with Hombre, and file system extraction.
For DL380 Gen10 cases specifically, our work involves the Smart Array P408i-a, P408i-p, P816i-a, E208i-a, S100i, and P408e-p controller families. The P408i-a’s MR-derived metadata format requires different reconstruction logic than the P440ar generation — we’ve developed dedicated tooling for the P408i-a family that handles its specific quirks around foreign configuration imports, rebuild interruption states, and energy pack interaction. The iLO 5 AHS log feeds into this process when available.
For DL380 Gen10 systems with NVMe drives, we image NVMe storage via U.2-compatible forensic imaging hardware. NVMe-specific failure modes — namespace corruption, PCIe link issues, controller firmware problems — have dedicated handling in our workflow. Mixed SAS/SATA/NVMe configurations are imaged per-tier and reconstructed in the combination the application expects.
For systems running with Persistent Memory in App-Direct mode, recovery extends beyond the drives to include the Optane DCPMM modules themselves. PMem state needs to be captured from the modules before the system is decommissioned — if the modules are removed and powered off too long, certain configurations can lose the persistence guarantee. Coordinate PMem handling in the consultation when applicable.
For Silicon Root of Trust lockouts where the server won’t boot, the recovery is straightforward from our side: we extract the drives and recover independently. The SRT issue prevents the chassis from booting but doesn’t affect what’s stored on the drives.
What to Do Right Now If Your DL380 Gen10 Is Failing
Don’t accept any “Import Configuration,” “Foreign Configuration Found,” or equivalent prompt without consultation. The P408i-a phrasing differs slightly from Gen9-era controllers, but the destructive potential is the same. One wrong click destroys array metadata irreversibly.
Don’t initiate a rebuild on a degraded array without verifying every surviving drive. Even though Gen10 fleets are younger than Gen9, drives in production for 6-9 years have accumulated wear — the AHS log should be checked for any predictive failure history before committing to a rebuild.
Don’t attempt firmware rollback on a system that’s already in a Silicon Root of Trust verification failure state. SRT lockouts often have a specific recovery path through HPE support that involves reflashing signed firmware — arbitrary rollback attempts can leave the system in worse states. If SRT is locking your DL380 Gen10 out of booting, the data on the drives is unaffected. Don’t prioritize fixing the chassis over preserving the drives.
For systems running Optane Persistent Memory in App-Direct mode, do not remove or reseat PMem modules without preserving their state. Optane DCPMM persists data on the modules themselves; mishandling them during recovery can lose data that the application expects to be available.
For NVMe-specific failures, distinguish between PCIe link errors and actual NVMe drive failures. PCIe training errors often resolve with a firm reseat of the U.2 connector, but only if the underlying issue is connector wear rather than drive failure. Don’t initiate aggressive replacement workflows without confirming the failure mode.
Don’t update iLO, BIOS, or Smart Array firmware while in a degraded or failed state. SPP firmware updates on stressed DL380 Gen10 systems can compound issues, especially when Silicon Root of Trust is involved.
Don’t clear the Smart Array energy pack module if dirty cache is reported. Clearing discards in-flight writes that may be the difference between a clean recovery and a corrupted file system.
Don’t run filesystem repair tools. NTFS chkdsk, ReFS integrity scrub, ESXi datastore repair, ext4 fsck, XFS repair, ZFS scrub on a degraded vdev — all can permanently alter metadata recovery depends on.
Download the iLO 5 AHS log if possible. The Gen10 AHS log is the most detailed diagnostic artifact HPE produces, and it’s often the deciding evidence in distinguishing between similar failure modes.
Document the controller model (P408i-a, P408i-p, P816i-a, E208i-a, S100i, P408e-p, H240, etc.), iLO 5 firmware version, server BIOS / ROM version, presence of NVMe drives or Optane PMem, OS or hypervisor version, and recent maintenance history.
DL380 Gen10 Configurations We’ve Recovered
- DL380 Gen10 8 LFF (8x 3.5″) running RAID 5 or RAID 6 (ADG) — file servers, backup repositories, video surveillance
- DL380 Gen10 12 LFF (12x 3.5″) running RAID 6 — large file storage, backup-to-disk, Veeam repositories
- DL380 Gen10 8 SFF (8x 2.5″) running RAID 10 — database servers, transaction-heavy workloads
- DL380 Gen10 16 SFF or 24 SFF (2.5″) running RAID 5 or RAID 10 — virtualization hosts and databases
- DL380 Gen10 with NVMe Express Bay configurations (up to 8 NVMe drives mixed with SAS)
- DL380 Gen10 all-NVMe configurations (24 U.2 NVMe drives) — high-performance database and analytics workloads
- DL380 Gen10 with Optane DC Persistent Memory in App-Direct Mode — SAP HANA, Redis Persistent Memory, custom PMem-aware databases
- DL380 Gen10 with Optane in Memory Mode — large-memory virtualization workloads
- DL380 Gen10 in HBA mode running Storage Spaces Direct (S2D) on Windows Server 2019 / 2022
- DL380 Gen10 in HBA mode running VMware vSAN on ESXi 6.7 / 7.0 / 8.0
- DL380 Gen10 running VMware ESXi 6.5, 6.7, 7.0, 8.0 with VMFS-5, VMFS-6, or vVol datastores
- DL380 Gen10 running Hyper-V on Windows Server 2019 / 2022 with NTFS or ReFS, including Cluster Shared Volumes
- DL380 Gen10 running enterprise Linux (RHEL 7/8/9, Ubuntu LTS, SUSE) with ext4, XFS, or ZFS
- DL380 Gen10 running Kubernetes, OpenShift, or Rancher as container hosts
- DL380 Gen10 connected to external D3xxx / D6xxx enclosures via P408e-p or P816i-a external controllers
- DL380 Gen10 as HPE SimpliVity hyperconverged nodes (where applicable)
- DL380 Gen10 as HPE dHCI (disaggregated HCI) compute nodes connected to Nimble or Alletra storage
Frequently Asked DL380 Gen10 Questions
My DL380 Gen10 is showing “Silicon Root of Trust Verification Failed” and won’t POST. Is my data lost?
No — the data on your drives is unaffected by SRT verification failures. SRT prevents the chassis from booting until firmware integrity is restored, but the storage subsystem and drive contents are independent. We can extract the drives and recover the data while the chassis itself is unbootable. Fixing the SRT issue is a separate problem you can address through HPE support; preserving the data shouldn’t wait on it.
My DL380 Gen10 ran SAP HANA with Optane Persistent Memory. The server crashed. What’s recoverable?
Both the drive contents and the PMem module state are relevant for SAP HANA recovery. We need access to both the drives and the Optane DCPMM modules to provide a consistent recovery. If your server crashed but the PMem modules are still intact, capture their state before doing anything else — particularly before any system maintenance or component swap that might disturb the modules.
My DL380 Gen10 P408i-a controller shows “Foreign Configuration Found” after I swapped the motherboard. What now?
This is one of the highest-risk prompts on a P408i-a. Importing the foreign configuration usually works, but clearing it permanently destroys the array. Importing can fail if the configuration is partially corrupted or if drives were moved across slots during the motherboard swap. Don’t make a choice yet — image the drives forensically first, then attempt import only after the originals are preserved. We can help walk through this if you call before clicking either option.
My DL380 Gen10 has all-NVMe configuration and one drive disappeared from iLO. Is it failed?
Possibly — but on NVMe drives, “disappeared” can also mean PCIe link training error (the drive is fine, but the link couldn’t establish), U.2 connector wear (intermittent enumeration), or NVMe controller firmware issue (drive is healthy but the controller-level state is broken). The IML and AHS log usually distinguish between these. Don’t replace the drive until the failure mode is confirmed — replacing a healthy drive that experienced a transient link error can cause more problems.
My DL380 Gen10 runs a vSAN cluster and the cluster is degraded. What does recovery look like?
Depends on the failure scope. If vSAN has tolerated the failure and the cluster is still serving data, recovery may focus on extracting specific objects that lived primarily on the failed node. If vSAN has lost more redundancy than the storage policy was designed to tolerate, we image the drives forensically and reconstruct from vSAN’s object metadata. vSAN on Gen10 hardware is common in mid-market and enterprise deployments — we work with these scenarios regularly.
I updated my DL380 Gen10 via SPP and now Silicon Root of Trust is flagging the new firmware as invalid. Help?
This is a known scenario when SPP delivers firmware versions that don’t match the SRT chain’s expectations. HPE support has a documented recovery process for this. From our perspective, the data on the drives is fine — we can recover independently of whether SRT can be resolved. If the firmware issue is blocking your operations and the data needs to be migrated to another system, that’s a natural use case for shipping us the drives while you work through the SRT resolution separately.
My DL380 Gen10 won’t POST — iLO 5 doesn’t respond, front panel shows amber. Can I still recover the data?
Yes. The data lives on the drives, not in the server. Even if the chassis is completely dead, removing the drives (including NVMe U.2 drives) in their original slot order and shipping them lets us reconstruct the array. Mark which drive came from which physical bay before removing anything. For NVMe drives specifically, handle U.2 connectors carefully — they’re sturdier than M.2 but still benefit from gentle extraction.
How can I tell if my server is a DL380 Gen9 or Gen10?
Several visual cues distinguish them: the Gen10 front bezel design is updated with a different status panel layout, the drive carriers have a different latch design (especially NVMe carriers, which don’t exist in significant numbers on Gen9), and the product label / service tag will show the generation. Gen10 product numbers typically start with 826564, 826565, 826566, 868703 (Gen10 Plus uses different numbers entirely), and others depending on SKU. A photograph of the front bezel and the service tag confirms the generation quickly.
My DL380 Gen10 has SED with controller-managed encryption. What’s recoverable?
With the encryption keys available (typically managed via iLO 5, HPE Secure Encryption, or an external key management server such as HPE Enterprise Secure Key Manager), the recovery works the same as non-encrypted arrays. Without the keys, the encrypted data is mathematically inaccessible. Gen10 systems sometimes use OPAL-compliant SEDs with keys managed by the application layer rather than the controller; discuss key-management specifics during your consultation.
Start Your Free DL380 Gen10 Recovery Consultation
If your HPE ProLiant DL380 Gen10 is down, get a free consultation with our server team. We’ll walk through your specific configuration — including NVMe, Persistent Memory, SRT state, and clustering — and tell you what’s possible.
Start Your Free DL380 Gen10 Consultation
Free consultation · Clear upfront pricing · ISO 5 cleanroom recovery
Or call 1-877-624-7206 to speak with our server team directly.