最近ESX3.0とVC2.0で運用していたシステムに新たにESX3.5を追加する事になりました。

VC2.0ではESX3.5と通信が出来ないのでVC2.5にあげる必要があります。
アップデート自体は問題なく終了、しかし既存のESX3.0Hostとの通信が出来てない模様。

仕方なく手動でconnectして見た所、下記のエラーポップアップが。

Failed to install the VirtualCenter Agent service

どうやらESX3.0のVCAgentとVC2.5はそのままでは通信が出来なくて、
ESX3.0のVCAgentをアップデートしなければならなかったらしい。

しかし、本来であればESX3.0からVC2.5への初回の
通信で自動的にVCAgentがアップデートされるはず。

アップデートされなかった原因はどうやらバグらしい。

修正パッチも出ていたようですが、
今回は手動でVCAgentをアップデートしました。

以下手順を覚え書き。

①. VCサーバ上にアップデートモジュールがあるのでそれをESXへコピー。(/tmpにでも)
　　C:\Program Files\VMware\Infrastructure\VirtualCenter Server\upgrade\
　　vpx-upgrade-esx-6-linux-64192
　　(ちなみにバージョンはいくつかあるので環境に合わせてください)

②. mgmt-vmwareとvmware-vpxaサービスの停止。
　　# /etc/init.d/mgmt-vmware stop
　　# /etc/init.d/vmware-vpxa stop
　　(この時、GuestOSの自動起動は切っておかなければGuestOSのrebootが発生します)
　　VMware Knowledgebase Document

③. VCAgentのアップグレードモジュールをインストール。
　　# sh vpx-upgrade-esx-6-linux-64192
　　# rpm -Uvh vpx-upgrade-installer/VMware-vpxa-2.5.0-64192.i386.rpm

④. /var/log/vmware/vpxa.log辺りで正常にインストールされているか確認。

⑤. mgmt-vmwareとvmware-vpxaサービスの起動。
　　# /etc/init.d/mgmt-vmware start
　　# /etc/init.d/vmware-vpxa start

⑥. VCからホストを再登録して完了。

以上です。

ちなみに③もバグで、こっちも修正パッチが出てました。

ESXはデフォルトインストールすると最初からFW(iptables)が効いていて、
ntpの123番ポートも閉じられてしまっています。

なので、ESXでntpdateやntpdを使用するにはFWに穴を開けてやる必用があります。

普通にiptables使用して穴を開けてやることも出来ますが、
esxには専用のコマンドも用意されているのでどうせなのでそちらを使ってみます。

①FWへ穴あけ
# /usr/sbin/esxcfg-firewall -e ntpClien

②FWの確認
# /usr/sbin/esxcfg-firewall -q | grep 123

これだけです。後は実際にntpdateなど動かして疎通確認すればOK。

ちなみに、ftpなども閉じられているので使いたい場合は穴あけが必用。

# /usr/sbin/esxcfg-firewall -e ftpClient
# /usr/sbin/esxcfg-firewall --allowoutgoing

ftpは入口と出口でポートが違うので両方必用です。

以上。

最近、VMware ESX(3.0と3.5)の環境でFCスイッチの障害が起こりました。

この環境はESXにFC経由で共有ストレージを持たせており、
そこの途中にあるFCスイッチに障害が発生してFCの経路が切り替わりました。

ここまではいいのですが、FCパスのFailOver後になんと
Linuxサーバの1/3くらいファイルシステムがReadOnlyになってしまった。

軽くパニックったがどうしようもなかったのでReadOnlyのサーバを全台再起動して復旧。

取り合えず復旧はさせたので原因調査を開始。

まずReadOnlyになったサーバだが、Linuxサーバのうち約1/3程度。
現象が発生しなかったサーバとの違いはどうやらOSのバージョンくらい。

でVMware Knowledgebase Documentを眺めていたらあっさり原因を発見。

vmware knowledgebase Document

どうやら、パスのFailOverが発生した場合に
特定のGestOSを使用していると発現する障害らしい。

だがやっかいな事にESX側のバグではなく、
GestOS側の問題なので、修正はGestOS側になるらしい。

で、どうやらその修正にはOSのバージョンをあげろとの事。

