2.1デバイス仮想化（ハイパーバイザ・VM・仮想スイッチング）

ENCOR の仮想化ドメインは配点10%ですが、SD-Access や SD-WAN のコントローラ、ブランチの仮想ルータ、テスト用ラボまで、現代の企業ネットワークは仮想化の上に載っています。ネットワーク技術者にとって重要なのは「ハイパーバイザとは何か」を暗記することではなく、VM の通信がどこを通っているのかを物理と同じ精度で追えることです。物理サーバのNICから先は、外からは見えない仮想スイッチというL2の世界が広がっており、VLANタグの扱いを一つ間違えるだけで VM は沈黙します。この節では type1/type2 の選択基準、VM のリソース割り当て、そして仮想スイッチの接続とタグ処理を、構成選定と障害切り分けの観点で整理します。

2.1.1ハイパーバイザの2形態

• type1ハイパーバイザ（ベアメタル型）＝物理ハードウェア上に直接インストールされ、自身がハードウェアを直接制御する方式（VMware ESXi・KVM・Microsoft Hyper-V など）。間に汎用OSを挟まないためオーバーヘッドが小さく性能と安定性が高い、また攻撃面（アタックサーフェス）も小さい。データセンタ本番環境や、ブランチで仮想ルータ/仮想ファイアウォールを動かす基盤に用いる。
• type2ハイパーバイザ（ホスト型）＝Windows や macOS といったホストOSの上のアプリケーションとして動く方式（Oracle VirtualBox・VMware Workstation など）。ホストOSのスケジューリングとドライバを経由する分オーバーヘッドが大きく本番向きではないが、手元のPCで手軽に検証環境を立てられる利点があり、学習ラボや開発端末で使う。
• 判断軸は性能・分離・運用である。本番トラフィックを転送する仮想アプライアンス（仮想ルータ・仮想FW・コントローラVM）は type1、資格勉強や機能検証は type2、というのが基本の使い分け。「type2 のほうが新しい」「type1 は古い」といった世代の話ではなく、ハードウェアとの距離の違いである点に注意する。

2.1.2VM とリソース割り当て

• VM（仮想マシン）＝ハイパーバイザが割り当てたvCPU・メモリ・仮想ディスク・vNIC（仮想NIC）の集合の上で、独立したゲストOSが動く単位。VM ごとにOSカーネルを持つため分離は強いが、その分メモリ/ディスクの消費は大きい。対してコンテナはホストのカーネルを共有するOSレベル仮想化で、軽量だが分離は VM より弱い——ネットワーク機能の仮想化では両者が使い分けられる。
• 仮想ルータ/仮想FWのようなデータプレーンを担うVMは、汎用の業務VMとは要求が異なる。パケット処理はCPUを連続的に消費するため、vCPUの過剰割り当て（オーバーサブスクリプション）やメモリのスワップはスループット低下・遅延のジッタとして現れる。ベンダ推奨の vCPU/メモリ予約（リザベーション）を守り、NIC のオフロードや専有割り当てを検討する。
• VM はスナップショットやライブマイグレーションで柔軟に扱えるが、ネットワーク視点では移動先でも同じVLAN/同じサブネットに到達できることが前提になる。移行先ホストのアップリンクで当該VLANが許可されていなければ、VM は移動した瞬間に通信を失う——「サーバ側の作業」に見えて実はスイッチ側の設定が効いてくる典型例である。

2.1.3仮想スイッチングと外部接続

• 仮想スイッチ（vSwitch）＝ハイパーバイザ内部でVM同士や外部を結ぶソフトウェアL2スイッチ。VM の vNIC をポートグループ（VMware）やブリッジ（KVM/Open vSwitch）に接続し、物理NICをアップリンクとして外部の物理スイッチへ橋渡しする。同一ホスト内の同一VLANのVM間通信は物理スイッチを一切通らないため、物理側のミラーやACLでは可視化も制御もできない点に注意する。
• 複数VLANのVMを1台のホストに同居させる標準的な構成では、物理スイッチ側のアップリンクポートを switchport mode trunk にし、switchport trunk allowed vlan で必要なVLANを許可する。仮想スイッチ側は各ポートグループにVLAN IDを付与し、タグ付きフレームをVM側で外して（VST＝Virtual Switch Tagging）ゲストOSにはタグなしで渡すのが一般的である。
• 仮想スイッチは物理スイッチの完全な等価物ではない。一般にSTPに参加せず（BPDUを転送/生成しない）、MACアドレスも学習ではなくVMの構成情報から把握する実装が多い。したがって「仮想スイッチのループ」を STP が救ってくれる前提を置いてはならず、アップリンクの冗長化はチーミング/NICボンディングの方式（および物理側の対応）で担保する。

ブランチ拠点で、type1 ハイパーバイザ上に3台のVMを新規に配置しました。VLAN 10（業務・既存）に2台、VLAN 20（新設した監視セグメント）に1台です。導入後、VLAN 10 の2台は相互にもゲートウェイにも通信できるのに、VLAN 20 の監視VMだけが同一VLANの物理サーバにも既定ゲートウェイにも到達しません。ここで「監視VMのOS設定が悪い」と決めつけて再インストールに走るのは、切り分けの順序として拙い判断です。まず押さえるべきは、VLAN 10 が通っているという事実が何を証明し、何を証明していないかです。VLAN 10 の2台が疎通するだけでは、実は同一ホスト内の仮想スイッチ内で折り返している可能性があり、アップリンクの健全性の証明にはなりません。しかしゲートウェイにも届いているなら、少なくとも物理NICのリンク・アップリンクのトランク自体は生きていると分かります。次に、VLAN 20 だけが落ちているというVLAN単位の切り分けから、疑うべきはタグの経路上のどこかで VLAN 20 が落とされていることです。候補は2つ——(1) 仮想スイッチのポートグループに付与したVLAN IDが誤っている（例：20 のつもりが 200、あるいは未設定でタグなし扱い）、(2) 物理スイッチのアップリンクが switchport trunk allowed vlan で VLAN 10 のみを許可しており、新設した VLAN 20 を追加し忘れている。実務ではこの (2) が圧倒的に多く、新VLANを増やしたときのアップリンク更新漏れが典型的な原因です。確認は物理側で show interfaces trunk を打ち、Allowed VLAN と Active VLAN の一覧に 20 が含まれるかを見るのが最短で、含まれていなければ switchport trunk allowed vlan add 20 で追加します（allowed vlan 20 と打つと既存の10が消えるため、必ず add を使うのがプロの手癖です）。加えて、当該VLANが物理スイッチにVLANとして作成されているか（show vlan brief）も併せて見ます。「VMの障害＝サーバ担当の領分」ではなく、タグが物理と仮想の境界を越えられているかを軸に、両側を等しく疑うのがこのドメインの要諦です。

2.1.4この節のまとめ

• type1（ベアメタル）はハードウェア直上で低オーバーヘッド＝本番/仮想アプライアンス向き、type2（ホスト型）はホストOS上のアプリ＝検証/学習向き
• VMはゲストOSごとに分離が強く、データプレーンVMは vCPU 過剰割り当てがスループット/ジッタ劣化として現れる。コンテナはカーネル共有で軽量だが分離は弱い
• 仮想スイッチはVMのvNICを収容しアップリンクで物理へ橋渡しする。同一ホスト同一VLANの通信は物理を通らず、通常STPにも参加しない。VM疎通障害はポートグループのVLAN IDとアップリンクの許可VLANを両方確認する