2010年3月31日水曜日

ESX 4.0を起動した後に、vSphere Clientが接続できるまで時間がかかる

ESX 4.0を起動した後にvSphere Clientで接続しようとしても、
10分程度以下のようなエラーが表示されアクセス出来ないことがあります。
また、ESX 4.0を起動後にvCenterから見ても、そのESX 4.0は10分程度切断状態のままです。








これは、ESXサーバに設定しているDNSサーバに、
ESXサーバがアクセス出来ない場合に発生します。
以下、VMware社のKBです。
http://kb.vmware.com/kb/1012942

ESX 3.5の時はこの問題は発生しなかったので、アップグレードして
問題が発生する可能性がありますね。
あと、仮想マシンの中にDNSサーバを構築している場合などは
構成を気をつけた方が良いですね。

2010年3月26日金曜日

仮想ディスクの拡張が1TB以上は出来ない

ESX 3.5で、VI Clientからvmdkを1TB以上に拡張しようとすると、エラーが出て拡張できません。
以下のKBでは、VMFSの場合が書かれていますが、NFSでも同様です。
この問題はESX 4.0で修正しているようです。

kb.vmware.com/kb/1008528

ESX 3.5で1TB以上に拡張したい場合のワークアラウンドとしては、以下の通り。
① 仮想マシンを停止

② VI Clientで対象の仮想マシンを「インベントリから削除」
※「ディスクから削除」をしてしまうとデータが全部消えるので、気をつけること。
※インベントリから削除しないと、古い値がVI Clientに表示されるようです。

③ ESXのコンソールで、vmkfstoolsコマンドで、仮想ディスクを拡張。
たとえば1TBの仮想ディスク(test.vmdk)に100GBの容量を追加する場合は、以下の様に実行。
vmkfstoos -X 1100g /vmfs/volumes/Storage1/test/test.vmdk
※ディスクサイズはディスクに追加するサイズではなく新しいサイズ全体を定義します。
※ test-flat.vmdkではなくtest.vmdkを指定します。
※ディスクのサイズは、GB(g)、MB(m)、KB(k)で指定することが出来ます。

④ VI Clientで再度仮想マシンをインベントリに追加

以上です。

2010年3月18日木曜日

vCenter 4.0でESX 3.5とESX 4.0を管理する場合のライセンスサーバ

vCenter 4.0でESX 3.5を管理する場合は、ライセンスサーバが必要です。
またvCenter Serverがライセンスサーバをしようするよう構成されている必要があります。
これを行わないと、vCenter 4のライセンスキーを登録する時に
「ライセンス割り当て操作が完了できません」とエラーが表示されます。

以下、手順
1. vCenter Serverで、[管理]→[vCenter Serverの設定]を選択します。













2.ライセンスサーバのテキストボックスに、「27000@ライセンスサーバ名」を入力します。

3.[このサーバを使用するよう、ライセンスサーバを使用するESX 3ホストを再構成する]チェックボックスを選択します。

4.[OK]をクリックします。




















http://www.vmware.com/files/jp/pdf/vsp_40_u1_esx_vc_installation_guide_ja.pdf
p.121参照

以上です。

2010年3月11日木曜日

VMware Toolsによる時刻同期

VMware Toolsで「仮想マシンとESX Serverオペレーティングシステム間の時刻の同期を有効にする」にチェックをした場合、どれぐらいのタイミングで時刻が同期されるのか試しました。













確認方法としては、仮想マシン(OSはWindows 2003のStandard Edition 32bit)の時刻を5分程度戻して、ESXの時刻と同期するまでの時刻を測定しました。

結果として、60秒に1度同期しています。

また、仮想マシンの時刻がESXの時刻より進んでいる場合は、時刻同期がされませんでした。

2010年3月9日火曜日

ESX 4 サービスコンソール(COS)のバックアップ、リストア その2

ESX 4 サービスコンソール(COS)のバックアップ、リストア その1 で、「COSの設定をミスしたため、ミス以前の時点に戻りたい。」場合のリストア方法を書きました。
今回は、「COSがインストールされているHDDが破壊されたため、破壊以前の時点に戻りたい。」場合を書きます。
(もし作業実施する場合は、自己責任のもとお願いします。)


※ 画面は以前の方法とかぶる場合は省略しています。

①バックアップ
1.ESXのインストールCDで起動して、Network Configurationまで行います。

2.Network Configurationの次の画面の、Advanced Settingsで、
Ctrl+Alt+F2キーを押します。

3.scpコマンドで外部のlinuxサーバにesxconsole-xxxxフォルダごとコピーします。
以下例:
scp -r /vmfs/volumes/Storage1/esxconsole-* root@バックアップサーバ名:/バックアップ用フォルダ

4./etc/fstabの設定の結果を取得します。
※これは後で重要になります。







以上で、バックアップは終了です。


②リストア
1.今回はHDDが壊れてデータがない想定なので、ESXを一度再インストールを行います。

2.ESXのインストール終了後、再度インストールCDで起動して、Network Configurationまで行います。

