IT or War

概要 vSphereクラスタ環境で仮想マシンをvMotionで移行した際に発行される RARP（Reverse Address Resolution Protocol）フレーム を、ESXi標準のパケットキャプチャコマンド pktcap-uw を使って観測する。移行先ESXiの物理アップリンク（ vmnic0 / vmnic1 ）でキャプチャを取得し、実際に流れるRARPフレームの中身を確認する RARPが発行される意味 vMotionによってVMがホストを移行すると、物理スイッチから見れば「あるMACアドレスが接続されているポート」が突然変わることになる。スイッチのMACアドレステーブル（CAM / TCAM）はこの変化をすぐには認識できないため、テーブルが更新されるまでの間はVM宛のフレームが旧ホスト側のポートへ送られ、 フレームがロストしてしまう 。 これを防ぐため、vMotionの際には移行先ESXiが、VMが使用しているMACアドレスの接続先が変わったことをスイッチへ知らせる仕組みを持っている。その通知に使われるのがRARPフレームだ。スイッチはこのフレームを受け取ることで、該当MACアドレスのポートマッピングを即座に更新できる。 補足：GARPではなくRARP vSphere仮想スイッチはGARP（Gratuitous ARP）ではなく、EtherType 0x8035 のRARPパケットを送出する。これはARPリクエストの一種で、ESXiが上流スイッチに対してMAC-to-switchportマッピングの更新を「アナウンス」するために用いられる。 ESXiがRARPを発行する主なケース 参考KBによれば、「Notify Switch」オプションが「yes」に設定されている前提で、ESXiホストは次のような場面でRARPを送出する。 リンクのダウン／アップ時 — VMが別のアップリンク経由で接続し直す必要がある場合、稼働中のリンクからRARPが送られる。VMごとに約5個（最大8個）。リンクフラップ時は状態変化ごとに最大8個。短時間に多数のイベントが起きると、ホストが送出数を制限したり一部を送らない場合もある（LAGには適用されない）。 vMotion後 — 移行先ESXiが、移行先で接続されたVMのためにRARPを送出する（通常1秒未満）。もし...

概要 仮想マシンのストレージポリシーを Thick プロビジョニングから Thin プロビジョニングへ変更したとき、vSAN データストアの使用容量は本当に減るのか。vSphere Cluster 8.x の実機で、Snapshot が絡んだ場合の挙動まで含めて検証しました。 VMware vSAN では、仮想マシンのディスクを「Thick(領域を確保する)」で作るか「Thin(使った分だけ消費する)」で作るかを、ストレージポリシーの Object space reservation で切り替えられます。すでに Thick で運用している仮想マシンをあとから Thin に変えたい、というのは容量が逼迫してきた環境ではよくある要望です。 ただ「ポリシーを変えれば本当に空き容量が戻るのか」「Snapshot を取っているとどうなるのか」「変更後すぐに数字へ反映されるのか」といった点は、実際にやってみないと分かりにくい部分です。そこで vSANクラスタ上の VM を対象に、一連の操作と容量の変化を追いかけてみました。 先に結論 Thick → Thin へポリシー変更した結果、 vSAN データストアの使用容量は 4.86TB → 4.41TB へ約 0.45TB 減少 しました。仮想マシン単体の VM Used Space で見ると 620GB → 124GB(差分 約 496GB) 。FTT1(ミラー)構成のため、物理消費ベースでは約 500GiB 相当の削減に相当します。ただし数値が反映されるまでには VM の PowerCycle と 1〜2 時間の待機が必要でした。 検証環境 今回はVxRail に標準で存在する VxRail Manager VM を検証対象にしています。特別な仕込みは行わず、既存の仮想マシンのストレージポリシーを切り替える、という運用でありがちなシナリオをそのまま再現しました。 プラットフォーム:  vSphere/vSAN 8.x ハードウェア:  Intel Skyelake CPU サーバ 3 ノード構成 耐障害性: FTT=1 / RAID-1(ミラーリング) 対象 VM:  仮想マシンディスクサイズ 288GiB、GuestOS 実使用 約 39GiB 検証の流れ 「作業前の状態確...

概要 vCenter Server Appliance (VCSA) に標準搭載されている簡易ファイアウォール機能を使い、特定 IP からのアクセスを拒否する設定を実際に投入してみる。GUI での操作から、裏側で生成される iptables ルール、そして通信方向ごとの挙動を確認した。 1. VAMI ファイアウォールとは vCenter は簡易的なアクセス制御機能を搭載しており、特定の IP アドレスやサブネットからのアクセスを許可・拒否できます。設定は vCenter Server Management Interface（VAMI、 https://<appliance>:5480 ）の Firewall メニューから行います。 [1] これは環境内にファイアウォールを持たないフラットなネットワークでも、vCenterへのアクセスを制御できるという、セキュリティ観点では意外と有用な機能です。踏み台（ジャンプホスト）や管理セグメントからのみアクセスを許し、それ以外を遮断する、といった用途に使えます。 [2] ポート単位の制御はできない この機能はあくまでネットワーク層（送信元 IP／サブネット）でのフィルタです。「443 だけ許可」「22 だけ拒否」といったポート単位の制御はできず、ルールはその NIC に届く すべてのトラフィックに一律で適用 されます。SSH だけ絞りたい、GUI は全体公開したい、といった要件は VAMI 単体では実現できないため、外部 L4 ファイアウォールや NSX 側で行う必要があります。 [3] 2. VAMI GUI での設定手順 VAMI の Firewall 画面では、ルールを上から順に評価します。今回は例として、送信元 192.168.80.253/32 からのアクセスを拒否（Reject）するルールを 1 件投入しました。 ①ブラウザで https://<appliance-IP-or-FQDN>:5480 にアクセスし、 root でログイン（vCenter SSO の SystemConfiguration.Administrators グループのメンバーである必要があります）。 ②左メニューの Firewall を開き、 ADD をクリック。 ③ルールを指定する。 Network...