vEXPERTのブログ(vEXPERT2年目に突入)

BIGLOBE鈴木(研)です。

無事に申請内容が受理されて、vEXPERT生活2年目に入ることが出来ました。 星が2つになりました。 vExpertのポータルサイトのDirectoryで「japan」で絞り込んでみると、71名が日本のメンバのようです(ワールドワイドで2000名弱)。

f:id:biglobe-editor4:20200312142350p:plain:w300f:id:biglobe-editor4:20200312142407p:plain:w300

本来は、3/5のUserCON2020というイベントのレポートでもしようかと思ってたんですが、 新型コロナウイルスの影響で延期となったため、最近BIGLOBEでの作業でドタバタした技術ネタでも書きたいと思います。

■突然VMのMACアドレスが変わってしまうことがあるのか?

事象発生時の状況

通常、電源ON状態で仮想マシンのMACアドレスは変わることはないのですが、なぜか変わってしまった事象がありました。

事象の発端は「突然VMとの通信が出来なくなって、今もその状態が継続中なんだけど」でした。

初動調査

基盤側を調べたら、通信が出来なくなったタイミングでDRSのvMotionで対象VMが別ESXホストに移行されていて、どうもvMotionがトリガで発生した事象であることがおぼろげに見えてきました。 すぐに分かったのは、ポートグループのセキュリティ設定のMACアドレス変更を「拒否」に設定しているのに引っかかり、このVMのポートがブロックされたということです。

f:id:biglobe-editor4:20200304114107j:plain

VMの設定を確認すると、MACアドレスは、上記とは違うものが設定されていることが分かり、このせいでポートブロックされたことはわかりました。

vCenterのイベント情報を確認すると、実際にVMのMACアドレスが変わっていることが確認できました。

Changed MAC address from 00:50:56:86:67:1a to 00:50:56:86:45:62 for adapter XXXXXXXX_3783

f:id:biglobe-editor4:20200311162157j:plain

ただし、最初の画面のとおり、ランタイムMACアドレスが"00:50:56:86:67:1a"になっているので、ゲストOSで設定されているMACアドレスは"00:50:56:86:67:1a"のまま(変更前)であるようでした。

しかし、vMotionのタイミングより1か月以上も前だったので、関係無いようもに見えました。

前提

BIGLOBE環境の前提として、下記があります。

  • vSphereは6.0u3

  • ポートグループのセキュリティ設定は全て「拒否」

    • 「プロミスキャスモード」を「拒否」することで、宛先にかかわらず全てのパケットを受信することができなくなり,他の送信者や受信者に気付かれずにデータを傍受することができなくなります
    • 「MACアドレス変更」を「拒否」することで、外からVMが受信する通信について、VMに割り振ったMACアドレスと違うMACアドレスをゲストOSで成りすまして使ったら、ESXホストが通信をブロックします
    • 「偽装転送」を「拒否」することで、VMから外に送信する通信について、VMに割り振ったMACアドレスと違うMACアドレスをゲストOSで成りすまして使ったら、ESXホストが通信をブロックします

f:id:biglobe-editor4:20200304111606j:plain

  • VMのMACアドレス採番は「自動」

抱いた疑問

  • なぜvMotionがトリガで、このVMは通信できなくなったのか?
  • なぜvMotion実施前までは、このVMは通信できていたのか?
  • 電源ON中のVMのMACアドレスが変わることがあるのか?

調査継続

VMware社に問合せした結果、VMを電源ONの状態でポートグループ変更するとMACアドレスが変わる場合がある(必ずそうなるわけではない)、変更が反映されるのはVMの電源OFF/ONや再起動後であるとのことでした。

このVMの初期設定で、ポートグループを初期→正規のものに切り替えたのですが、その際VMの電源はONのまま実施していました。

ここで、VMのMACアドレスが 00:50:56:86:67:1a → 00:50:56:86:45:62 に変わりました。 MACアドレス変更「拒否」の設定にここで引っかかっても良さそうですが、通信は継続されたままでした。

しばらく経ってある時に、このVMがDRSによるvMotionで別ESXホストに移動したタイミングで、MACアドレスが変更になっていたことにvSphereが気づいて、通信をブロックし出した、ということのようです。

謎解き

VMware社にいろいろ確認したところ、「下記の動きをしたのでは?」という結論になりました。

  • VMが電源ONのままvNICのMACが変わった場合は、変更前からできていた通信が保持される仕様とのことで、ポートグループのセキュリティポリシー(MACアドレス変更)には引っかからず、通信できていた
  • vMotionで別ESXホストに移行されたため、仮想スイッチのポートが変更になり、その時点でセキュリティポリシーに違反していることをvSphereが検知し、ポートがブロックされた

そんな仕様は想像もしてなかったです。

一連の動作の動きを整理するとこんな感じです。これで一連の動作の説明がついたのでスッキリしましたw

f:id:biglobe-editor4:20200304090811j:plain

VMのvNICが接続するポートグループを変更するような場合、vNICに割り振られるMACアドレスが変更になる場合があるようなので、ご注意ください。 特に、MACアドレスでライセンスされるようなソフトウェアを使用している場合は、固定MACにすることをお薦めします。

※ 本記事で記載されている会社名、製品名は、各社の登録商標または商標です。

補足

そのほかでMACアドレスが変更になる操作としては、仮想マシンのHWバージョンをアップグレードすることが該当するようです。

https://kb.vmware.com/s/article/1010675

■お知らせ

VMwareユーザ会(VMUG)に興味のある方は、

https://www.vmug.com/membership/membership-benefits

から入会していただけると幸いです。 部会でお会いできるのを楽しみにしております。

以上です。