VMware Tools でカスタムスクリプトを実行させる

VMware Tools には、ゲストOSの起動/終了時、および仮想マシンをサスペンドやレジュームしたときにスクリプトを実行する機能がある。

Windows の場合は 「%ProgramFiles%\VMware\VMware Tools」 以下に以下のバッチファイルがあるのが見てとれるだろう。このバッチファイルが、それぞれのタイミングで実行されるスクリプトだ。

• poweron-vm-default.bat
• poweroff-vm-default.bat
• resume-vm-default.bat
• suspend-vm-default.bat

なお、Linux, FreeBSD, Solaris などUNIX系のOSの場合、/etc/vmware-tools 以下に同等のファイルが存在する。
OS X をゲストOSとして動かしている場合は、/Library/Application Support/VMware Tools/ 以下だ。

これらのスクリプトを編集することでOSの起動直後や終了前に様々な処理を追加する事ができる。特に View のデスクトップVMなどでは、終了前に ipconfig /flushdns, ipconfig /release をかけておきたいものだが、この機能を使えば簡単に実現できる。

ただ、特に Windows 版では、上記のスクリプトはインストール時に少々きつめの制限がかかってて、編集に苦労する。また resume と suspend については、実は空ではなく VMware 社自身の処理が入っていたりもする。念のために残しておきたいものだ。

そこで、デフォルトのスクリプトを編集するのではなく、スクリプトを別途作成、デフォルトのスクリプトに代わって VMwareTools に実行させる。これがカスタムスクリプトだ。

Fusion 4.0 や vSphere 5.0 までの VMware Tools では、GUIからカスタムスクリプトを指定することができた。

Fusion 4.0 までのタスクトレイのメニュー

VMware Tools を開くを選ぶと、各種設定が可能

しかし、Fusion 5 や vSphere 5.1 ないしそれ以降の VMware Tools ではこのUIがなくなってしまっている。

Fusion 5.0 ないしそれ以降のタスクトレイのメニュー

VMware Tools についてを選んでも情報が見えるだけだ

では、カスタムスクリプトを指定するにはどうすればいいかというと、GUIではなくコマンドラインからになる。VMwareToolboxCmd というコマンドが増えており、これをつかうのだ。
(Linux/FreeBSD/Solaris は /usr/bin/vmware-toolbox-cmd 、OS X は何故か /Library/Application Support/VMware Tools/vmware-toolbox-cli とコマンド名からして他のUNIX系と異なる)

Windows 版ではこのコマンドは VMware Tools のインストールディレクトリにある。
ただ、何故かこのディレクトリをカレントディレクトリにして使うことを前提としている節があるので、まず cd しておいたほうがいいだろう。

使い方は、「VMwareToolboxCmd help」を実行すると表示される

現在のシャットダウン時に実行するスクリプトのパスを表示するには「VMware Tools script shutdown current」で表示される

シャットダウン時のカスタムスクリプトを設定するには「VMware Tools script shutdown set "フルパス"」で指定する。相対パスは使えないので注意だ。

なんでこんなことをいまさら書いているかというと、カスタムスクリプトを仕掛けておいた vSphere 4.x 時代の仮想マシン(テンプレート)をずっと使っていたのだが、新しく作った仮想マシンでも同じくカスタムスクリプトをしかけようとして、見てみたら VMwareTools の GUI が無くなっており、設定ができなくなって焦ったから、だったりする。

VSAN で使ったディスクを再利用して VMFS を構成する

先日のことだが、vExpert 2014受賞者向けに VSANを含む各種製品の評価ライセンス(365日有効)が配布された。
例年、vExpert にはだいた1年のほぼ全製品の評価版が渡されており、自由に検証に使うことができる。あくまで個人への割り当てのため家の私物 ESXi 環境などに入れても問題がないため、これは結構重宝する。


