Client Hyper-V の留意点と WSL2 との共存

Windows 11 には Client 用の Hyper-V があるので、検証用の環境等の作成に便利に使えるのですが、Windows Server の Hyper-V と多少勝手が違うので Client Hypre-V の留意点と、WSL2 と共存時の留意点について説明します

Hyper-V は Azure のベーステクノロジーとして使用されているハイパーバイザー型の仮想化テクノロジーです

Hyper-V は、元々 Windows Server で仮想環境を作成する機能でしたが、Windows OS は Client も Server も共通のコアを使用しているので Client OS 向けにも Hyper-V が提供されるようになりました

Server Hyper-V は、インフラエンジニアが環境構築する前提なので、設定の自由度が高い反面で全てを設定する必要があります

一方 Client Hyper-V は、Clinet OS 利用者が容易に仮想化環境を利用出来るように Default 設定等の工夫が仕込まれています

難しい事は気にせず、手っ取り早く仮想化環境を利用したい場合は、Client Hyper-V か圧倒的に有利ですが、少し突っ込んだ使い方をしたい時に便利機能でブラックボックス化されている事が足枷になることがあります

このため Clinet Hyper-V がどのような環境になっているのかを理解するのが Client Hyper-V を使いこなすためのコツになります

Client Hyper-V と Server Hyper-V の違い

Client と Server の Hyper-V の違いは以下のようになっています

機能	Client Hyper-V	Server Hyper-V	備考
自動チェックポイント	Default ON	Default OFF	仮想マシンの起動時に自動的にチェックポイントを作る機能
クイック作成	有り	機能無し	テンプレートを使用した簡易的な VM(仮想マシン) 作成機能
Default Switch	有り	無し	Clinet Hyper-V 標準の NAPT 仮想スイッチ

細かいところを見ると、これ以外にも違いはあるのですが、普通に使う分であればこの違いを認識していれば問題無いでしょう

自動チェックポイント

何かあったときに設定箇所まで環境を戻せる「チェックポイント」は、Azure や AWS の仮想マシンでは使用できない Hyper-V の機能です
この機能を使いたいがためだけに Hyper-V が手放せないという方は多いかと思います(僕もその一人)

Server Hyper-V では、手動でチェックポイントを設定する必要があるのですが、Client Hyper-V の Default では VM の起動時に自動的にチェックポイントが作成されます

このため、長期間 VM 環境を使用していると、大量のチェックポイントが自動作成される事になります

任意のチェックポイントを設定するのであれば、「自動チェックポイントを使用する」を OFF にします

チェックポイントはチェックポイント作成時点の仮想ディスクを保持して、チェックポイント以降の変更は差分仮想ディスクにすることでチェックポイントを実現しています

つまり、チェックポイントの数だけ差分仮想ディスクが作られるので、自動チェックポイントを使用状態で長期間 VM を使用していると、大量の差分仮想ディスクが作られてしまいます

チェックポイントを削除すると、削除したチェックポイントの差分仮想ディスクがマージされますが、マージにはそれなりの処理時間が必要です
チェックポイントを複数削除すると、マージに結構な時間が必要になります

また、VM を削除しても仮想ディスクは削除されないので、完全にクリーンナップするには差分仮想ディスクを含め VM で使用していた仮想ディスクを全部削除する必要があります

余談ですが、これを手動で削除するのが面倒なので、僕は VM と仮想ディスクをまとめて削除する自作 PowerShell スクリプトを使っています

Hyper-V の VM と VHD をまとめて削除する
https://www.vwnet.jp/windows/PowerShell/2018071401/RemoveVM.htm

クイック作成

Microsoft が提供している VM イメージをインターネットからダウンロードするか、ローカルハードディスクにある ISO またか仮想ディスクを使用して VM 環境を構築します

Default Switch

Default Switch は Client Hyper-V で Default 作成される NAPT 仮想スイッチです
詳細は後述の「Hyper-V のネットワーク」を参照してください

WSL と Hyper-V の共存

お手軽に Linux 環境を使いたい方は、Hyper-V ではなく WSL を使っている方も多いかと思います

結論から先に言うと、WSL と Hyper-V は共存できます

Hyper-V と WSL の違いは、WSL はログインユーザー別に異なる環境の WSL になるのに対し、Hyper-V VM はログインユーザー共通の VM として作成できる点です

Hyper-V のメリットは、コンピューターのリソースが許す限り複数の VM を同時起動できる事と、ネットワークの自由度の高さですが、VM に対し Guest OS のインストールが必要になります

単に Linux を使いたいだけであれば、WSL の方が圧倒的にお手軽です

ご存じの方も多いかと思いますが、WSL には当初から提供されている WSL (便宜的に WSL1 と表現)と、WSL1 の進化版として登場した WSL2 の2種類があります

荒っぽい言い方をすると WSL1 はアプリケーションとして動作しています(エミュレータのイメージ)

これに対し、WSL2 は Hyper-V テクノロジーを使用しています

このため、WSL2 は WSL1 より高速で Linux との互換性が高いものになっています

実は、WSL2 を使用している段階で Hyper-V 環境を使用している事になるのです

Windows 11 で WSL を使っている場合は、Default で WSL2 になっていると思います

使用している WSL が 1 なのか 2 なのかを確認するには「wsl --status」コマンドを使用します

WSL2 は Hyper-V のサブセットを使って環境を作っていますが、フルセットの Hyper-V をインストールしても WSL2 の VM は Hyper-V マネージャーからは操作できないようになっています(VM が見えない)

