2025/04/24追記
vSphere 8でもこの手法が使えるのかどうかは、検証していません。
また、vSphere 8 Update 3から vCLSの実装手法が変更となっています。
従来のvCLS仮想マシンではなく、よりvSphere基盤側に結合された組み込みvCLSとなっていますが、そちらでの動作がどうなるかも確認していません。
2023/03/06追記
警告２
vSphere 7.0 Update1以降、VMware HAを有効にするとvCLSという仮想マシンが起動するようになるという仕様変更があり、おとなしくUPS連動でシャットダウンをさせてくれなくなっています。
詳細は「vSphere 7.0 Update 1以降 vCLSという仮想マシンが勝手に起動してUPS連動シャットダウンに失敗する」を見てください。
2019/06/26追記
警告
UPSによる自動停止と自動起動が目的である場合、このページに書かれている手法は、どこにも担保されていない手法となり推奨できません。
保証がある、という方向性で考えると、UPSソリューションズの「シャットダウンボックス UPSS-SDB02」など、外部機器を用意し、そちらからコントロールする手法をお薦めします。
また、2019年現在では、UPSメーカ公式の対応手法がいくつか出てきています。
基本的には、シャットダウン時にVMware HAを無効化して、起動時はVMware HAが無効化されているのでvCSAと起動用VMが自動起動できるので、それらをまず起動してから、VMware HAを有効化し、それ以外の仮想マシンも起動する、という手法をとっています。
APC UPS「PowerChute Network Shutdown for Virtualization v4.x VMware HA環境でのサポート構成」
Eaton UPS「シャットダウン for vCSA on vSphere HA by IPM 1.62」「自動起動 for vCSA on vSphere HA by IPM 1.62」
よっぽどのことが無い限り、これらの手段を使うべきだと思います。
また、シャットダウンを行う仮想マシンとしてvMA(vSphere Management Assistant)を使用するといった手順が紹介されている場合がありますが、vMAはvSphere 6.5までの対応(2016年11月リリースが最終版)となっており、最新のvSphere 6.7環境ではサポートされないことに注意してください。
vMAというアプライアンスの代替は公式にはありません。
別途、Windows/Linuxをインストールした仮想マシンに対して「vSphere CLI」をインストールするか、もしくはPowerShellがインストールされたWindows/Linux/MacOSXで動作する「VMware PowerCLI」モジュールを組み込むかを行う必要があります。
追記終わり
↓からが、もともと作成していた部分
VMware HA利用時って、ESXiの仮想マシン自動起動設定が使えません。
そんなわけで、いままではvCenter ServerとしてWindowsサーバを別途ハードウェアを用意し、そこから、スクリプトを使って仮想マシンを起動させていたりました。
しかし、いまは、vCenter Server Appliance(vCSA)。
仮想マシンでたてちゃえば、Windowsライセンスもいらないのでお気軽・・・ってことになっています。
(vCSAは、SuSE Linux+Linux版vCenter Serverです)
が・・・VMware HA有効時は、仮想マシンの自動起動が使えない→vCSAも起動しない。
さて、どうしよう？
正規な解決手法は無い模様。
ハードウェアを追加で購入して対応する、というのであれば、UPSソリューションズの「シャットダウンボックス UPSS-SDB02」というアプライアンスを使って解決する、という手があります。
ESXiサーバだけでなんとか解決する手法はないものか、いろいろ捜索してみた結果、ESXiの起動時に実行される/etc/rc.local.d/local.shを利用して起動させる、というあたりが最適かな、という結論に。
(rc.localに関するVMwareのKB:Modifying the rc.local or local.sh file in ESX/ESXi to execute commands while booting)
警告！！！以下の手順はVMware公式の手順ではありません。
ESXi5.1の場合、ESXi Shellを有効にしてログイン、もしくはsshを有効にしてログインしたあと、/etc/rc.local.d/local.shを編集します。
元々のlocal.shはこんな感じ。
~ # cat /etc/rc.local.d/local.sh
#!/bin/sh
# local configuration options
# Note: modify at your own risk! If you do/use anything in this
# script that is not part of a stable API (relying on files to be in
# specific places, specific tools, specific output, etc) there is a
# possibility you will end up with a broken system after patching or
# upgrading. Changes are not supported unless under direction of
# VMware support.
exit 0
ここに仮想マシン起動のコマンドを入れ込みます。
いろいろ実験した結果、すぐに実行すると仮想マシンファイルのロック問題が発生し、vMotionができない状況が発生したりしたので、若干スリープを入れて処理を遅延させます。
・・・時間調整が面倒だったので、切りよく５分(300秒)で設定しちゃってますけどね。
#!/bin/sh
# local configuration options
# Note: modify at your own risk! If you do/use anything in this
# script that is not part of a stable API (relying on files to be in
# specific places, specific tools, specific output, etc) there is a
# possibility you will end up with a broken system after patching or
# upgrading. Changes are not supported unless under direction of
# VMware support.
LOGS=/vmfs/volumes/sharedstore/tmp/`hostname`.txt
date >> $LOGS
vim-cmd vmsvc/getallvms >> $LOGS
sleep 300
date >> $LOGS
vim-cmd vmsvc/getallvms >> $LOGS
for vmid in `vim-cmd vmsvc/getallvms | grep "sharedstore" | awk '{ print $1 }'`
do
vim-cmd vmsvc/power.on $vmid
sleep 5
done
date >> $LOGS
echo "boot finished" >> $LOGS
exit 0
書き換えた後は「auto-backup.sh」を実行します。
これを忘れると、再起動を行うとlocal.shは初期状態に戻ってしまいます。
~ # auto-backup.sh
Files /etc/vmware/dvsdata.db and /tmp/auto-backup.5979//etc/vmware/dvsdata.db differ
Saving current state in /bootbank
Clock updated.
Time: 00:37:06 Date: 09/20/2013 UTC
~ #
もしかすると、下記の様な感じの出力になるかもしれません。
~ # auto-backup.sh
--- /etc/vmware/hostd/hostsvc.xml
+++ /tmp/auto-backup.5631//etc/vmware/hostd/hostsvc.xml
@@ -8,6 +8,5 @@
<mode>normal</mode>
<service>
<TSM-SSH>on</TSM-SSH>
- <ntpd>automatic</ntpd>
</service>
</ConfigRoot>
\ No newline at end of file
Saving current state in /bootbank
Clock updated.
Time: 00:26:37 Date: 09/20/2013 UTC
~ #
これは、vSphere Clientから行った設定と、いまauto-backup.shで保存した設定に差異があり、vSphere Clientで行った設定が無効になったような場合に表示されます。
その場合は､もう１回、vSphere Clientから設定をやり直します。
上記の場合は、「automatic」が無くなった、ということになりますので、NTPに関する設定をやり直します。
解説
#!/bin/sh
# local configuration options
# Note: modify at your own risk! If you do/use anything in this
# script that is not part of a stable API (relying on files to be in
# specific places, specific tools, specific output, etc) there is a
# possibility you will end up with a broken system after patching or
# upgrading. Changes are not supported unless under direction of
# VMware support.
LOGS=/vmfs/volumes/sharedstore/tmp/`hostname`.txt
LOGS=でログファイルの出力先を指定。
「/sharedstore/tmp/」は適宜環境に応じて調整のこと。
date >> $LOGS
vim-cmd vmsvc/getallvms >> $LOGS
この段階での、このESXiホストが管理している仮想マシン一覧を取得。
sleep 300
date >> $LOGS
vim-cmd vmsvc/getallvms >> $LOGS
300秒待ったあと、再度、仮想マシン一覧を取得。
ここでウェイトを入れなかった場合、ESXi間での共有ファイルロックがおかしくなったようで、vMotionがうまくできなくなったという事例が発生した。
どれくらい待てばいいのかという最適値は不明。とりあえず切りよく300秒としただけ。
for vmid in `vim-cmd vmsvc/getallvms | grep "sharedstore" | awk '{ print $1 }'`
do
vim-cmd vmsvc/power.on $vmid
sleep 5
done
仮想マシン一覧を「vim-cmd vmsvc/getallvms」で取得し、そのなかから、起動したい仮想マシンだけをうまいこと選択できるキーワードを使ってgrepで抜き出し、その最初の数字を抜き出す。
その数字の仮想マシンをpower.onする。
という感じ。
仮想マシンの台数が多いときは、この部分を２つに分けて、最初のforループでは、vCSAの起動を。
そこから2分(sleep 120)ぐらい間を置き、
次のforループでは、それ以外の仮想マシンを起動するようにした方がいいと思う。
今回は「sharedstore」という文字列が入っているものを起動させている。
ここら辺は、うまいことやる必要がある。
date >> $LOGS
echo "boot finished" >> $LOGS
exit 0
