2014/04/19

Fusion 6.0.3

4/17付けで VMware Fusion 6.0.3 がリリースされております。

リリースノートにも以下の記載があります。

Security Issues

VMware Fusion has been updated to resolve the Heartbleed issue described here. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CVE-2014-0160 to this issue.
件の OpenSSL heartbleed 問題にどうも抵触しているみたいなので、Fusion 6 を使ってる方はすぐにアップデートした方が良いです。

2014/04/17

ESXi をクローンした場合、互いに通信できなくなる

● 職場で同僚が悩んでた件

ESXi on ESXi で仮想環境上に ESXi を実行しているのだが、どうも vMotion がうまくいかないとの事。vMotion 用の VMkernel Port はもちろん作ってるし、設定を見る限りでは疎通してもおかしくない。

とりあえずと調べているうちに(まあ色々妙な設定は見つかったのでなおしたのだがそれは略して根本だけを見ると)、どうも互いの ESXi 同士の ping / vmkping がいずれも通らないのが原因のようだ。

そして、よくよく見ると気がついたのが、ARPテーブルがうまく作れていない。
ESXi のARPテーブルは「esxcli network ip neighbor list」で確認できるが、相手の項目が作成されないのだ。
で、「esxcfg-vmknic -l」を見てみたら、双方の vmknic が同じMACアドレスを持っている。どうもこれが原因だと判明。

聞いたところ、どうも1台目の ESXi を構成した後、シャットダウンして、クローンを作って2台目を構成したとのこと。どうやら、それが悪かったようだ。

● vmknic のMACアドレス

VMkernel Port のMACアドレスだが、これは以下に見受けられる

・インストール時に指定した管理ポートは、管理用NICのMACアドレスがつく
・後で追加したものは「00:50:56」等から始まるVMwareの仮想用のMACアドレスがつく

ここでうっかりしてしまうのだが、上記の、最初の VMkernel Port (Management Network) のMACアドレスも「仮想」である。つまり、すべての VMkernel Port の MACアドレスは、仮想マシンの仮想NICと同じで仮想MACアドレスである。

VMkernel Port にどの仮想MACアドレスがつくかは、ESXi の管理領域の /etc/vmware/esx.conf に記載されている。つまり、この esx.conf の値を書き換えない限り、同じMACアドレスが割り当てられる。

先の問題は、クローンをしてしまった事から生じる。クローンを実施した折に ESXi を実行する仮想マシンのMACアドレスはもちろん差し替えられる。しかし、さすがに /etc/vmware/esx.conf を書き換えることはないので、起動すると、クローンされた ESXi は、クローン元の ESXi と同じMACアドレスを VMkernel Port に設定してしまう。

クローン元のESXi
vmnic0 (ESXiに繋がってるNIC)のMACアドレスと、
vmk0 のMACアドレスが同じであることが分かる

クローン先の ESXi
vmnic0 は 00:50:56:35:53:52 であるのに対し、
vmk0 は 00:0c:29:2a:a3:cf とクローン元のままだ

冒頭の症状、vMotion 用の VMkernel Port がお互いに通信できなかったのは、同じMACアドレスを持っているため、たとえ異なるIPアドレスを設定しててもL2的には相手が見つけられなかったからだ。

● 修正方法
最も手っ取り早いのは、ESXi はクローンしない、クローンした ESXi 同士をクラスタ挿せるなど連携で使わない、って事だろう。別々のネットワーク、異なる vCenterServer の配下であればまあ問題はないが、同じネットワーク、同じ vCenterServer でクラスタを組むときは個別にインストールする必要がある。ESXi のインストール時間などたかがしてれるので、それぐらいは毎度やってしまえと言うことだ。

クローンしてしまってこの問題に遭遇した場合は、クローン先の ESXi で以下のコマンドを実行するのが手っ取り早い




1. 「esxcfg-vmknic -l」で、VMkernel Port ポートグループと vmknic の対応を確認する
2. 「esxcfg-vmknic -d "<ポートグループ名>"」で、そのポートグループの vmknic を削除

esxcfg-vmknic -d で vmknic を削除
"Management Network" というポートグループが残留しているのがポイント
vSphereClient では分かりにくいが、VMKernel Port も仮想マシン用と同じ
ポートグループがあり、vmknic が一つだけ入っているというだけだ 
3. 「esxcfg-vmknic -a -i <IPアドレス>  -n >>」で、そのポートグループのvmknic を作成
残留している "Management Network" に vmk0 を作成
この時、新しいMACアドレスが裁判されているのが分かる
4. 「esxcfg-vmknic -l」で、設定を確認する(上図)



そもそも、vSphereClient では VMkernel Port が、ポートグループと vmknic でできていることが隠蔽されており、一つのポートのように見えている。このため、VMKernel Port を削除すると、vmknic とポートグループが一気に削除されてしまう。
WebClient ではこの二つが明確に別れて表示されるようになり、どちらを選択して設定ボタンを押したかで設定できる項目に違いが出てくる。
WebClient での表示
Management Network を選択するとこの通りポートグループ全体が選択される

WebClient での表示
ポートグループの仲の vmk0 を選択すると、vmknic だけが選択される

上記のコマンドは、この事を利用して VMKernel Port に設定されたチーミングやセキュリティ設定などを保存しつつ、また管理用の VMKernel Port がなくなって混乱する時間を最低限にしつつ、vmknic を作り直してMACアドレスを再生成させるという手順なわけだ。


※ 2014/5/28 付記

クローンを行う前に仮想環境上の ESXi で以下のコマンドを実行する事でも、回避はできる。

esxcfg-advcfg -s 1 /Net/FollowHardwareMac

察せられるように、NICのMACアドレスが変わったら取りなおすというものだ。
...今思いついたが、クローンした後でも、クローン先のESXiで個別に実行してから再起動しても何とかなりそうだな。