さて、そのVSANの検証をしていて、VSANの構成にHDDやSSDを使おうとした際、あるいはその逆でVSANで使ってたディスクを VMFSで利用しようとすると、構成時にそのディスクが選択肢に表示されず、利用できないことがあった。

どうやら以前に一方で使っていたディスクは、もう一方に使えないようになっているようだ。これはフェイルセーフとしても納得がいく。何らかの理由で孤立してしまい、単体では VSANの一部として見なされないディスクをうっかりVMFSで上書きしてしまっては困るからだ。

とはいえ、検証でディスクを使い回しているとそうも言ってられない。
ので、少々乱暴だが認識できるようにしたので、メモをしておく。


● なぜ認識されないか

VMFSを削除したり VSANを解放しても、SSD/HDD上にはその時に作成されたパーティション情報が残っている。ESXi はこのパーティション情報を見て VSAN/VMFSで使っていたことを検知する。VMFSで使ってた領域を VMFSで使う分には問題ないのだが、タイプを変えようとするとお互いの選択肢から除外されてしまう訳だ。
(なお、これに限らず、ESXi はなんらかのパーティション情報があると選択肢から除外する傾向がある。Linux 等で使ってたディスクを追加のVMFSとして使う際はこれが問題になる事がある。 )
このため、パーティションテーブルをクリアすれば新しいSSD/HDDのように素直に認識してくれる。


● パーティションの削除(失敗編)

さて、パーティションテーブルを飛ばすとなると、普通 dd コマンドだろう。
(大事なことなので強調してみました)

しかし、なんとも嘆かわしいことに ESXi Shell では dd コマンドは使えない。
存在はするのだが、ディスクドライバ側に必要なAPIが備わってないため、書き込みができないのだ。

# dd if=/dev/zero of=/dev/disks/naa.600508b1001cccc92c42c05aa821872a count=1 bs=1M
dd: can't open '/dev/disks/naa.600508b1001cccc92c42c05aa821872a': Function not implemented

嘆かわしい、実に嘆かわしいっ。

仕方が無いので、前時代的で格好の悪いパーティション操作系のコマンドを使うことになる。もういつから使ってるか分からない、あの fdisk だ。

ただ、ESXi の作者はすこしは正気が残ってたようで、fdisk コマンドは動きはするが非推奨となっている。MBRパーティションではなく GPT を使ってるからだ。

# fdisk -l /dev/disks/naa.600508b1001cccc92c42c05aa821872a

***

*** The fdisk command is deprecated: fdisk does not handle GPT partitions.  Please use partedUtil

***

Found valid GPT with protective MBR; using GPT

Disk /dev/disks/naa.600508b1001cccc92c42c05aa821872a: 390651840 sectors,  372M

Logical sector size: 512

Disk identifier (GUID): b380795f-8cc1-4991-b911-aed80429cf48

Partition table holds up to 128 entries

First usable sector is 34, last usable sector is 390651806

Number  Start (sector)    End (sector)  Size       Code  Name

   1            2048            6143        4096   0700

   2            6144       390651806        372M   0700

上記のように、fdisk を実行すると推奨されるのが partedUtil というコマンドだ。


● partedUtil で情報を取得する

partedUtil でのパーティション情報の取得には get/set とgetptbl/setptbl という2つの系統がある。どっちも fdisk にくらべればシンプルだが、より細かい情報が出るのは getptbl の方だ。

# partedUtil get  /dev/disks/naa.600508b1001cccc92c42c05aa821872a
24316 255 63 390651840
1 2048 6143 0 0
2 6144 390651806 0 0
# partedUtil getptbl  /dev/disks/naa.600508b1001cccc92c42c05aa821872a
gpt
24316 255 63 390651840
1 2048 6143 381CFCCC728811E092EE000C2911D0B2 vsan 0
2 6144 390651806 AA31E02A400F11DB9590000C2911D1B8 vmfs 0