WSL2 VM は Hyper-V マネージャーから見えませんが、WSL2 が使用する仮想スイッチ「WSL (Hyper-V firewall)」が確認できます

「WSL (Hyper-V firewall)」はコンピューターを再起動すると、WSL2 を起動するまで WSL2 の仮想スイッチが表示されなくなるので、Hyper-V の VM が使用する仮想スイッチには使用しないのが良さそうです

Hyper-V のネットワーク

Client Hyper-V 標準の「Default Switch」がどのような動作をしているのか、Hyper-V の仮想スイッチにはどのようなものがあるかを説明します

Hyper-V の基本機能として、「外部」「内部」「プライベート」の3種類の「仮想スイッチ」があります

「仮想スイッチ」とは、われわれが日常的に使用しているスイッチングハブを仮想化して Hyper-V ネットワーク内に置いているイメージです

仮想スイッチには、任意の VM を接続して通信することが可能です

Windows 11 に Client Hyper-V インストールした時に自動構成される「Default Switch」は、「内部」仮想スイッチに加え、ホスト OS での NAPT 処理で実現されています

Default Switch

「Default Switch」は、「内部」仮想スイッチと、ホスト OS で NAPT する機能を組み合わせた NAPT 通信の仕組みです

本来、「内部」仮想スイッチに接続された VM は、ホスト OS が default でルーティング機能を提供していないため外部との通信は出来ません

「Default Switch」が構成されている状態は、ホスト OS に NAPT 機能が追加され、VM はホスト OS に追加された NAPT 機能を使用してホスト OS の IP アドレスを使って外部と通信をします

これは、家庭のネットワークからインターネットをアクセスしているイメージと同じで、ホスト OS がインターネット境界のルーターの役割を担い NAPT 処理をしています

NAPT 動作なので、外部ネットワークから VM へのインバウンド通信を実現するには、リバースプロキシ設定する必要があります
(コマンドライン設定)

Windows Server には「Default Switch」はありませんが、「内部」仮想スイッチとホスト OS での NAPT 機能を追加することで同じ事が実現できます
(コマンドライン設定)

「外部」仮想スイッチ

「外部」仮想スイッチは、VM を物理 LAN ポートに接続し、VM を外部ネットワークに接続します

接続は透過ですので、VM が持つ IP アドレスをそのまま使って外部通信をします

このため、VM が複数あれば、VM の数だけ IP アドレスを使用する事になります

物理 LAN ポートが1つしかない場合は、ホスト OS が使用する LAN ポートがなくなってしまい、ホスト OS が通信できなくなってしまいます

この問題を解決するには、後述の「管理OS共有」機能を使用します

「内部」仮想スイッチ

「内部」仮想スイッチは、VM とホスト OS を接続する仮想スイッチです

VM はホスト OS との通信は出来ますが、ホスト OS である Windows 11 はルーティング機能を提供していないので VM は外部との通信は出来ません

「プライベート」仮想スイッチ

「プライベート」仮想スイッチは、VM 間だけを接続する仮想スイッチです

VM は外部との通信は出来ません

管理OS共有(外部仮想スイッチの拡張)

「管理OS共有」は、物理 LAN ボートが1つしかないコンピューターで、透過通信を実現する仕組みです

「外部」仮想スイッチは、物理 LAN ポートにマッピングされるので、物理 LAN ポートが1つしかない場合は、ホスト OS が通信に使用する物理 LAN ポートなくなってしまいます

Hyper-V 環境では、ホスト OS も VM の1つなので、ホスト OS の VM を「外部」仮想スイッチに接続することが可能です

こうすることで、ホスト OS と VM の両方が1つの物理 LAN ポートを使用して透過的に通信が出来るようになります

「管理OS共有」を有効にするには、「管理オペレーティングシステムにこのネットワークアダプターの共有を許可する」を ON にします

まとめ

仮想化	仮想スイッチの種類	特徴	VM のアウトバウンド通信	VM のインバウンド通信
Hyper-V	Default Switch	「内部」仮想スイッチ + ホスト OS NAPT (Client Hyper-V 専用)	NAPT	リバースプロキシ設定が必要
	外部	VM が外部と通信できる	透過	透過
	内部	VM とホストOS 間の通信ができる	不可	不可
	プライベート	VM 間でのみ通信ができる	不可	不可
	内部 + ホスト OS NAPT	Windows Server で Default Switch と同等の実装	NAPT	リバースプロキシ設定が必要
	外部 + 管理OS共有	ホスト OS を「外部」仮想スイッチに接続する	透過	透過
WSL2	WSL(Hyper-V firewall)	WSL2専用(Default Switchと同様の仕組み)	NAPT	リバースプロキシ設定が必要

仮想化	メリット	デメリット
Hyper-V	・複数 VM 起動が可能・ネットワーク自由度が高い・ログインユーザーに依存しない VM が構築できる	・VM に Guest OS のインストールが必要
WSL2	・手軽に使用できる・ログインユーザー別の環境が提供される	・1 VM しか起動できない・ネットワーク自由度が制限される

参考情報

NAT ネットワークの設定 | Microsoft Learn
https://learn.microsoft.com/ja-jp/virtualization/hyper-v-on-windows/user-guide/setup-nat-network

interface portproxy の netsh コマンド | Microsoft Learn
https://learn.microsoft.com/ja-jp/windows-server/networking/technologies/netsh/netsh-interface-portproxy