3.Network Configurationの次の画面の、Advanced Settingsで、Ctrl+Alt+F2キーを押します。














4.一度Enterキーを押します。

5.rm -r /vmfs/volumes/Storage1/esxconsole*コマンドで、既存のesxconsoleフォルダを消去します。

6.scpコマンドで、バックアップしてあるesxconsole-xxxをフォルダリストアします。
以下例:
scp -r root@バックアップサーバ名:/バックアップ用フォルダ/esxconsole-* /vmfs/volumes/Storage1/

7.cdコマンドで/vmfs/volumes/esxconsole-xxxのフォルダに移動してpwdコマンドでesxconsole.vmdkのフルパスを確認します。

8.CDを取り出してrebootして、GRUBのブートローダーの画面でaキーを押します。

9.grub append>の行に「/boot/cosvmdk=7でメモしたesxconsole.vmdkのフルパス」を書き加えます。
↓こんな感じです。

編集前:
grub append> ro root=UUID=d01bc3a8-1e83-47ea-8250-a77cd15fc54 mem=300M quiet

編集後:
grub append> /boot/cosvmdk=/vmfs/volumes/4a79e784-066e4fef-9d4b-005056ab7e20/esxconsole-4a785116-c442-9826-6f60-005056ab7e20/esxconsole.vmdk ro root=UUID=d01bc3a8-1e83-47ea-8250-a77cd15fc54 mem=300M quiet

また、バックアップ時にメモした、/etc/fstabの情報の中の「/」のuuidを、
「ro root=UUID=」以下に書き換えます。
 下の赤字の部分です。
grub append> /boot/cosvmdk=/vmfs/volumes/4a79e784-066e4fef-9d4b-005056ab7e20/esxconsole-4a785116-c442-9826-6f60-005056ab7e20/esxconsole.vmdk ro root=UUID=d01bc3a8-1e83-47ea-8250-a77cd15fc54 mem=300M quiet
ちなみに、「/boot/cosvmdk=」行を加えない場合は、以下のように、vsd-mountのエラーが出ます。











また、「ro root=」行を書き換えないと以下のように、mount-rootでエラーが出ます。
 










10.(/boot)のuuidに不整合が起きて、エラーが発生します。rootのパスワードを入れます。











11.書き込み可能にする為に、「mount -n -o remount /」でマウントし直します。











12.「blkid」コマンドを実行して、/dev/sda1(/boot)のuuidをメモします。





13./etc/fstabの/bootのuuidを、12でメモした/dev/sda1(/boot)のuuidに変更します。







14.rebootします。

15.手順8と9の作業を繰り返します。
GRUBのブートローダーの画面でaキーを押し、
grub append>の行に「/boot/cosvmdk=7でメモしたesxconsole.vmdkのフルパス」を書き加えます。また、バックアップ時にメモした、/etc/fstabの情報の中の「/」のuuidを、ro root=UUID=」以下に書き換えます。

16.キタ━━━(゚∀゚)━━━!!!! 起動しました。











17.今後の再起動時にきちんと、COSが起動するよう、/etc/vmware/esx.confを編集します。
/etc/vmware/esx.confを開き「/boot/cosvmdk=・・・」で始まる行を検索し、
7でメモしたCOSのパスに書き直して保存します。

18./boot/grub/grub.confのroo-UUID行のuuidを、バックアップ時にメモした、/etc/fstabの情報の中の「/」のuuidに書き換えます。










19.最後に、「esxcfg-boot -b」を実行してbootの設定とinitial RAM disk imageをアップデートします。

以上ですが、やっぱりCOSのバックアップ/リストアは時間がかかりますね。
ホストプロファイル(Enterprise plusが必要)か、設定を保存しておく等の対策の方が早いです。

あと、気になることが1点。
リストアした後ですが、起動中に毎回「Updating summary log: hostname: host name lookup failure」と出てしまいます。
これは何かわかりませんでした。/var/logの下のvmksummary.txtやvmksummary.htmlは更新されているのですが。。。












以上です。

ESX 4 サービスコンソール(COS)のバックアップ、リストア その1

ESX 4 ローカルストレージのブロックサイズの変更方法 その2で、
COSのブロックサイズの変更方法を説明しました。
手順の概要は以下の通りでした。

手順1.COSの仮想ディスクを、ネットワーク経由(もしくは、USB等のリモーバルディスク)にバックアップ

手順2.ローカルストレージを、フォーマット

手順3.手順1でバックアップしたCOSをリストア。

手順4.COSがきちんと起動するように、設定。

上記を見ると、これって手順2を抜かせば、単純なCOSのバックアップとリストア方法ですね。
ならば、COSのバックアップ/リストア方法として使えるか試してみました。

バックアップの目的としては、以下2つが考えられます。
目的1. 「設定をミスしたため、ミス以前の時点に戻りたい。」
目的2. 「COSがインストールされているHDDが破壊されたため、破壊以前の時点に戻りたい。」

今回は、目的1に使えるかを試します。
(もし作業実施する場合は、自己責任のもとお願いします。)

目的2については次回で。

