mac 用 UTM 仮想化ソフトウェアの Shared Network モードと Bridge モード

UTM で色々と試していると、ネットワークの挙動によくわからない不審な点があるので調べてみました。それは、

「ゲストOS に固定 IP が振れない？」

ということなのですが、この理由は UTM のネットワークの設定に「共有ネットワーク」と「ブリッジ」の二種類があるということを正しく理解していないことによるものです。

ドキュメントには次の通り書かれているのですが、さっぱりピンとこない。まぁネットワーク・インフラに弱い脳みそには言葉のスタックが足りないからなのですが。

https://docs.getutm.app/settings-qemu/devices/network/network/

Network Mode

Emulated VLAN Creates a new VLAN and connects this virtual machine to it. This VLAN is created in userspace and requests from the VM will be seen by the host operating system as originating from the UTM process. Different VMs will each have their own VLAN.

MACOS

Shared Network Traffic is routed directly by the host operating system and the guest shares a VLAN with the host. Services running on the guest and the host can see each other without additional configuration. This is recommended for new virtual machines.

MACOS

Host Only Similar to “shared network” except WAN traffic is blocked so the guest cannot access the Internet.

MACOS

Bridged The host creates a layer 2 bridge with the specified interface. This is for advanced users.

という事で困ったときの ChatGPT

Q: macのUTM 仮想化ソフトウェアの、共有ネットワークとブリッジの違いを中学生にも分かるように教えて下さい。

A: UTMは、macOS上で動作する仮想化ソフトウェアの1つで、仮想マシンを作成して実行できます。UTMで使用できる2つの主要なネットワーク接続タイプは、共有ネットワーク接続とブリッジ接続です。

共有ネットワーク接続は、UTMの仮想マシンがホストmacOSのネットワークを共有する方法です。つまり、UTM上の仮想マシンは、macOSが使用するネットワークと同じネットワークを使用します。例えば、家のWi-Fiに接続している場合、UTM上の仮想マシンも同じWi-Fiネットワークに接続されます。共有ネットワーク接続は簡単に設定できますが、UTM上の仮想マシンは、ホストmacOSのネットワークと同じIPアドレス範囲に属するため、IPアドレスの競合が起こる可能性があります。

ブリッジ接続は、UTMの仮想マシンを、外部のネットワークに直接接続する方法です。例えば、UTM上の仮想マシンを学校のネットワークに接続したい場合、ブリッジ接続を使用して、UTM上の仮想マシンに独自のIPアドレスを割り当てます。ブリッジ接続を使用することで、UTM上の仮想マシンは、外部ネットワークから直接アクセスできるため、より高度なネットワーク操作が可能になります。ただし、ブリッジ接続はより高度な設定が必要であり、UTMが外部ネットワークに正しく接続されていることを確認する必要があります。

なるほど、よく解らないけどなんとなくわかる。

なぜ共有ネットワークで好きに固定 IP が振れないか

UTM のゲスト OS を「共有ネットワーク」に設定して立ち上げると、ホスト側の macOS 上に、もう一つのインターフェースが出現するのですね。WIFI と有線付きリプリケーターをつないでいるので、LAN にあるDHCP から 192.168.1. XX にふたつの IP を貰っているわけですが、「共有ネットワーク」に設定したゲストVMを起動すると、何故か 192.168.64.XX というインターフェースがもう一つ出現する訳なんです。64 だったり32だったり変化します。

myname@MbookAir ~ % ifconfig | grep 192

inet 192.168.1.50 netmask 0xffffff00 broadcast 192.168.1.255

inet 192.168.1.32 netmask 0xffffff00 broadcast 192.168.1.255

myname@MbookAir ~ % ifconfig | grep 192

inet 192.168.1.50 netmask 0xffffff00 broadcast 192.168.1.255

inet 192.168.1.32 netmask 0xffffff00 broadcast 192.168.1.255

inet 192.168.64.1 netmask 0xffffff00 broadcast 192.168.64.255

これが謎なので、実際にゲストOSから traceroute してみました。

localhost:/home/user # traceroute google.com

traceroute to google.com (172.217.175.46), 30 hops max, 60 byte packets

1 192.168.64.1 (192.168.64.1) 0.891 ms 0.809 ms 0.798 ms

2 buffalo.setup (192.168.1.1) 0.788 ms 1.273 ms 1.264 ms

3 192.168.11.1 (192.168.11.1) 2.238 ms 2.229 ms 2.219 ms

まず、心当たりのない 192.168.64.255 という IP をホスト mac 側に存在すること。ゲストOSがホストに通信する時、192.168.64.1 という謎のルータを通して LAN から外に接続していることがわかります。実際に仮想 VM にバインドされている IP は 192.168.64.32 というアドレスでした。

これ、ゲストVM から見ると UTM で「共有ネットワーク」構成のゲスト VM を立ち上げると、UTM は仮想的なルータを構成してゲストOSにIPを供給しているわけです。この値はケースバイケースの様で、時折変わることがあるようです。

だから、ゲストVM に固定 IP を与えることができない。ゲストVM は UTM が仮想的に作り出した 192.168.64.xx セグメントに合わせて固定 IP を作らなければならない訳なんです。

ということもあり、 UTM で「共有ネットワーク」を使う場合は、事実上ゲスト VM は DHCP 設定にした方が無難、ということになります。これはゲストVMがデスクトップ系クライアントOSとしてセットアップすることに向いています。

固定 IP を使うならブリッジモード

これは KVM や XEN で仮想化した人ならわかると思いますが、ブリッジモードでインストールしたゲスト VM は、直接 LAN 上に接続され、ホスト mac 側からは検出されないネットワークになります。サーバの様に固定 IP が必要なゲスト VM を使うなら、「ブリッジモード」でゲスト VM をインストールしなければならない訳です。もちろんDHCPでセットアップすれば、LAN 内のルールに従ってゲストVMのネットワークIFは構成されるはずです。

ゲスト VM をDHCP 運用するなら結果的にはどちらを選んでも良いのですが、固定IPで使う場合はブリッジモードが良いというところでしょう。多くはブリッジモードでも構わないと思いますが、仮想化するOSによっては、共有モードでなければ動かない、という事もあるようなので注意が必要です

ちなみに、現在 UTM 4.1.5 では、ゲスト VM をインストールした後にネットワークモードを変更することはできない様です。インストールする前に、固定IPが必要かどうかよく考慮してからVMをインストールします。

ｰｰ

UTM で最初は「動いた」と言ってはヨロコンでいたわけですが、実際使いこなしてくると色々おかしな挙動がある訳ですね。奥が深いです。

アップル仮想化フレームワークって何

共有サーバーにある mac のリソースフォークを削除する

isLandcenter.jp