get/set では「パーティション番号」「開始ブロック」「終了ブロック」「タイプ」「属性」の順で、getptbl/setptbl では「パーティション番号」「開始ブロック」「終了ブロック」「UUID」「属性」となっている。実際には上記のように、UUIDのあと、そのUUIDの意味がテキストで表示されている。どの用途(ファイルシステムなど)でどのUUIDを使うかは、showGuids オプションで確認できる

# partedUtil showGuids 
Partition Type       GUID 
vmfs                 AA31E02A400F11DB9590000C2911D1B8
vmkDiagnostic        9D27538040AD11DBBF97000C2911D1B8
vsan                 381CFCCC728811E092EE000C2911D0B2
VMware Reserved      9198EFFC31C011DB8F78000C2911D1B8
Basic Data           EBD0A0A2B9E5443387C068B6B72699C
Linux Swap           0657FD6DA4AB43C484E50933C84B4F4F
Linux Lvm            E6D6D379F50744C2A23C238F2A3DF928
Linux Raid           A19D880F05FC4D3BA006743F0F84911E
Efi System           C12A7328F81F11D2BA4B00A0C93EC93B
Microsoft Reserved   E3C9E3160B5C4DB8817DF92DF00215AE
Unused Entry         00000000000000000000000000000000

Linux のパーティションが何故、と思われるかも知れないが、これらは ESXi のブートディスクで利用される。
実際にブートドライブを partedUtil で見たのが、以下だ。

# partedUtil getptbl /dev/disks/naa.600508b1001c7b1101f3c08c5b2c5784
gpt8920 255 63 143305920
1 64 8191 C12A7328F81F11D2BA4B00A0C93EC93B systemPartition 128
5 8224 520191 EBD0A0A2B9E5443387C068B6B72699C7 linuxNative 0
6 520224 1032191 EBD0A0A2B9E5443387C068B6B72699C7 linuxNative 0
7 1032224 1257471 9D27538040AD11DBBF97000C2911D1B8 vmkDiagnostic 0
8 1257504 1843199 EBD0A0A2B9E5443387C068B6B72699C7 linuxNative 0
9 1843200 7086079 9D27538040AD11DBBF97000C2911D1B8 vmkDiagnostic 0
2 7086080 15472639 EBD0A0A2B9E5443387C068B6B72699C7 linuxNative 0
3 15472640 143305886 AA31E02A400F11DB9590000C2911D1B8 vmfs 0

EFI準拠のため、先頭に EFI パーティションが存在する。LinuxNative の部分がブート用に使用され、vmkDiagnostic がカーネルだんぶ領域だ。最後のVMFSは datastore1 に相当する部分にあたる。パーティションの物理的な所在と、パーティション番号が異なるのも注意を要する。

どのドライブがどのデバイス名を持っているかは、色々調べる方法がある。
こちらのブログのように esxcfg-scsidevs コマンドを使っても良いし、以下のように esxcli でも同じ結果を得られる。

# esxcli storage core  device list
naa.600508b1001c36b38da960b49ca5fbed
   Display Name: HP Serial Attached SCSI Disk (naa.600508b1001c36b38da960b49ca5fbed)
   Has Settable Display Name: true
   Size: 3815350
   Device Type: Direct-Access
   Multipath Plugin: NMP
   Devfs Path: /vmfs/devices/disks/naa.600508b1001c36b38da960b49ca5fbed
   Vendor: HP
   Model: LOGICAL VOLUME
   Revision: 1.28
   SCSI Level: 5
   Is Pseudo: false
   Status: degraded
   Is RDM Capable: true
   Is Local: false
   Is Removable: false
   Is SSD: false
   Is Offline: false
   Is Perennially Reserved: false
   Queue Full Sample Size: 0
   Queue Full Threshold: 0
   Thin Provisioning Status: unknown
   Attached Filters:
   VAAI Status: unknown
   Other UIDs: vml.0200030000600508b1001c36b38da960b49ca5fbed4c4f47494341
   Is Local SAS Device: false
   Is Boot USB Device: false
   No of outstanding IOs with competing worlds: 32

