概要
仮想環境（VM）で稼働させているCentOS 5系のサーバーで、突然CPU負荷が急激に上昇するトラブルに遭遇しました。今回はその際の原因調査と、無事に解決に至った手順をふりかえりとしてまとめます。
突然のCPU負荷
平和だったサーバは一気に不穏な状況になりました
不審なプロセスが稼働しているのではないか、あるいはサーバが乗っ取られたのではないかとも疑いましたが、ほぼ同一環境の他のVMでも一斉にこのCPU負荷が発生していました。 更にはコンソールに以下のようなエラーが出力され、サーバの動作が完全に停止してしまいました。再起動を実施して一旦は解消したものの、サーバの根本的な設定に問題があることは明らかでした。
hda: dma_timer_expiry: dma status == 0x21
hda: DMA timeout error
hda: dma timeout error: status=0x50 { DriveReady SeekComplete }
hda: irq timeout: status=0xd0 { Busy }
ide0: reset: success
この DMA timeout error や irq timeout は、OSがハードディスクからの応答を待ってタイムアウトしている状態を示しています。物理サーバーであれば、「ハードディスクの寿命・物理故障」や「マザーボード・ケーブルの異常」を疑う、非常に心臓に悪いエラーです。
解決策：仮想ドライブの接続を「IDE」から「SATA」へ変更
VMの設定を確認すると、仮想ディスクの接続方式が古い「IDE」になっていました（ログに hda と出ているのがその証拠です）。
IDE（Integrated Drive Electronics）端子は、ひと昔前のパソコンでハードディスクやCD/DVDドライブなどをマザーボードに接続するために広く使われていた規格です。正式には「ATA」や、後継のSATAと区別するために「PATA（Parallel ATA）」とも呼ばれます。今のマザーボードやHDDではほぼ見かけなくなった、40本（ノートPC用は44本）のピンがずらりと並んでいるあの端子です。
該当のVM環境はリプレイス環境です。準備段階ではVirtIO BlockやSCSIで仮想HDDをマウントしようとしましたが、CentOS 5がそれらのドライバを持っておらずカーネルパニックを連発。それなら「うんと古いIDE形式ならば文句は言われないだろう」と考えて構築した際のしわ寄せが、今になって返ってきたというわけです。
とにかくIDEは古い規格のため、現在の仮想化ソフトが無理やりエミュレートしていることが多く、ディスクI/Oに負荷がかかると処理が詰まってタイムアウトを引き起こしがちです。 そこで、並行処理に強い「SATA」コントローラへ接続方式を変更することにしました。
懸念点：hda から sda へのデバイス名変更の壁
ここで一つ大きな懸念がありました。それは、OSが「CentOS 5」であることです。 IDEからSATAへ変更すると、Linux上でのデバイス認識名が /dev/hda から /dev/sda へ変わります。
古いカーネルの場合、SATAを読み込むためのドライバ（ahci など）が初期起動イメージ（initrd）に入っておらず、/etc/fstab のマウント指定も /dev/hda1 などに固定されていると、カーネルパニックを起こしてOSが立ち上がらなくなるリスクが高いのです。
結果：まさかの「勝手に切り替わって起動」
設定をSATAに変更していざ起動テスト。結果はあっけなく正常起動しました。 すんなりと起動してくれた理由は以下の2点のおかげでした。
- マウント設定が柔軟だった パーティションがLVMで管理されていたり、/etc/fstab で LABEL=/ のようにデバイス名に依存しない指定になっていたため、名前が変わってもOSが迷子になりませんでした。
- ドライバが既に存在していた 過去のアップデート等の影響か、汎用的なSATAドライバがすでに組み込まれており、VM側の仮想SATAコントローラを問題なく認識できました。
まとめ：仮想環境ではIDEの使用は避けるべし
無事にSATA接続へ変更できたことで、ディスクI/Oの詰まりが解消され、同様の現象は今のところ発生していません。
【今回の教訓】
- 仮想マシンのディスク接続に「IDE」を使うと、エミュレーションの負荷が高くなり不安定になりやすい。
- 古いOSであっても、仮想化環境では可能な限り「SATA」のようなパフォーマンスと安定性に優れた規格を使用するべき。
