taka8aru: 1/1/22

手元のM1 MacBook Airは貴重なApple Siliconマシンなので、いろいろ無茶をして実験することができないでいました。
このたび、私のお気に入りのUTM appがこの状況の打開策を出してくれました。

UTM app 3.0では、仮想化ゲストOSとしてmacOSを動かせるようになります。

v3.0.1ベータが2022年1月9日公開され、以下の問題は修正ずみ、きちんと動作します。
《残念ながら、現在公開されているv3.0.0ベータ（2022年1月1日公開）では、macOSゲストのVM作成処理の最後のステップで、設定パラメータの判断エラー ("AuxiliraryStorage" is nil. のエラーメッセージ) が発生してゲストの作成に失敗してしまいます。
この問題に対してソースコードは修正済みなので、git cloneして頑張ってビルド（一部手を入れる必要があり(後述)、時間も1時間くらいかかります、わたしはビルドを通すための試行錯誤にさらに2日ほど要しました）すれば問題なく動作します。
本家でもそれほど日を置かずに新しいビルドが公開されると思うので、わたしのようなよっぽどの新しい物好きじゃない限り、少し待つのが良いと思います。》

右の画像が、macOS 12.1 MontereyをApple Silicon Macで実際に仮想ゲストとして動かした様子です。
現在の動作状態は以下のようになりますが、不足機能はどんどん改善されていくと思います。

CPUは「Apple M1 (Virtual)」と認識されます。コア数やメモリサイズは設定で変更できます。メモリサイズはデフォルトは4GBですが、6MBくらいにしないと最初のインストールに時間がかかってしまうと思います。
CPUエミュレーションではなくて、macOSのVirtualization Frameworkが直接使用されるのでフルスピードで動作します。
ディスプレイは初期状態では、物理1920x1200、Retina表示で960x600の固定サイズになります。仮想ゲストのウィンドウの大きさを変更すると表示内容が拡大縮小されます。ディスプレイサイズもUTMの設定で変更できます。
仮想ゲストとホストの間のコピペはまだできません。
Magic Trackpadの右クリック（2本指タップ）は少し効きが悪くて、タップしてホールドしたまま少し指を動かすと認識されます。
macOSのOSイメージは
~/Library/Containers/com.utmapp.UTM/Data/Library/Caches/UniversalMac_12.1_21C52_Restore.ipsw
にダウンロードされます。通常のインストーラとは違う形式で、リカバリイメージを使用するようです。サイズは13GBです。
このキャッシュファイルは何かのタイミングですぐに消されてしまうので、
ln ~/Library/Containers/com.utmapp.UTM/Data/Library/Caches/UniversalMac_12.1_*.ipsw ~/Downloads/
などのコマンドでコピーしておくのがおすすめです。
仮想ゲストは
~/Library/Containers/com.utmapp.UTM/Data/Documents/ゲスト名.utm/
に作成されます。ディスクイメージは最大容量 (例60GB、lsで見た時) で作成されますが、macOS APFSのcopy-on-write機能 (CoW) のおかげで実際の占有サイズは初期20GB程度 (duで見た時) です。
初回起動時に Would you like to install macOS? というメッセージが出て、macOSインストーラが走ります（逆に何かの理由でこのメッセージ出なかった時はVMの作成をやり直さないと一切先には進みません）。インストールは5分くらいで終了します。ものすごく速いと思います（macOSのOSパッチ適用はApple Siliconの場合でも、iOS/iPadOSのインストールはクリーンインストールでも、小一時間かかりますよね）。M1 Macの初期インストールの様子は（Intelと同じですが）今回初めて実施に目にすることができました。

UTMをソースコードから自分でビルドする場合のコツを、ご参考用、かつ自分用のメモとして以下に書いておきます。

基本的な手順はUTM appのgithubのここに書いてある通りです。
わたしはhomebrewよりむしろmacports派なので
sudo port install glib2 libgpg-error nasm meson gmake
で不足ツールを事前インストールしました。さらにmacOS付属のbisonが要件に満たないバージョンなので
sudo port install bison
もしました。
./scripts/build_dependency.sh -p macos -a arm64
は30分以上、
./scripts/buid_utm.sh -p macos -a arm64
は5分くらいかかります。膨大なログが出るのでエラーメッセージを見逃しがちです。実行後、ターミナル上で Cmd+F Error: で検索して確認した方が良いです。
後者のビルドは UTM.xcodeproj をXcodeで開いて行うこともできます。
どうしても #include のパスが解決できないため、ソースコード中のインクルードファイルのパスをフルパスに書き換えたソースが
./build-macOS-arm64/qemu-6.2.0-utm/include/qapi/qmp/qobject.h
です。
ファイルが欠落していて別途追加ダウンロードしたものが
./Platform/Shared/HTerm/libapps
の配下のファイルで、githubのhtermからダウンロードしました。
全てのソースコードをダウンロードしてビルドするには22GBのディスク容量が必要です。

Apple Silicon Macでできることがどんどん広がって、ますます無敵感が高まっていきますね。

[2022-01-08] 初出では思い込みでqemuのhvf (macOSのHypervisor Framework) を使用していると書いてしまいましたが、qemuを経由せず、macOSのもう一つの仮想化FrameworkであるVirtualization Frameworkを直接使用するようになっています。
その証拠に、macOSの仮想化ゲスト（とLinuxでApple Virtualizationを選んだ場合）ではゲストシステムの詳細設定オプションがqemuとは違うものが表示されます。
macOSが提供するこの2つの仮想化Frameworkは、ゲストOSのブートの仕方が違うだけでどちらも高速動作します。
Intel CPUをエミュレーションしてLinuxやWindowsを仮想化で実行する場合にはこれらのFrameworkを使用できないのでApple Siliconやarm64に比べて数倍遅くなるのです。
macOS上で動くアプリやコマンドであれば、Rosetta 2で実行され数割の減速ですみます。
[2022-01-09] v3.0.1ベータが出て初期設定の問題が解消しました。
[2022-01-10] もしやmacOS 11も実行できないかと、UTMのソースコードのバージョンチェック箇所をいじくってやってみましたが(転んでもタダでは起きない)、初回起動のBig Surのセットアップの早い段階でエラーになって、これはダメでした。
"macOS on Apple Silicon Mac" の機能は、おそらくホスト側とゲスト側の両方にMontereyでの追加機能が必要なようです。
複数バージョンは今はできないことが分かりましたが、
macOS 12のクリーンインストール環境がいつでもすぐに(5分程度)いくつでも(ディスクが許す限り、外付けディスクに逃してやることも容易)、手に入るのはとても偉大な進歩です。
[2022-01-12] ネストされた仮想化 (nested virtualization、入れ子の仮想化、仮想化ゲストのmacOSの中でさらに仮想化ゲストを実行する (qemuの(遅い)エミュレーションは大丈夫)) はmacOSの制約？のためにまだできないようです。