naa.600508b1001c7b1101f3c08c5b2c5784
   Display Name: HP Serial Attached SCSI Disk (naa.600508b1001c7b1101f3c08c5b2c5784)
   Has Settable Display Name: true
   Size: 69973

(後略)

iSCSI/FibreChannel での共有ディストレージやRAIDカード経由の接続の場合はだいたい naa. から始まる名称に、オンボードのSATA/SAS インターフェイスの場合は mpx. から始まる名称になる。

非常に多くの情報が出るので適宜 grep で削ってもいい。お目当てがどのデバイスかは、サイズとやベンダー名、Display Name あたりがヒントになるだろう。

なお、partedUtil について記載している VMware 社のKB1036609 では、ディスクを見つけるのに /dev/disks 以下を調べろ、というなかなか素敵なことが書いてある。

余談だが、VSANで使ってた、個別にマウントされていたHDDを HP社の SmartArray でRAID5で束ねた場合、partedUtil で見るとこんなことになる。

# partedUtil getptbl /dev/disks/naa.600508b1001c36b38da960b49ca5fbed
Error: The backup GPT table is not at the end of the disk, as it should be.  This might mean that another operating system believes the disk is smaller.  Fix, by moving the backup to the end (and removing the old backup)? This will also fix the last usable sector as per the new size. diskSize (7813837232) AlternateLBA (1953459631) LastUsableLBA (1953459598)
Error: The primary GPT table on '/dev/disks/naa.600508b1001c36b38da960b49ca5fbed' is OK, but secondary is corrupt. Fix secondary table? This will move secondary at the end in case it is not at the end already. It will also set LastUsableLBA to use all the space at the end. diskSize (7813837232) AlternateLBA (1953459631) LastUsableLBA (1953459598)
Warning: Not all of the space available to /dev/disks/naa.600508b1001c36b38da960b49ca5fbed appears to be used, you can fix the GPT to use all of the space (an extra 5860377600 blocks) or continue with the current setting? This will also move the backup table at the end if is is not at the end already. diskSize (7813837232) AlternateLBA (1953459631) LastUsableLBA (1953459598) NewLastUsableLBA (7813837198)
gpt
486388 255 63 7813837232
1 2048 6143 381CFCCC728811E092EE000C2911D0B2 vsan 0
2 6144 1953459598 AA31E02A400F11DB9590000C2911D1B8 vmfs 0

間にすごく長いエラーメッセージが表示されるが、要は、先頭のGPTパーティションテーブルと、末尾にあるはずのバックアップテーブルが一致しない、というエラーになる。

すくなくとも SmartArray では、RAIDを組んだだけでは内容がクリアされない、以前の単一ディスクだったときのどれかのパーティションテーブルが見えてしまうことがあるようだ。
こういう場合は、partedUtil fixGpt <デバイス名> コマンドを実行することで、パーティションテーブルの復元が行われる。


● partedUtil でパーティションを削除する

ここまで分かれば、後は簡単だ。パーティションを削除すれば良い。
ブートドライブや共有ディスクを誤って殺ってしまわないよう、またパーティション番号にも注意して、以下のように partedUtil delete コマンドを実行する

# partedUtil getptbl /dev/disks/naa.600508b1001cb619f764cc6d47de5db0
gpt486388 255 63 7813837232
1 2048 6143 381CFCCC728811E092EE000C2911D0B2 vsan 0
2 6144 1953459598 AA31E02A400F11DB9590000C2911D1B8 vmfs 0
# partedUtil delete /dev/disks/naa.600508b1001cb619f764cc6d47de5db0 2
# partedUtil delete /dev/disks/naa.600508b1001cb619f764cc6d47de5db0 1
#

delete のあとに、デバイス名とパーティション番号を指定し、うまくいけば、何のエラーも表示せずに消えてくれる。あとは、vSphereClient / WebClient よりストレージの再スキャンを行い、デバイスを再認識させる。