※ 画面は以前の方法とかぶるので省略します。
①バックアップ
1.ESXのインストールCDで起動して、Network Configurationまで行います。

2.Network Configurationの次の画面の、Advanced Settingsで、
Ctrl+Alt+F2キーを押します。

3.scpコマンドで外部のlinuxサーバにesxconsole-xxxxフォルダごとコピーします。
以下例です。
scp -r /vmfs/volumes/Storage1/esxconsole-* root@バックアップサーバ名:/バックアップ用フォルダ

以上で、バックアップは終了です。

②リストア
1.ESXのインストールCDで起動して、Network Configurationまで行います。

2.Network Configurationの次の画面の、Advanced Settingsで、
Ctrl+Alt+F2キーを押します。

3.一度Enterキーを押します。

4.rm -r /vmfs/volumes/Storage1/esxconsole*コマンドで、
既存のesxconsoleフォルダを消去します。

5.scpコマンドで、バックアップしてあるesxconsole-xxxをフォルダリストアします。
以下例です。
scp -r root@バックアップサーバ名:/バックアップ用フォルダ/esxconsole-* /vmfs/volumes/Storage1/

6.再起動

以上で終了です。

次回は、目的2の「COSがインストールされているHDDが破壊されたため、破壊以前の時点に戻りたい。」場合を説明します。

2010年3月1日月曜日

ESX 4 ローカルストレージのブロックサイズの変更方法 その2

ESX 4 ローカルストレージのブロックサイズの変更方法 その1 で、
インストール時に、ESX 4のローカルストレージ(COSが配置されるVMFS領域)のブロックサイズの変更の方法を説明しましたが、
今回はESXをインストールした後に、ローカルストレージのブロックサイズを
変更する方法がVMware社から発表されていたので実際に行ってみました。
http://kb.vmware.com/kb/1013210

大まかな手順としては、以下の通りです。
手順1.COSの仮想ディスクを、ネットワーク経由(もしくは、USB等のリモーバルディスク)にバックアップ
※今回の手順ではネットワーク経由でCOSの仮想ディスクをバックアップするので、linuxサーバを用意して下さい。

手順2.ローカルストレージを、フォーマット

手順3.手順1でバックアップしたCOSをリストア。

手順4.COSがきちんと起動するように、設定。


以下、詳細な手順です。
1.最初にローカルストレージのデバイスアドレスをメモしておきます。















2.ESX 4.0のインストールCDでbootして、グラフィカルモードに入ります。















3.Network Configurationまで通常の方法で進みます。
Network Configurationではきちんと外部に接続できるIPアドレスを設定して下さい。















キーボード配列は普段はJapaneseを選択してますが、
ここでは意味がないので英語キーボードを選択しています。
※ COSをリストアした後は元のキーボード配列になります。









































































































4.Network Configurationの次の画面の、Advanced Settingsで、Ctrl+Alt+F2キーを押します。















5.コンソール画面が表示されるので、Enterキーを押します。





6.scpコマンドで外部のlinuxサーバにesxconsole-xxxxフォルダごとコピーします。








7.vmkfstoolsコマンドで、vmfs領域をフォーマットし直します。ブロックサイズは-bオプションで指定します。vmfs領域は、1で確認したローカルストレージのエクステントを指定します。




8.scpコマンドでバックアップしたesxconsole-xxxのフォルダをリストアします。






9.cdコマンドで/vmfs/volumes/esxconsole-xxxのフォルダに移動して、
pwdコマンドでesxconsole.vmdkのフルパスを確認します。すごいめんどくさい。。。




10.CDを取り出してrebootして、GRUBのブートローダーの画面でaキーを押します。











11.grub append>の行に「/boot/cosvmdk=9でメモしたesxconsole.vmdkのフルパス」を書き加えます。
※ 元々ある「ro root=UUID=....」を消さずに、その前に書き加えて下さい。
これも異様にめんどくさい。。。
↓こんな感じです。

編集前:
grub append> ro root=UUID=d01bc3a8-1e83-47ea-8250-a77cd15fc54 mem=300M quiet

編集後:
grub append> /boot/cosvmdk=/vmfs/volumes/4a79e784-066e4fef-9d4b-005056ab7e20/esxconsole-4a785116-c442-9826-6f60-005056ab7e20/esxconsole.vmdk ro root=UUID=d01bc3a8-1e83-47ea-8250-a77cd15fc54 mem=300M quiet






12.Enterキーを押してESXを起動します。

13.vSphere Clientで接続しブロックサイズが変わっているのが確認出来ます。















14.また今後の再起動時にきちんと、COSが起動するよう、
/etc/vmware/esx.confを編集します。
/etc/vmware/esx.confを開き「/boot/cosvmdk=・・・」で始まる行を検索し、
9でメモしたCOSのパスに書き直して保存します。












15.最後に、esxcfg-boot -bを実行してbootの設定とinitial RAM disk imageを
アップデートします。



以上ですが、 COSがそんなに複雑な設定をしていないなら、
再インストールでブロックサイズを変えて、 再設定の方が楽かも。

以上です。