この疑問に回答します。
vCenterにアクセス出来なくなると「かなり焦ります」。マジで冷や汗たらたらです。こんな経験はもうしたくないので同じ境遇に陥った際に参考にしてください。
この記事の内容はこちら
- ゲストOSが立ち上がらない
- ゲストOSの起動は簡単
- vCenterの原因調査と障害対応 その1
- vCenterの原因調査と障害対応 その2
- vCenterの原因調査と障害対応 その3
ゲストOSが立ち上がらない
VCSA 6.0(vCenter Server Appliance)からゲストOSを起動させようとすると、エラーが出力され起動できませんでした。
とりあえずの再起動で様子見を行おうとしたら、vCenterにログイン出来なくなりました。
ここからが壮絶な戦いが始まりです。
ゲストOSの起動は簡単
このエラーばvCenterから出されるエラーなので、ゲストOSが乗っている VMware ESX Serve に直接アクセスすればゲストOSを起動することが可能です。
ゲストOSは、起動さえすればvCenterが動かなくても影響を受けませんので安心してください。ダウンタイムを減らすため、接続先を切り換えてゲストOSをすばやく起動させてください。
vCenterの原因調査と障害対応 その1
- ログ採取(vc-support)をブラウザから試みる
- ログ解析の結果、ディスクが枯渇していた
- “/storage/log”への対応
- “/”への対応
過去にもVMwar環境でトラブルが何度か起こりましたが、vCenterにはログイン出来たのでGUIで状態の確認から対応まで色々と行うことが出来ました。
今回はログインができないのでログ採取するできないので大変でした。
ログ採取(vc-support)をブラウザから試みる
ログは、Client、ブラウザ、CUI経由から取得が可能です。
今回は vSphere Client にアクセス出来ないので、Webブラウザから試みます
https://<vCenter Server Appliance>:443/appliance/support-bundle

無事に画面が表示されました。ログインが出来ればログを取得することが出来ます。
ログ解析の結果、ディスクが枯渇していた
vCenter Server Appliance の “/” と “/storage/log” が100%で容量が枯渇していました。
Filesystem 1K-blocks Used Available Use% Mounted on /dev/sda3 11215096 11215096 0 100% / udev 8233848 164 8233684 1% /dev tmpfs 8233848 36 8233812 1% /dev/shm /dev/sda1 130888 38224 85906 31% /boot /dev/mapper/core_vg-core 51597948 184648 48792272 1% /storage/core /dev/mapper/log_vg-log 10313016 10269820 0 100% /storage/log /dev/mapper/db_vg-db 10313016 1251148 8537992 13% /storage/db :
原因はこの2ヵ所のようです。
ファイルを削除するにはSSHを利用してコマンドラインから実行する必要があります。
コマンドラインからShellを実行するための手順はこちら
関連記事