再認識後は、VMFSの作成などで再び選択肢に表示されるようになる。

● VSAN で使っていたSSDの場合

ただ、VSANで使われていた SSD の場合、2つできているパーティションの後者が削除されないという問題が生じた。

# partedUtil getptbl /dev/disks/naa.600508b1001cccc92c42c05aa821872a
gpt
24316 255 63 390651840
1 2048 6143 381CFCCC728811E092EE000C2911D0B2 vsan 0
2 6144 390651806 AA31E02A400F11DB9590000C2911D1B8 vmfs 0
# partedUtil delete /dev/disks/naa.600508b1001cccc92c42c05aa821872a 1
# partedUtil delete /dev/disks/naa.600508b1001cccc92c42c05aa821872a 2
Error: Read-only file system during write on /dev/disks/naa.600508b1001cccc92c42c05aa821872a

Unable to delete partition 2 from device /dev/disks/naa.600508b1001cccc92c42c05aa821872a

どうやら、SSDについては ESXi の VSAN モジュールが握っており、簡単には解放させてくれないようだ。

これについては、こちらのブログに記載がある。手段としては以下の2つがある。

1. esxcli vsan cluster leave コマンドで VSANを終わらせる
2. 下記の vmkload_mod コマンドで VSAN関連のモジュールを排除し、解除させる
• vmkload_mod -u vsan
• vmkload_mod -u plog
• vmkload_mod -u lsocommon

ただ、ブログにも記載があるが、1. ではうまくいかないことが多いようだ。私の場合、先に1つパーティションを消して情報を欠損させているせいか、やはりうまくいかなかった。
ので 2. にある3つの vmkload_mod を実行した。すると、上記にある Read-only のエラーが出なくなり、パーティションが削除された。

なお、別解としては以下がある

3. SSDの2つあるパーティションのうち一方を削除後、ESXi を再起動

最初の VSANパーティションを削除することで、VSAN関連のモジュールがSSDを見つけ出す標を失ってしまう。それから ESXi もろとも再起動、再初期化することで VSANモジュールが握れなくしてしまうと言う訳だ。

再起動が一回かかるので面倒で時間はかかるが、強制的なモジュール排除などを必要としないのでまだ安全かと思われる。

[余談] Buffalo TS5400 シリーズで管理者パスワードを忘れた場合の対処

職場で Buffalo TS5400R という、ラックマウント型のNASが使えるようになった。

ISOイメージや製品インストーラやアップデータ、検証時のキャプチャ画像など、なにかと一時的なデータの量が多いので、一時的な物置として用意されたのだ。

使ってみると、UIは割と分かりやすく、また HTMLファイルを適当にアップロードすればWebサーバになったり、MySQLやPHPが内蔵されていて動的なWebページを持つサーバとしても利用できる、SOHOでのWebサーバなんてこれがあれば十分じゃないのか?という感じでなかなか良い。
( もっとも、 iSCSI機能については少々 挙動不審なところがある。iSCSI ストレージとして使いたいなら、Terastation IS (TS-RIXシリーズ)を買え、という事なのだろう...、まあ、iSCSI有効にして ESXi に繋ごうとするのがそもそもの間違いというか。)

折角だからと色々試みているうちに、気がついたら管理者パスワードを忘れてしまったのか、管理画面でユーザ:admin、パスワードを知っている限り入力してもログインできなくなった。

しょうがないのでパスワードリセットの方法を探したが、FAQはこのとおり、サポートに電話してもパスワードリカバリーUSBを作ってなければどうしようもない、修理扱いになる、との返事でした。まあ、これはサポートが言う事が正しく、作ってなかった私が悪いのだが。

と、嘆いていても仕方ないので、なんとかしてみることとした。

このNAS、後ろ側を見ると USBポートがあるのはともかく、何故か VGAコネクタと「HDD-USB」と書かれたスライドスイッチなんかがある。ディスプレイを繋ぐと、Linux を起動しているのがよく分かる。

