HP ProLiant DL380p Gen8 の轟音ファンを iLO4 アンロックファームで PID 制御して自宅運用可能にした
要旨
フォロワーから譲ってもらった HP ProLiant DL380p Gen8 (要するに中古機) を自宅ラックに入れたら、アイドル時から常時 50% 近いファン回転で、夏場は掃除機が部屋で常に動いてるようなレベルでうるさい。
これを kendallgoto/ilo4_unlock で iLO4 v2.77 をパッチして fan/pid SSH コマンドを露出させ、PWM 最低値と PID setpoint を調整することで、夜間でも気にならないレベル(体感ほぼ無音)まで静音化した。
- 環境: HP ProLiant DL380p Gen8 / iLO4 v2.77 (パッチ済) / Proxmox VE ホスト / Mac から SSH
- ポイント: 公式 iLO4 ファームには
fan/fan pidSSH コマンドは存在しない(隠しデバッグ実装)。パッチファームを焼いて初めて使える - アンロック対象は v2.77 が事実上の最終(v2.78 以降は HP が制御ユーティリティ自体を削除したのでパッチしても無意味)
- 設定は揮発するので reboot 後に自動再適用する仕組みが必須
背景: DL380p Gen8 を家のラックに入れた人類共通の悩み
DL380p Gen8 は 2012〜2015 年あたりに広く出回ったエンタープライズサーバ。中古市場で 2 万円台から手に入り、Xeon E5-26xx v2 × 2 + 大量メモリ + Smart Array P420i + SAS 10ベイで自宅サーバとしてのスペックは破格。仮想化基盤・NAS・録画機など何でも来い。
ただし音は地獄。エンタープライズ機は「冷えれば壊れない、うるさくてもいい」設計思想なので、デフォルトでファンが下がらない。HBA カード (P420i) が乗っていると iLO がそれを過剰に冷却しようとして、アイドル時でも全 8 ファンが PWM 100 前後 (≒40%) で常時回転する。
普通のオフィス・住居環境でこれを動かすのは無理。特に夏場は室温が上がるとファンが追従して回転を上げるので、さらに地獄になる。
既存策と限界
よく挙がる対策
- 物理的にファンを Noctua 等の静音モデルに換装 — DL380p Gen8 のファンコネクタは特殊なので変換ケーブル必須、しかも回転数フィードバック (tach) を偽装しないと iLO が「ファン異常」で全ファン全開になる
- 温度センサーを騙すパッチ済 iLO ファーム — 出所不明バイナリを焼くのでリスク大
- iLO4 の SSH 経由で
fan/fan pidを叩く — 一番安全で柔軟
3 が本命なのだが、ここで詰まる。
公式 iLO4 には fan/pid コマンドが「存在しない」
iLO4 の SSH に入って help を叩いても、fan / fan pid といったファン制御系コマンドは表示されない。実機で fan ? を叩いても応答ナシ。公式ファームでは出てこない。
これらは iLO4 ファーム内部にデバッグコマンドとして実装されてはいるが、外向きの CLI ハンドラには繋がっていない。HPE が意図的に非公開にしている、いわば「隠しコマンド」。
最初は素直に「iLO4 で fan 制御」「DL380p Gen8 静音化」あたりで Reddit (r/homelab, r/HomeServer) を漁っていて見つけたのが kendallgoto/ilo4_unlock — iLO4 ファームをパッチして隠しコマンドを CLI に露出させるツール。同じ DL380p Gen8 静音化スレッドで複数人が言及していたので「これだ」と当たりを付けて入った。
重要: パッチが効くのは iLO4 v2.77 (Dec 07 2020) まで。HP は v2.78 以降で
fan/pid等の制御ユーティリティ実装そのものを削除しているので、それより新しいバージョンにはパッチしても意味がない。v2.77 が事実上の最終解。
ハードルとブレークスルー
kendallgoto/ilo4_unlock のビルド
kendallgoto/ilo4_unlock は、Airbus SecLab の ilo4_toolbox によるリバースエンジニアリング成果をベースに、
- HPE 公式の iLO4 v2.77 ファームを build スクリプトが自動でダウンロード
- 内部の CLI ハンドラテーブルを書き換えて、隠しデバッグコマンド (
fan/fan pid含む) を露出させる - 整合性チェックを通るように再パックして書き戻し用
.binを吐く
という Docker ベースのビルドツール。手元では Debian 13 (trixie) 上でビルドした:
git clone --recurse-submodules https://github.com/kendallgoto/ilo4_unlock.git
cd ilo4_unlock
sudo docker build --network=host -o build .注意: --network=host を付けないと、Docker のブリッジネットワークから deb.debian.org の名前解決が失敗してビルドが落ちる。daemon.json に DNS を書いても効かなかった。--network=host が一番確実。
成功すると build/ 配下に以下が生成される:
ilo4_277.bin.patched— パッチ済ファーム (16MB)flash_ilo4— HPE 配布の ELF 書込ツール (i386 静的リンク)CP027911.xml— HPE パッケージのメタデータ
なお生成された .bin を ilo4_250.bin のような旧バージョン名にリネームして使う流れになっているのは、HPE 公式書込ツール (flash_ilo4) が CP027911.xml の宣言バージョン (v2.50) をチェックする実装になっているため。中身は v2.77 パッチ済。
書き込み: Web UI ではなく flash_ilo4 --direct
パッチ済ファームは iLO Web UI からはアップロードできない(署名検証で弾かれる)。HPE 配布の flash_ilo4 ELF を Linux ホスト上で直接実行する必要がある。
サーバ側で必要な物理手順:
- DIP スイッチ S1 を ON (iLO Security Override) — マザーボード上のスイッチ、フラッシュ時のみ必須
- AC ケーブルを完全に抜く — シャットダウンだけでは不十分。iLO は待機電源で動作しているので、AC 断しないと S1 の効果が反映されない。これを怠るとパッチコマンド自体が認識されない
- AC を戻して起動 → Linux (今回は Proxmox ホスト) にログイン
その上で:
# hpilo カーネルモジュールを外す (flash_ilo4 と排他)
sudo modprobe -r hpilo
chmod +x flash_ilo4
sudo ./flash_ilo4 --direct実測:
- ファームサイズ:
0x1000000 bytes(16MB) - 消去: 約 2 分
- 書き込み: 約 1 分
書き込み終了後、iLO を再起動 → AC 断 → DIP スイッチ S1 を OFF に戻す → 再起動。iLO Web UI で iLO 4 Advanced 2.77 Dec 07 2020 (パッチ済) を確認。
一つ罠だったのは、フラッシュ後に iLO の IP が DHCP に変わること。固定 IP の設定が部分的にリセットされる。フラッシュ前に IP メモして、後で再設定が必要。
iLO への SSH 鍵登録
fan / pid コマンドの大量適用を SSH スクリプトで回したいので、SSH 鍵認証を有効にする。
注意点:
- iLO は RSA 鍵のみ対応。ED25519 / ECDSA は使えない
- 鍵は iLO Web UI の Administration > User Administration > Administrator > Authorized SSH Keys から登録
- ペーストする鍵は OpenSSH 形式 (
ssh-rsa AAAA... user@host) でそのまま貼れる
Mac から iLO4 に SSH するときの罠
iLO4 はかなり古い SSH 鍵交換 / ホストキーアルゴリズムしか喋らない。Apple Silicon Mac の標準 OpenSSH からはそのままでは接続できず、明示的に古い algo を許可する必要がある:
ssh \
-oKexAlgorithms=+diffie-hellman-group14-sha1 \
-oHostKeyAlgorithms=+ssh-rsa \
-oPubkeyAcceptedKeyTypes=+ssh-rsa \
-i ~/.ssh/id_rsa \
Administrator@<iLO_IP>毎回これを打つのは面倒なので ~/.ssh/config に書いておく:
Host ssh-ilo
HostName 192.168.x.x
User Administrator
IdentityFile ~/.ssh/id_rsa
KexAlgorithms +diffie-hellman-group14-sha1
HostKeyAlgorithms +ssh-rsa
PubkeyAcceptedKeyTypes +ssh-rsaこれで ssh ssh-ilo "fan info g" のように一発で叩ける。
fan / fan pid のコマンド体系
パッチ済 iLO4 の SSH で利用可能になる主要コマンド:
| コマンド | 意味 |
|---|---|
fan p <fan_id> min <pwm> | ファン PWM 最低値の固定 (0-255) |
fan p <fan_id> lock <pwm> | ファンを指定 PWM に固定 (位置確認用に便利) |
fan pid <pid_id> lo <pwm> | PID コントローラの下限 PWM |
fan pid <pid_id> sp <value> | PID setpoint (低いほど閾値が緩い = 静か、100 倍スケールで 5500 = 55.00 ℃) |
fan info g | 現在の全ファン状態 (PWM、回転数) |
fan info t | 全 PID コントローラの状態 (setpoint、出力) |
fan g stop / fan g start | ファンコントローラの再初期化 (GPU 増設時の暴走対策に使う) |
fan_id は物理ファン 0〜7、pid_id は温度センサーと結びついた仮想 PID で 50 以上の番号がある。
fan 系コマンドは「返事を返さない」のが仕様
パッチ済 iLO4 で fan p 0 min 25 のような設定コマンドを叩くと、応答が空のまま Enter キーが返ってくる。設定コマンドだけでなく fan info g / fan info t のような参照コマンドも同様に空 で返ってくる。「効いてないのでは?」と最初は思うが、これは ilo4_unlock の実装上の仕様:
- 公式ファームの
null_cmdハンドラをバイナリパッチでfan系に置換しているため、出力ストリームの繋ぎ込みが省略されている - コマンド自体は正常に実行されている
- 出力が見える唯一の例外は iLO リセット (
reset /map1) 直後の最初の SSH セッション。一度抜けて再ログインするとまた空になる
つまり fan info で日常的に状態確認するのは現実的でない。実運用ではこうする:
- 設定が効いたかの確認は iLO Web UI の “Fans” / “Temperatures” 画面で見る (パッチ済でも Web UI のセンサー表示は正常)
- 回転音と温度の経過観察で十分判断できる (PWM 100→25 は耳で明確にわかる)
- どうしても CLI で詳細を見たい時だけ
reset /map1→ 即 SSH ログイン →fan info gのワンショットで取る
「設定コマンドは打ちっぱなしで OK、確認は Web UI」が一番運用が楽。
段階的な調整の試行錯誤
最初は素直に fan p 0 min 25 から fan p 7 min 25 まで全部下げた:
for i in 0 1 2 3 4 5 6 7; do
ssh ssh-ilo "fan p $i min 25"
done結果: HD Controller (P420i) が 65℃ → 84℃ まで上昇。fan 6 が HBA / HD コントローラ冷却専用位置にあったため。
最終的に落ち着いたのが以下の設定:
# fan 0-5, 7: min 25 (静か)
for i in 0 1 2 3 4 5 7; do
ssh ssh-ilo "fan p $i min 25"
done
# fan 6: min 80 (HDコントローラ冷却)
ssh ssh-ilo "fan p 6 min 80"これで fan 6 だけは少し回り続けるが、他の 7 機は完全に下げきれる。
PID 50 が「下げ切れない」ボトルネックだった話
fan p min をすべて 25 / fan 6 だけ 80 にした状態でも、全ファンの PWM が 97 前後で下がらない 状況が続いた。
reset /map1 直後の SSH ワンショットで fan info t を取って全 PID の状態を眺めると、PID 50 の setpoint が 36℃ で、温度センサーが 35℃ → PID 50 出力が 97 PWM という挙動。この PID 50 が他全部のファンを底上げしていた (前述の通り通常セッションでは fan info も空で返ってくるので、リセット直後の 1 回で取り切るのがコツ)。
# PID 50 の setpoint を 55℃ まで引き上げる
ssh ssh-ilo "fan pid 50 sp 5500"これで PWM が一気に底打ちした。原因がわかるまで時間がかかった部分。同様に過剰反応していた PID も上げる:
# PID 35: setpoint 40 → 52
ssh ssh-ilo "fan pid 35 sp 5200"
# PID 49, 46, 45: いずれも 55 まで引き上げ
ssh ssh-ilo "fan pid 49 sp 5500"
ssh ssh-ilo "fan pid 46 sp 5500"
ssh ssh-ilo "fan pid 45 sp 5500"PID 番号と物理的に何を見ているかの公式対応表は無いので、reset /map1 直後のワンショット fan info t で各 PID の温度値・出力 PWM・名称ヒントを取って「PWM が高すぎる PID から潰す」のが現実的な手順。
fan_info t の出力例(抜粋):
PID 50: sp 36 in 35 out 97 ← これがボトルネック
PID 35: sp 40 in 32 out 65
PID 45: sp 49 in 40 out 50
...PID コントローラ側の下限 PWM も全体に底上げ:
for i in 01 02 03 04 05 06 07 08 09 10 11 12 13 15 17 \
20 21 22 23 24 25 26 27 28 29 30 31 32 33 35 \
36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52; do
ssh ssh-ilo "fan pid $i lo 25"
doneOption Card センサー (PID 18-19) は status N にして無効化
リセット直後のワンショット fan info t で Option card does not support OCSD というコメント付きで PID 18 / 19 が status N (無効) になっているケースがある。これらは PCIe 増設カードが OCSD (Out-of-Band Card Sensor Data) をサポートしていない場合の温度センサーで、status N のまま放置しておく のが正解。下手に有効化しようとすると温度未取得 → 「異常」扱い → 全ファン全開になる遠因になる。
設定が reboot で揮発する問題
これらの fan 設定は iLO 再起動 / iLO ファーム更新 / サーバ AC 断で全消し になる。永続化フラグはファーム側に無い。
そこで 常時稼働の Proxmox ホスト (iLO と同じネットワークセグメントにある) の crontab に再適用スクリプトを仕込んでいる:
@reboot sleep 60 && /root/ilo4_fan_control.shスクリプトは SSH 用ホスト名 (上記 ssh-ilo) を引いて、3 セット (fan p min、pid lo、pid sp) を一気に再適用する形にまとめている。Proxmox 自体が落ちる時はそもそも全部落ちている時なので、起動順は気にしなくて良い。
結果
| 状態 | 体感 (主観) | HD Controller 温度 |
|---|---|---|
| パッチ前 (公式デフォルト) | 掃除機が常に部屋で動いてるレベル (夏場は特に酷い) | 65℃ |
fan p min のみ (fan 6 は 80) | PC ファン程度 | 84℃ |
fan pid sp も調整後 | ほぼ無音 | 84〜85℃ (Caution 105℃ なので十分余裕) |
CPU は CPU1 40℃ / CPU2 60℃ (VM 負荷の偏り、許容範囲)、Chipset 52℃、HD Cntlr Zone 48℃。深夜の長時間アイドル放置でも温度警告なし。
教訓
- 公式 iLO4 に
fan/fan pidSSH コマンドは無い。kendallgoto/ilo4_unlockでパッチファームを焼くのが唯一の SSH ルート - パッチ可能な最終バージョンは v2.77。v2.78 以降は HP がコマンド実装ごと削除している
- 書き込みは
flash_ilo4 --directのみ(Web UI 不可)。Linux ホスト + DIP S1 ON + AC 完全断 +modprobe -r hpiloが物理前提 fan系コマンド (設定もfan infoも) が応答返さないのは仕様。状態確認は Web UI の Fans/Temperatures 画面で行い、CLI で詳細を取りたい時だけreset /map1直後のワンショットで取る- PID 50 のような「過剰反応 PID」を最初に潰す。
fan p minだけでは下がらない - fan 6 (HBA 冷却) は下げすぎない。DL380p Gen8 の場合は最低 80
- Option Card センサー (status N) はそのまま放置。下手に有効化しようとすると暴走
- 設定は揮発するので reboot 後の自動再適用が必須。常時稼働の Linux 機 (今回は Proxmox 自体) の crontab で十分
よくある質問
公式 iLO4 のままで fan / fan pid SSH コマンドは使えない?
使えない。手元の v2.77 環境で確認しても、SSH の help には出ず、コマンドそのものを叩いても応答ナシ。一部のコミュニティで「古いバージョンでは出る」みたいな話を見かけるが、自分は試していない (パッチが安定動作したのでわざわざダウングレード検証する必要が無かった)。SSH 経由でファン制御したいなら ilo4_unlock 一択 と言って良い。
v2.78 / v2.79 / v3 系にパッチしたい
無理。HP は v2.78 以降で fan / pid 等の制御ユーティリティ実装そのものを削除している(コマンドハンドラだけ非公開だった v2.77 までと違って、コードが居ない)。v2.77 が事実上の最終解。
kendallgoto/ilo4_unlock のビルドはどれくらい大変?
Docker さえあれば README どおりで 1 コマンド。HPE 公式 v2.77 ファームは build.sh が自動 DL するので、入力ファイルの準備も不要。Docker のブリッジネットワークだと apt 更新で DNS 失敗する ので --network=host を必ず付けること。
iLO のフラッシュ手順で必須の物理作業は?
最低でも以下:
- マザーボード上の DIP スイッチ S1 を ON (iLO Security Override)
- AC ケーブルを完全に抜く(シャットダウンだけでは不十分、iLO は待機電源で生きている)
- AC を戻して起動 → Linux からフラッシュ → 完了後にもう一度 AC 断 → DIP S1 OFF
物理アクセスできない遠隔サーバには不可能な手順なので、最初から自宅機 / 物理アクセス可能機限定の手段と思って良い。
Web UI からのアップロードはなぜダメ?
Web UI は HPE 公式署名の検証を通すため、パッチ済ファームを拒否する。flash_ilo4 --direct は低レベルで SPI Flash に直接書くので署名検証を回避する。Web UI 由来の安心感は無いが、書込手順自体は確立されているので失敗例は少ない。
DL360p / DL360 Gen9 / DL380 Gen9 でも同じ?
iLO4 (Gen8) と iLO5 (Gen9 以降) ではファーム構造もコマンド体系も全く別。本記事の手順 (および ilo4_unlock) がそのまま使えるのは iLO4 (= Gen8 系列) のみ。Gen9 以降の iLO5 は別途調査が必要。
パッチファームのリスクは?
iLO4 は ASIC レベルで独立した管理プロセッサ (BMC) なので、書き換え失敗してもサーバ本体は普通に起動する。最悪ケースは iLO 管理機能が使えなくなるだけ。フラッシュ後の戻し (公式ファーム再書込) も flash_ilo4 --direct で同じ手順でできるので、「うまくいかなかったら戻す」運用は現実的。
ファン交換 (Noctua 化など) と比較してどっち?
| 比較軸 | iLO4 アンロック + PID 調整 | ファン物理交換 |
|---|---|---|
| 静音化レベル | 中〜強 (体感ほぼ無音まで可) | 強 |
| コスト | ゼロ (ソフトのみ) | 1〜2 万円 |
| 文鎮化リスク | 低 (iLO 再書込で復旧可) | 中 (tach 信号偽装失敗で警告止まらず) |
| 元に戻す難易度 | 公式ファーム再書込のみ | 物理工程必要 |
| 必要技能 | Docker + SSH + 物理 DIP 操作 | 電子工作 + 物理作業 |
まず PID 調整で試して、それでも気になるなら物理交換を追加、の二段戦略が無難。自分はパッチ + PID 調整だけで運用継続できている。
GPU (Tesla P4 等) を追加で挿したらどうなる?
iLO は標準で「HPE 認定外の PCIe カード」を温度センサー異常とみなしてファンを全開にすることがある。これに対しては fan g stop → fan g start でファンコントローラを再初期化する手筋がコミュニティで知られている (GTX1080 等の非 HPE GPU 挿入時の暴走対策)。本格運用するなら GPU 挿入後に再キャリブレーションが必要。
制作プロセスについて
kendallgoto/ilo4_unlock のビルド手順整理、Docker DNS の --network=host 解決、PID 50 ボトルネック発見、fan コマンドの空応答仕様の特定、温度の経過観察など、調査と試行錯誤のサイクルには Anthropic の Claude Code を活用した。実機への書き込み・物理 DIP 操作・温度監視・体感判断は当然人間が担当している。