“/storage/log”への対応
“/storage/log”はディレクトリ名からログが増えている事が簡単に想像できます。
/storage/log/vmware/cloudvm/cloudvm-ram-size.log の容量が1.8GBに肥大化していました。
このcloudvm-ram-size.logファイルはログローテーションの構成が行われていないため、ローテーションされずに肥大化するようです。
cloudvm-ram-size.log ファイルのログ ローテーションが機能しない (2149154)
1. vCenter Server Appliance にSSHを利用してログインします。 2. シェルを起動します shell.set --enabled True shell 3. /etc/logrotate.d/cloudvm_ram_size.log ファイルを作成します。 /storage/log/vmware/cloudvm/cloudvm-ram-size.log{ missingok notifempty compress size 20k monthly create 0660 root cis } 4. ログ ローテーションを実行します。 logrotate -f /etc/logrotate.conf ※いくつかエラーが表示される場合がありますが、無視してかまいません。
関連情報
別のログファイルが肥大する場合もあります。
vCenter Server Appliance の /storage/log ディレクトリがいっぱいになる (2143565)
“/”への対応
何でしょうか “/” が一杯になっても動くOSって凄いよな~。
とりあえず、原因のファイルを探します。
1. vCenter Server Appliance にSSHを利用してログインします。 2. シェルを起動します shell.set --enabled True shell 3. # du -a / ※ファイルサイズが大きいものを探します。
duコマンドの結果、
/var/log/audit/audit.logファイルが5GB近くに肥大化して”/”領域を圧迫していました。
とりあえず、ファイルを削除してディスクに空きを作りOSの再起動を実施しました。
が~ん。まだ、GUIからログインできない
引き続き調査続行です。
vCenterの原因調査と障害対応 その2
また、ログ採取(vc-support)です。調査の結果、VMware Inventory Service が起動できなくなっていました。
Inventory Serviceサービスへの対応
パスワードの不一致が発生し、Inventory Serviceサービスが起動できない状態になっているようです。
1. vCenter Server Appliance にSSHを利用してログインします。 2. シェルを起動します shell.set --enabled True shell 3. vdcadmintool コマンドを実行します。 /usr/lib/vmware-vmdir/bin/vdcadmintool 次のオプションが表示されます。 ================================ Please select: 0. exit 1. Test LDAP connectivity 2. Force start replication cycle 3. Reset account password 4. Set log level and mask 5. Set vmdir state ================================ 4. オプション 3 を選択します。 5. vmdird-syslog.log ファイルにリストされたユーザー アカウントを入力します。 -------------------------------------------------- <vCenter Server ApplianceのFQDN>@<SSOのドメイン名> 例:[email protected] 注:自動生成された新しいパスワードをメモしておきます。 -------------------------------------------------- 6. vCenter Server Appliance のシェルに戻りパスワードを変更します。 /opt/likewise/bin/lwregshell cd HKEY_THIS_MACHINE\services\vmdir\ set_value dcAccountPassword "new password" quit 7. vCenter Server Appliance を再起動します
無事に、vCenter へログイン出来るようになりましたが!まだ終わりではありません。なぜ audit.log が肥大したのでしょうか?
ログローテーション設定があるのにローテーションされていない
引き続き調査続行です。
vCenterの原因調査と障害対応 その3
cron実行時に認証に失敗しているため、 rootユーザのパスワードの有効期限が切れ、cronが実行できずにログローテーションができていないようです。
cronへの対応
有効期限を確認しようとしたところ何故かパスワード変更を求められます。やはり、有効期限切れが原因のようです。期限の確認を諦めてパスワードを変更しようとしたら、複雑性を非常に厳しく求められました。よって、chage からパスワードを変更は実施せず、password コマンドから変更を行いました。
※パスワードは世代管理されています。5世代前まで同じものは使えませんのでご注意ください
1. vCenter Server Appliance にSSHを利用してログインします。 2. シェルを起動します shell.set --enabled True shell 3. chage コマンドを実行して有効期限を確認します。 <例>-------------------------------------------------------- # chage -l root Minimum: 0 Maximum: 365 Warning: 7 Inactive: -1 Last Change: Sep 01, 2017 Password Expires: Sep 01, 2018 ★有効期限 Password Inactive: Never Account Expires: Never ------------------------------------------------------------ 4. passwd コマンドを実行しパスワードを変更します。 # passwd root 5. パスワードの期限を無期限にします。 # chage -M 99999 root <例>-------------------------------------------------------- # chage -l root Minimum: 0 Maximum: 99999 Warning: 7 Inactive: -1 Last Change: Sep 29, 2017 Password Expires: Never Password Inactive: Never Account Expires: Never ------------------------------------------------------------ 6. vCenter Server Appliance を再起動します。
無事にGUIからログイン出来るようになりました。
ふぅ~。疲れました。
まとめ
今回の不具合の原因は3つありました。一つ一つ解決することで無事に復旧することができました。
- ディスクの空き容量が無くなった
- サービスが利用するアカウント情報に不整合が発生した
- ログのローテーションが実行されていない
以上、「vCenterからゲストOSが起動できなくなり、最終的にvCenterにログインできなくなる」という記事でした。