既にサービスインしているGuestOSなので簡単にはOSのバージョンをあげられないが、
結局対処方法が他に見つからなかったのでOSのバージョンをあげる事にしました。

修正パッチとかもう少しスマートな方法で対応出来ると思ってたけど、なんだかな～。

ESXではパスが二重化されていて且つストレージのコントローラがActive-Activeに
なっていても、LUN毎にパスが固定化されている為、自動でロードバランスしてくれない。

なので、LUN毎に手動でパスを指定してあげる必用があります。

例えば、ESXのサーバが二台(A,B)あり、ストレージにLUN(01,02)が二つあるとします。
(サーバではパスが二重化されており、ストレージコントローラもAct-Actとします。)

デフォルトの設定だと、AのサーバはLUN01,02に対してPrimaryのパスを使い、
Bのサーバも同様に両LUNに対してPrimaryのパスを使用します。

さらにPrimaryのパスはストレージAのコントローラに繋がっているので、
サーバA,B共にPrimaryパスを経由してストレージAのコントローラを使用して
LUN01,02に対してアクセスする事になります。

これでは、パスもストレージもせっかく二重化されていてAct-Actなのに
片系しか使用しておらずリソースを無駄に余らせてしまう事になります。

そこで、下記にある通りにパスを切り替えてあげることにします。

サーバ　　　LUN　　　パス　　　　　　コントローラ(ストレージ)
A　　　　　　01　　　　Primary　　　　A
A　　　　　　02　　　　Secondary　　B
B　　　　　　01　　　　Secondary　　B
B　　　　　　02　　　　Primary　　　　A

上記のように設定してあげれば、アクセスが均等に分散されます。

実際に設定する場合は、まずVIClientからVCに繋げます。
設定したいESXの「Configration」タブから「Hardware」メニュー、
「Storage(SCSI,SAN and NFS)」と選択。

「Storage」メニューから対象LUNを選択して、「Properties」を開きます。

Properties画面から「Manage Paths」を選択して、Manage Pathes画面にいきます。
対象のパスを選び、「Change」選択後、Change Path State画面にて「Preferred」
及び「Enable」にチェックを入れてあげればOKです。

後は上記の繰り返しとなります。

以上で、手動ではありますがパスのロードバランシングが可能になります。

補足：
実は最新のESXにはManage Pathで「Load Load balancer」という項目があります。
これは今回のように手動で設定していくのではなく、自動で負荷分散してくれる設定です。
何故今回こちらで設定しなかったといつと、これはまだ試験的サポートのみとあったからです。
(少し前の話なのでもしかしたらもう本番サポートも開始したかも？)
この辺調べきれてなくてすみません。。どなたか情報お持ちでしたら教えて下さい。。

ストレージ上に新規のLUNを作成した場合、
通常のサーバだとそれを認識させるにの再起動が発生する。

しかしESXの場合はオンラインのままそれが出来るのである。

やり方はいたって簡単で、新規のLUNをストレージに作成し、
ゾーンやマスキングの設定が全て終了したらVIClientでVCに接続する。

認識させたいESXサーバを選択し、「Configration」タブから「Storage Adapters」を選択。
「Rescan」というリンクが存在しているのでそれを選択。

すると、下記のようなポップアップが表示されるので、
「Scan for New Storage Devices」にチェックを入れてOK。



これだけで新規のLUNをESXが認識出来る。

ちなみに、「Rescan」にはバグがあり、「Storage Devices」と「VMFS Volumes」の両方に
チェックを入れて実行すると、VIClientとESXのバージョンの組み合わせによってはESXが
フリーズしてしまう。

ESXがフリーズすれば当然その上で稼動している仮想OSも全てフリーズ状態になるので、
かなりクリティカルなバグです。

片方づつRescanを実行するか、もしくはバグフィックスのパッチがvmwareから
出てるのでそれを適用してから実行するかなどした方が良いと思います。

ちなみに検証してみた所、VIClient2.0とESX3.0の組み合わせでは現象が発現し、
最新のVIClient2.5とESX3.5の組み合わせでは発現しませんでした。

前者のバージョンをお使いの方はくれぐれもご注意を。