VMware HA利用時って、ESXiの仮想マシン自動起動設定が使えません。
そんなわけで、いままではvCenter ServerとしてWindowsサーバを別途ハードウェアを用意し、そこから、スクリプトを使って仮想マシンを起動させていたりました。
しかし、いまは、vCenter Server Appliance(vCSA)。
仮想マシンでたてちゃえば、Windowsライセンスもいらないのでお気軽・・・ってことになっています。
(vCSAは、SuSE Linux+Linux版vCenter Serverです)
が・・・VMware HA有効時は、仮想マシンの自動起動が使えない→vCSAも起動しない。
さて、どうしよう？
正規な解決手法は無い模様。
いろいろ捜索してみた結果、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/loca.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から設定をやり直します。
上記の場合は、「
・解説
#!/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する。
という感じ。
今回は「sharedstore」という文字列が入っているものを起動させている。
ここら辺は、うまいことやる必要がある。
仮想マシンの台数が多いときは、この部分を２つに分けて、最初のforループでは、vCSAの起動を。
そこから2分(sleep 120)ぐらい間を置き、
次のforループでは、それ以外の仮想マシンを起動するようにした方がいいと思う。
date >> $LOGS echo "boot finished" >> $LOGS exit 0