ためしに、USBメモリに適当なx86なLinuxを突っ込んで、スライドスイッチをUSB側にして電源を入れたところ、一応起動はした。どうもCPUも x86っぽい。ならば、USBから起動することでパスワードリセットぐらいできるだろう。

ただ、そのLinuxの選定で苦労した。 gparted-live-0.18.0-2-i486 を使ったところ、どうも起動途中でドライバーが足りないっぽいメッセージで fail する。ubuntu-ja-12.10-desktop-i386 の場合は、こんどは CPUパワーか RAMか何か足りないのか、起動途中でハングアップする。

結局、systemrescuecd-x86-4.2.0 で何とか起動に成功した。この systemrescuecd だが、混まんドライベースになるが結構良くできている。

ともあれ、dmesg をもとにデバイスを判断し、mount /dev/md1 /mnt とかしてマウント、/mnt/etc/shadow ファイルを編集、admin ユーザのパスワードを消して再起動することでパスワードリセットに成功した。

デバイスが /dev/md* になるのは、LVM を使ってない場合に限る。このとき /dev/md0 が /boot に相当、/dev/md1 が / , /dev/md2 が swap になる模様だ。LVMが使われた場合も、割と Linux の標準的な構成になるはずなので、適当に探ってほしい。


なお、ISOイメージから USBメモリにブート可能で書き込むのには、UNetbootin を利用した。これも、Mac 版はどうもうまく動いてないというか、書き込みが終わってもブート可能になってない模様。(他のサイトにもあったが、MBR のアクティブフラグが原因かと考えフラグを立ててみたが、改善されず)
使ってる人も多いだろう  Windows版の場合はまったく問題ないので、深追いせず VMware Fusion 上の Windows7 でさっさと作ってしまった。仮想環境でも、 plopbootmanager を併用すれば起動確認もできる。

ともあれ、仮想化とは全く関係がないのだが、メモ代わりに残しておく。

「セキュリティが強化された Windowsファイアーウォール」が起動不良に陥る

本日ハマったのでメモ。

ふと気がついたら、リモート環境にある WindowsServer 2012 のRDP接続ができなくなっていた。vSphereClient 側から確認するにOSは正しく動いている。が、RDPだけ返答しない。

ファイアーウォールの問題かと思ってMMCを開こうとすると 0x6D9 のエラーを表示してパネルが開かない。そもそも、advfirewall サービスが動いていないようだ。

ググると、同じ問題で困ってる人は居るが、解決したらしい記述がない。

どうも、

a. netsh advfirewall reset
b. net start mpsdrv
c. net start bfe
d. net start mpssvc
e. regsvr32 firewallapi.dll

の手順でコマンドを試せば良いようだが、三つ目の net start bfe でこれまた「エラー 1075: 依存関係サービスが存在しないか、または削除の対象としてマークされています。」を表示する。

このエラー番号から調べて見つけたのが以下のページ

http://www.sevenforums.com/system-security/206716-how-turn-base-filtering-engine.html

こちらにリンクされている「RestoreBFE.exe」を実行、再起動するとBFEサービスも起動し、ファイアーウォールも正常に稼働、RDP接続もできるようになった。

イベントビューアでログを見ると、SQL Server のアップデートがかかってエラーしている記述がある。どうも、エラーが起こってアンインストールが行われる際に、依存関係か何かから BFEもアンインストールを試み? 削除マークだけ残ってる?? という感じっぽい。

再現方法が分からないので確証はないが、以上、私的なメモまで。

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 を使ってる方はすぐにアップデートした方が良いです。

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で個別に実行してから再起動しても何とかなりそうだな。

vExpert 2014 受賞しました

今年も vExpert 2014 を受賞できました。ありがとうございます。

https://blogs.vmware.com/vmtn/2014/04/vexpert-2014-announcement.html