みなさん、こんにちは。
私は普段、メインの仮想化環境としてVMware Workstation Proを愛用しています。以前はVirtualBoxをメインに使っていたのですが、動作が少し不安定になることがあったため、商用利用でも無料で使えるようになったタイミングでVMware Workstation Proへ移行しました。そのあたりの経緯は、以前の記事でも詳しくご紹介しています。
実はその際、「QEMU/KVMも良さそうだな」と思って試してみたのですが、いざ設定しようとすると「Wi-Fiブリッジができない」という壁にぶつかり、メイン環境への採用を断念したという経験があります。「Wi-Fiブリッジさえすんなり動けば、QEMU/KVMをメインにしたかったのに……！」と残念に感じたものです。
そこで今回は、「なぜQEMU/KVMではWi-Fiブリッジができないのか？」、そして「なぜVirtualBoxやHyper-V、VMwareでは当たり前のようにできてしまうのか？」という疑問について、それぞれの「設計思想の違い」から紐解いてみたいと思います！
この記事の要点を先に
最初にざっくりと結論をお伝えすると、以下のような違いがあります。
- VirtualBox / Hyper-V / VMware
- Wi-Fiの仕様にある制約を、独自の“裏技”で上手に「ねじ曲げて」疑似的なブリッジ環境を提供している。
- QEMU/KVM
- どこまでも「正統派」。Wi-Fiの制約をねじ曲げるようなトリッキーな処理はあえて行わず、疑似ブリッジは提供しない。
この設計思想の違いが、結果として以下のような自然な棲み分けを生んでいます。
- 開発用途・ポータビリティ重視 ➔ VirtualBox / Hyper-V / VMware
- 本番用途・パフォーマンス重視 ➔ QEMU/KVM
それでは、なぜこのような違いが生まれるのか、仕組みを少し覗いてみます！
そもそも、Wi-Fiブリッジは「本来できない」仕様
まず大前提として知っておきたいのが、Wi-Fiクライアント（STAモード）の仕様上、1つの接続に対してMACアドレスは1つしか流せないというルール（IEEE 802.11の3アドレスフレーム形式の制約）です。
つまり、一般的な有線LANと同じ感覚で、
- 仮想マシン（VM）の固有のMACアドレスをそのままWi-Fiルーター（アクセスポイント）に見せる
- Linuxのブリッジ（
br0など）にWi-Fiインターフェース（wlan0など）をそのまま突っ込む - VMを完全に物理LANのL2（データリンク層）に参加させる
といった操作は、仕様上そもそも禁止（不可能）されているのです。この制約は、Windows、Linux、macOS、あるいはESXiであっても、すべて共通の物理的なルールです。
VirtualBox / Hyper-V / VMwareが「できているように見える」理由
では、なぜ私たちがよく使うハイパーバイザではWi-Fiブリッジが使えているのでしょうか？
答えは、3つともWi-Fiの制約を回避するための「独自の裏技（プロキシ処理）」を裏で実装しているからです。ただし、その裏技を仕込んでいる「レイヤー（階層）」に違いがあります。
1. VirtualBox（ユーザー空間で裏技を処理）
VirtualBoxの「Wi-Fiブリッジ」は、厳密には本物のL2ブリッジではありません。
中身をバラすと、以下のような処理を行っています。
- ARP（IPアドレスとMACアドレスを紐付ける通信）をホストOSが代理応答する
- DHCPの通信をホストOSが代理中継する
- 内部でNATとルーティングを組み合わせ、パケットのMACアドレスをホストのものに書き換える
これによって、Wi-Fiルーター側には「ホストのMACアドレス」しか流れません。VM側には、まるで「自分も直接LANに参加できている」ように錯覚させているわけです。つまり、VirtualBoxがユーザー空間でWi-Fiの仕様を上手にねじ曲げてくれているのです。
2. Hyper-V（OSレベルで裏技を処理）
Windows標準のHyper-Vで「外部仮想スイッチ」をWi-Fiアダプタに紐付けた場合も、やはり本物のブリッジではありません。
- Windows OSが、Wi-Fi NICの上に仮想ミニポート（vEthernet）を構築する
- OSのネットワークスタック層で、プロキシARPやDHCPプロキシを動作させる
- L3（ネットワーク層）の制御とARP偽装の複合技で、ブリッジっぽく見せる
こちらは、Windowsという「OS自体」がWi-Fiの仕様をカバーする仕組みを提供している、という形になります。
3. VMware Workstation / Fusion（高品質なユーザー空間の裏技）
VMwareのWi-Fiブリッジも、仕組みとしてはVirtualBoxとほぼ同じ「疑似ブリッジ」です。
- ARP偽装、DHCPプロキシ、MACアドレス変換（NAT的な書き換え）を駆使
ただし、VMwareは企業向けの商用利用や高い安定性を重視して作られているため、この裏技の実装が非常に丁寧で、通信が極めて安定しているのが強みです。VirtualBoxと同様に、ユーザー空間（ハイパーバイザの制御層）で仕様のギャップをきれいに吸収する思想ですね。
QEMU/KVMが「できない」理由（どこまでも正統派）
一方で、Linuxカーネル標準の「QEMU/KVM＋libvirt」の環境では、なぜこれができないのでしょうか。それは、彼らが「正統派の仮想化ネットワークモデル」を頑なに守っているからです。
- L2ブリッジを提供する際は、Linuxカーネル標準の本物のブリッジ（
bridge）しか使わない - Wi-Fiの仕様をねじ曲げるような、独自のARP偽装やDHCPプロキシといった「トリッキーなコード」はあえて実装しない
- Linuxネットワークの標準仕様・挙動に100%準拠する
QEMU/KVMやlibvirtは、個人のデスクトップだけでなく、OpenStackやProxmox、oVirtといった大型のクラウド・データセンター基盤でも使われる技術です。そのため、「トリッキーな裏技で便利にするよりも、ネットワークとして『正しく、予測可能で、堅牢であること』を最優先する」という設計思想を持っています。だからこそ、Wi-Fiの仕様に反する疑似ブリッジは「あえて提供しない」のです。
4方式の設計思想を比較するとこうなる
これまでの内容を一覧表にまとめると、それぞれのキャラクターがはっきり見えてきます。
| 仮想化方式 | Wi-Fiブリッジ | 裏技のレイヤー | 設計思想 | 適する用途 |
| VirtualBox | ◎ (疑似) | ユーザー空間 | 開発者向け・手軽さと使いやすさ重視 | 開発・ポータビリティ |
| Hyper-V | ◎ (疑似) | OSレベル | Windows企業環境への親和性重視 | Windows開発・ビジネス用途 |
| VMware | ◎ (疑似) | ユーザー空間（高品質） | 商業的な信頼性と安定性重視 | 開発・企業用途・マルチOS |
| QEMU/KVM | × (対応せず) | カーネル＋libvirt準拠 | 本番環境・性能・正確性重視 | サーバー・クラウド基盤 |
用途から考える最適な選択肢
今回の話を踏まえると、自分がどのハイパーバイザを選ぶべきかの基準がスッキリ見えてきます。
✔ 開発用途・ポータビリティ重視なら
- ノートPCで色々な場所に持ち歩いて作業したい
- Wi-Fi環境でも手軽にブリッジ接続を使いたい
- スナップショットを何度も撮ったり、OSを頻繁に入れ替えたりしたい
- GUIで直感的にサクッと設定を済ませたい
⇒ VirtualBox / Hyper-V / VMware が最適です！
✔ 本番用途・パフォーマンス重視なら
- 自宅サーバーや社内サーバーをガッツリ運用したい
- 高負荷な処理を回したい、少しでもレイテンシ（遅延）を減らしたい
- ネットワークの挙動に曖昧さを残したくない（有線LAN環境が前提）
- 将来的にクラウド基盤（AWSやOpenStackなど）に繋がる技術に触れたい
⇒ QEMU/KVM が最適です！
VM環境は作業環境と目的に合った最適なツールを選ぶ
Wi-Fiブリッジが「できる・できない」という違いは、決して技術力の差ではなく、開発元がどこをターゲットにしているかという「設計思想の違い」によるものでした。
もちろん、今回の話は「Wi-Fiブリッジに限ったネットワークの挙動」にフォーカスしたものであり、これだけでハイパーバイザ自体の優劣が決まるわけではありません。本番環境のサーバー用途であっても、Hyper-VやVMware（ESXiなど）はエンタープライズ向けの超高信頼なシステムとして広く使われています。大切なのは、「自分の作業環境と目的に合った最適なツールを選ぶこと」ですね。
私の場合、普段作業するメインPCの環境がLinux（Ubuntu）であり、なおかつローカルでの開発・検証用途がメインなので、Wi-Fi環境でもストレスなくブリッジが動いてくれるVMware Workstation Proを相棒に選んでいます。
もし今後、手元でガチガチの本番用Linuxサーバーを組むならパフォーマンス重視でQEMU/KVMを選びますし、カリカリのチューニングより現場で手厚い公式サポートや実績が必要ならVMwareを選びます。また、開発環境としてVMを使い、ホストOS間のVMポータビリティを重視するならVirtualBoxを選ぶことになるでしょう。
今回の記事が、仮想化環境のネットワーク設定で悩んでいる方や、ハイパーバイザ選びに迷っている方の参考になれば嬉しいです。
本日も最後までお読みいただき、ありがとうございました。
それでは、よい仮想化ライフを！
