HP BL460c G6にESX 4.0をインストールして、
Management agent for vmware 4.xをインストールした後に、
ESXをシャットダウンすると、以下の様なエラーが表示されます。
「Shutting down Rack Infrastructure Info Srv (cpqriisd): [ FAILED ] 」
「Shutting down Rack agent (cmarackd): [ FAILED ]」
以下のページに書いてあったが、
"cpqriisd"と"cmarackd"は、p-classブレードの監視やファームウェアアップグレードするためのサブエージェントで、p-class以外のシステムでは起動されないそう。
ちなみに、"cpqriisd"と"cmarackd"を起動しようとすると、きちんと起動したとメッセージが出るが、その後すぐに、自動的に停止している。
"cpqriisd"と"cmarackd"は既に停止している為、シャットダウンする時にFAILEDと表示される。
http://h50146.www5.hp.com/products/software/oe/linux/mainstream/support/faq_soft/soft_mgmt-im.html
FAILEDと表示させるのが嫌の場合は、
/opt/hp/hp-snmp-agents/cma.confの中に以下の行を追加する。
例：
exclude cmarackd
exclude cpqriisd
"exclude"の後に、"cpqriisd"と"cmarackd"を追加しても有効だった。
例：
exclude cpqriisd cmarackd
2010年7月25日日曜日
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サーバを構築している場合などは
構成を気をつけた方が良いですね。
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で１TB以上に拡張したい場合のワークアラウンドとしては、以下の通り。
① 仮想マシンを停止
② 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で再度仮想マシンをインベントリに追加
以上です。
以下のKBでは、VMFSの場合が書かれていますが、NFSでも同様です。
この問題はESX 4.0で修正しているようです。
kb.vmware.com/kb/1008528
ESX 3.5で１TB以上に拡張したい場合のワークアラウンドとしては、以下の通り。
① 仮想マシンを停止
② 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参照
以上です。
また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の時刻より進んでいる場合は、時刻同期がされませんでした。
確認方法としては、仮想マシン（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は更新されているのですが。。。
以上です。
今回は、「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が破壊されたため、破壊以前の時点に戻りたい。」場合を説明します。
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がそんなに複雑な設定をしていないなら、
再インストールでブロックサイズを変えて、 再設定の方が楽かも。
以上です。
インストール時に、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/
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がそんなに複雑な設定をしていないなら、
再インストールでブロックサイズを変えて、 再設定の方が楽かも。
以上です。
2010年2月22日月曜日
VCBのNBDモードのパフォーマンス KB 1016291 1012159
ESX 4.0からNBDのパフォーマンスが低下したKBが以前発表されていました。
http://kb.vmware.com/kb/1012159
この問題は、2010年1月7日発表のパッチで修正したようです。
http://kb.vmware.com/kb/1016291
以下のコメントがあります。
「Improves the performance of backup applications such as VMware Consolidated Backup (VCB) on ESX 4.0. 」
ESX 4.0 Update 1で実際に試しました。
仮想マシンは、Windows 2003 SP2 32bitで、
仮想ディスクは35GB（実使用量:23GB）。
※ 仮想マシンの中のデータは、Dummy file makerで
作成した500MBのファイル×40個とOS部分です。
コマンドは以下の通り。
"C:\Program Files\VMware\VMware Consolidated Backup Framework\vcbMounter.exe" -h vCenterのIPアドレス -u administrator -p パスワード -a 仮想マシンのIPアドレス -r D:\tmp -m nbd -t fullvm
パッチ適用前
NBDモードのパックアップ時間
1回目: 19分55秒
2回目: 20分07秒
2010/1/7のパッチ適用後
※ 2010/1/7に発表された全てのパッチを適用しています。
NBDモードのパックアップ時間
1回目: 12分08秒
2回目: 10分32秒
半分までとはいきませんせんが、
6割ぐらいの時間でバックアップが終了するようになりました。
http://kb.vmware.com/kb/1012159
この問題は、2010年1月7日発表のパッチで修正したようです。
http://kb.vmware.com/kb/1016291
以下のコメントがあります。
「Improves the performance of backup applications such as VMware Consolidated Backup (VCB) on ESX 4.0. 」
ESX 4.0 Update 1で実際に試しました。
仮想マシンは、Windows 2003 SP2 32bitで、
仮想ディスクは35GB（実使用量:23GB）。
※ 仮想マシンの中のデータは、Dummy file makerで
作成した500MBのファイル×40個とOS部分です。
コマンドは以下の通り。
"C:\Program Files\VMware\VMware Consolidated Backup Framework\vcbMounter.exe" -h vCenterのIPアドレス -u administrator -p パスワード -a 仮想マシンのIPアドレス -r D:\tmp -m nbd -t fullvm
パッチ適用前
NBDモードのパックアップ時間
1回目: 19分55秒
2回目: 20分07秒
2010/1/7のパッチ適用後
※ 2010/1/7に発表された全てのパッチを適用しています。
NBDモードのパックアップ時間
1回目: 12分08秒
2回目: 10分32秒
半分までとはいきませんせんが、
6割ぐらいの時間でバックアップが終了するようになりました。
ESX 4 ローカルストレージのブロックサイズの変更方法 その1
ESX 4のService Console(以下、COS)が配置されるVMFS領域
（以下、ローカルストレージ）は、インストール時にフォーマットされますが、
そのブロックサイズは1MBに固定されており、
インストール中のウィザードでは他のブロックサイズに変更できません。
その為、ローカルストレージ上に仮想マシンを作成する時に、
256GB以上の仮想ディスクを作成出来ないという問題が起こります。
※ 各ブロックサイズの最大vmdkのファイルサイズは以下のとおりです。
1MBでは、256GB
2MBでは、512GB
4MBでは、1TB
8MBでは、2TB
この問題を解決するKBがVMware社から発表されましたので、
実際に行ってみました。
http://kb.vmware.com/kb/1012683
まずローカルストレージを1MB以上のブロックサイズでフォーマットするワークアラウンドとして
・ESX 3.5を入れてから、ESX 4にバージョンアップする方法
・ローカルストレージを2つのドライブに分ける、もしくはSAN-Boot構成にする方法
の2つの方法が書いてありますが、あまり綺麗な構成でないので現実的ではないです。
その下の「Alternatively, you can reconfigure the installer to install ESX 4.0 with a different blocksize:」からが本題。
1.ESX 4.0のインストールCDでbootして、グラフィカルモードに入ります。
2.次の画面で、CTRL+ALT+F2キーを押します。
3.以下のメッセージが出るのでEnterキーを押します。
4.psコマンドでXorgのプロセスを探して、Xorgのプロセスをkillします。
※ キーボードの配列が英語キーボードになっているので注意して下さい。
5.自動的にコンソールが切り替わり、rebootを行うか確認されますが、
ここで再度CTRL+Alt+F2キーを押します。
6./usr/lib/vmware/weaselに移動して、fsset.pyファイルを開きます。
7.「class vmfs3FileSystem(FileSystemType):. 」から始まるvmfs3を
定義している箇所を探します。
「blockSizeMB」のパラメタで「1」、「2」、「4」、「8」のどれかを選択して下さい。
8. /に移動して、/bin/weaselを実行し再度グラフィカルモードのインストールを開始します。
9.後は通常のインストールを行います。
10.インストール後にローカルディスク（Storage 1）のブロックサイズを確認すると、
ブロックサイズが変更されています。
（以下、ローカルストレージ）は、インストール時にフォーマットされますが、
そのブロックサイズは1MBに固定されており、
インストール中のウィザードでは他のブロックサイズに変更できません。
その為、ローカルストレージ上に仮想マシンを作成する時に、
256GB以上の仮想ディスクを作成出来ないという問題が起こります。
※ 各ブロックサイズの最大vmdkのファイルサイズは以下のとおりです。
1MBでは、256GB
2MBでは、512GB
4MBでは、1TB
8MBでは、2TB
この問題を解決するKBがVMware社から発表されましたので、
実際に行ってみました。
http://kb.vmware.com/kb/1012683
まずローカルストレージを1MB以上のブロックサイズでフォーマットするワークアラウンドとして
・ESX 3.5を入れてから、ESX 4にバージョンアップする方法
・ローカルストレージを2つのドライブに分ける、もしくはSAN-Boot構成にする方法
の2つの方法が書いてありますが、あまり綺麗な構成でないので現実的ではないです。
その下の「Alternatively, you can reconfigure the installer to install ESX 4.0 with a different blocksize:」からが本題。
1.ESX 4.0のインストールCDでbootして、グラフィカルモードに入ります。
2.次の画面で、CTRL+ALT+F2キーを押します。
3.以下のメッセージが出るのでEnterキーを押します。
4.psコマンドでXorgのプロセスを探して、Xorgのプロセスをkillします。
※ キーボードの配列が英語キーボードになっているので注意して下さい。
5.自動的にコンソールが切り替わり、rebootを行うか確認されますが、
ここで再度CTRL+Alt+F2キーを押します。
6./usr/lib/vmware/weaselに移動して、fsset.pyファイルを開きます。
7.「class vmfs3FileSystem(FileSystemType):. 」から始まるvmfs3を
定義している箇所を探します。
「blockSizeMB」のパラメタで「1」、「2」、「4」、「8」のどれかを選択して下さい。
8. /に移動して、/bin/weaselを実行し再度グラフィカルモードのインストールを開始します。
9.後は通常のインストールを行います。
10.インストール後にローカルディスク（Storage 1）のブロックサイズを確認すると、
ブロックサイズが変更されています。
2010年2月19日金曜日
VMware ToolsなしでvMotion
ESX 3.5では、VMware ToolsがインストールされていないWindows OSは
vMotionが出来ませんでしたが、vSphere 4ではVMware Toolsなしで
vMotionが出来るようになったようです。
Windows 2008とWindows 2003のゲストOSで、
VMware Toolsを入れてないくてもvMotionが出来るのを確認しました。
それ以外のゲストOSはまだ試していません。
vMotionの仕様がかなり変わったようですね。
どこかにvMotionの仕様に関するドキュメントがあるのでしょうか？？
vMotionが出来ませんでしたが、vSphere 4ではVMware Toolsなしで
vMotionが出来るようになったようです。
Windows 2008とWindows 2003のゲストOSで、
VMware Toolsを入れてないくてもvMotionが出来るのを確認しました。
それ以外のゲストOSはまだ試していません。
vMotionの仕様がかなり変わったようですね。
どこかにvMotionの仕様に関するドキュメントがあるのでしょうか？？
RHEL 3.5 Update5にVmware Toolsをインストール
ESX 4.0上のRHEL 3 Update 5のゲストOSで、
VMware Toolsをインストールした後にvmware-config-tools.plを実行すると、
添付した画面のエラー（Guest Operation system deamon 失敗）が出力して、
VMware-Toolsのプロセスが起動しません。
おそらくRHELが英語版以外だと、この問題が発生します。
以下の方法で回避が可能でした。
（もし作業実施する場合は、自己責任のもとお願いします。）
1. 仮想マシンの中の、/etc/sysconfig/i18nというファイルを開き、下記の様に追加/編集します。
LANG="C"
SUPPORTED="C"
2. 仮想マシンを再起動します。
3. vmware-config-tools.plを実行します。
4. 終了後、/etc/sysconfig/i18nで編集した箇所を元に戻します。
ちなみに、ESX 3.5ではこの問題は起きませんでした。
VMware Toolsをインストールした後にvmware-config-tools.plを実行すると、
添付した画面のエラー（Guest Operation system deamon 失敗）が出力して、
VMware-Toolsのプロセスが起動しません。
おそらくRHELが英語版以外だと、この問題が発生します。
以下の方法で回避が可能でした。
（もし作業実施する場合は、自己責任のもとお願いします。）
1. 仮想マシンの中の、/etc/sysconfig/i18nというファイルを開き、下記の様に追加/編集します。
LANG="C"
SUPPORTED="C"
2. 仮想マシンを再起動します。
3. vmware-config-tools.plを実行します。
4. 終了後、/etc/sysconfig/i18nで編集した箇所を元に戻します。
ちなみに、ESX 3.5ではこの問題は起きませんでした。
2010年2月18日木曜日
ESX 4.0で[Ctrl]＋[Alt]＋[Delete]キーを押すと、ESX4.0が再起動
2010年3月11日追記
以下の不具合は、VMware ESX 4.0, Patch ESX400-201002402-BG.で修正されました。
http://kb.vmware.com/kb/1018950
ESX 4.0の環境で、コンソールキーボードで[Ctrl]＋[Alt]＋[Delete]キーを
押すと、ESX自体が強制再起動されてしまいます。
原因は、/etc/inittabの中の以下の行。
「ca::ctrlaltdel:/sbin/shutdown -t3 -r now」
この行の先頭に「#」を付けてファイルを保存して、「init q」を実行すれば問題は解消されます。
ESX 4.0 Update 1でも同様です。
ESX 3.5以前ではこの問題はありません。
（もし作業実施する場合は、自己責任のもとお願いします。）
以下の不具合は、VMware ESX 4.0, Patch ESX400-201002402-BG.で修正されました。
http://kb.vmware.com/kb/1018950
ESX 4.0の環境で、コンソールキーボードで[Ctrl]＋[Alt]＋[Delete]キーを
押すと、ESX自体が強制再起動されてしまいます。
原因は、/etc/inittabの中の以下の行。
「ca::ctrlaltdel:/sbin/shutdown -t3 -r now」
この行の先頭に「#」を付けてファイルを保存して、「init q」を実行すれば問題は解消されます。
ESX 4.0 Update 1でも同様です。
ESX 3.5以前ではこの問題はありません。
（もし作業実施する場合は、自己責任のもとお願いします。）
登録:
投稿 (Atom)