こんにちは、キクです。
先日のとある作業でのできごと。
僕はESXiホスト上で稼働している仮想マシンの構成変更をするために「ゲストOSのシャットダウン」を実施しました。
「設定の編集」から仮想マシンの構成を変更し、仮想マシンを起動をしようと思ったのですが起動に失敗してしまいました。
なんで・・・。
また、ESXiホストではエラーコード「BC:3118」というものが発生していることに気が付きました。
なんだこのエラーは・・・?
仮想マシンの起動もできないし・・・。
そんな状態だったので調査を進めていきました。
結果としては無事に解消することができたので、記録として記事を書いておこうと思います。
というわけで、今回は『エラーコード「BC:3118」』をテーマに書いていきたいと思います！
本記事の内容
それでは、よろしくお願いします。
エラーコード「BC:3118」について
今回遭遇したエラーコード「BC:3118」関連のログとしては次のようなものが出力されていました。
■vmkernelログ
ALERT:BC: 3118 File protectedlist closed with dirty buffers. Possible data loss.
WARNING:NFSLock: 4435: Cannot primary remove lockfile .lck-xxxxx : Permission denied.本アラートは権限などの問題で仮想マシンファイルにアクセスできないことで発生しています。
また、NFSストレージへのアクセスで「Permission denied」が発生していることからNFS側の権限設定が怪しいと考えられます。
■hostdログ
DISKLIB-LINK: "/vmfs/volumes/xxxx/仮想マシン名/仮想マシン名.vmdk" : failed to open (Insufficient permission to access file).vmkernelログに加えて、仮想マシンへのアクセスも「Insuffient permission to access the file」が発生しており、ファイルオープンが失敗していることが分かります。
Googleにて「BC:3118」で検索をすると、真っ先にヒットしたのは以下のナレッジでした。
参考：High Availability fails when same NFS share is mounted multiple times using different IP address (81785)
こちらでは「同じNFS共有が異なるIPアドレスを使用して複数回マウントされる」などが原因となり発生するといった内容となります。
ONTAPでの設定上、1つのボリュームに複数のIPアドレスでマウントできる状態ではあったので最初はこの事象に該当するものと考えて調査をしていました。
しかし、結果としてはこの事象ではなく他の要因で発生しているということが分かりました。
エラーコード「BC:3118」発生前の環境説明
本節ではエラーコード「BC:3118」が発生する前の環境がどのようなものだったのかを説明したいと思います。
といっても至って普通の環境なのでサクッと進めていきます。
1. ホスト
・OSとして「ESXi 6.7」をインストールした物理サーバを利用
※IPアドレスは例として「192.168.1.10/24」で記載
2. ストレージ
・NetAppのストレージOS「ONTAP 9.8」で作成したボリュームを利用
・エクスポートポリシーで対象ホストのIPアドレス「192.168.1.10」を許可
▶︎ 本設定により対象ホスト(192.168.1.10)からのボリュームマウントが可能となる
3. 仮想マシン
・対象ホストから上記ボリュームをマウントした状態で作成した仮想マシンを利用
以上3点を図にすると次のような構成になっています。
エラーコード「BC:3118」が発覚するまでに実施した作業内容
以下の作業を実施しました。
少し余談になりますが、上記の作業はONTAP9.8のストレージ機器の初期構築時に、以下の動作を確認するために実施したものになります。
そんな観点から作業を実施しました。
ちなみに本節のタイトルが「発覚」となっていますが、これには理由があります。
後から分かったことですが、エラーコード「BC:3118」は「1. NFSストレージ側でのエクスポート設定変更の実施」の時点で発生していました。
しかし、この作業を実施していた理由は「他のホストからも同ボリュームをマウントできるようにすること」であり、それ自体は問題なくできていたため見落としてしまっていたのです・・・。
確認不足ですね。
そして「2. 仮想マシンの構成変更」の中で仮想マシンを再起動しようとしたら起動ができず、その時点で問題が発覚したという経緯になります。
ちなみに仮想マシン側で発生したエラーは次のようなものになります。
Unable to enumerate all disk. ファイルにアクセスするための適切な権限がありませんESXiホストと同様に、仮想マシンでもアクセス権限についてのエラーが出漁腐れていることが分かります。
エラーコード「BC:3118」が発生した原因
既に触れていますが、エラーコード「BC:3118」はストレージ側のエクスポート設定変更作業の時点で発生していました。
したがって「原因はエクスポート設定変更作業にある可能性が高い」と考えられます。
しかし、これまでもボリュームマウント対象ホストの追加のためにエクスポートポリシーを変更する作業は何度も実施していました。
それにも関わらず今回に限ってエラーが発生してしまいました。
なぜなのか・・・？
その原因は「ONTAPのGUI操作での仕様変更」にあることが分かりました。
直接的に関係していたのは、エクスポートポリシーのルール設定時に扱うことができる「スーパーユーザアクセスを許可」という項目。
設定変更前には同項目を「sys」と設定していました。
これはスーパーユーザアクセスを許可することを意味しています。
しかし、エクスポート設定変更作業後には「none」になってしまっていたのです。
スーパーユーザアクセスが無効化されてしまったことで仮想マシンファイルへのアクセス権がなくなり、結果としてエラーコード「BC:3118」に繋がったというのが一連の流れということになります。
ではなぜスーパーユーザアクセスが無効化されてしまったのか。
調査を進めていく中で「GUI操作時の「スーパーユーザアクセスを許可」のチェックあり/なしの持つ意味が変更されている」ということが分かりました。
以下の図の赤枠部分が該当の項目となります。
「チェックあり/なしの意味が変更されている」とはどういうことなのか、もう少し深堀りしていきます。
ONTAP9.8においては、チェックの有無が次のような意味を持つことが分かりました。
一方で、ONTAP9.1のような古いバージョンでは、「スーパーユーザのアクセスを許可する」という項目の下に次のような注意書きがありました。
スーパーユーザアクセスの設定：UNIXすべて設定するには、「スーパーユーザのアクセスを許可する」をオンにしてください。
これはつまり、チェックを入れた場合には「any」を設定するが、チェックを入れていない場合には特に何もしないと読み取ることができます。
これまではGUI操作で同項目にチェックが入っていなくても特に気にすることはありませんでしたが、ONTAP9.8ではチェックがないことで「none」が設定されてしまうようになってしまっていたんですね。
これは盲点でした・・・。
でもGUIから作業をする場合は毎回スーパーユーザアクセスを無効にしてしまう恐れがあるというのは正直言って「恐ろしいなー。」という印象が強いですね。
今回はテスト的な動作確認だったので問題なかったですが、本番環境のボリュームでやってしまったら多くの仮想マシンに影響が出てしまいますからね・・・。
エラーコード「BC:3118」発生後の対応
上記の通り「スーパーユーザアクセスの許可」が外れてしまったことが原因なので、解消方法としては再度許可してあげればいいだけでした。
しかし既に触れている通り、GUIで同項目にチェックを入れた場合には「sys」ではなく「any」という値で設定されてしまうので注意が必要です。
これは「作業前はany以外の設定をしていた」というような場合には作業前後で設定値が変わってしまうことになります。
そのため、作業前後で同じ設定をするためにはCLI操作で明示的に指定してあげるのが確実というのが現在の僕の認識です。
おまけ：エラー解消までに試して躓いたこと
おまけという名の「備忘録」を少し書かせてください。
エラーコード「BC:3118」発生後、調査のために検証環境で再現性があるかどうかを確認するためにボリュームをマウント中のホストを許可しているエクスポートポリシーで「スーパーユーザアクセスを許可」を意図的に無効化してみました。
しかし、そこでは「BC:3118」は発生しなかったんですね。
今思えば当然なのですが、そのときは「なんでだ？」となりました。
本記事でも触れている通り、エラーコード「BC:3118」は仮想マシンファイルにアクセスできなくなることで発生するものということが分かりました。
裏を返せばホスト上に仮想マシンが存在しなければ発生はしないんですね。
検証環境ではホスト上に仮想マシンがいなかったため、スーパーユーザアクセスを無効化しても「BC:3118」は発生しなかったということです。
納得です。
おわりに
いかがだったでしょうか。
今回はエラーコード「BC:3118」に遭遇した話についてでした。
作業内容としてはいつもと同じなのに思いがけずエラーが発生するというのはドキッとする体験でした。
しかしバージョンが異なることによる仕様変更の影響を気にかけるいい経験になりました。
「いつも通りの作業だから」と油断せず、1つ1つの項目に問題がないかを確認することが大切であると再認識しました。
本記事を最後までお読みいただきありがとうございました。
ではでは！