Apple Silicon Mac上でIntel x86 Windowsのアプリを最も高速に実行する方法は、現時点はWine

Hypervisor Framework（これに対してVirtualization FrameworkはHypervizor Frameworkにひと皮被せてLinux OSを実行しやすくしたもの）を使ってArm版WindowsをApple Silicon macOS上で実行できることは既に知られていることです。
更にその中で、Microsoftのエミュレータ機能を使って、Intel x86用のWindowsアプリを実行することもできます。

Appleは独自技術を使ってIntel x86アプリを実行するRosetta 2を提供していますが、Arm Windowsの中ではRosetta 2を使用することができなくて、Intel x86 Windowsアプリの実行速度はそれほど高速ではありません（おおよそ半分の速度くらいでしょうか）。

従来から有名なWineを使用すれば、Windowsアプリの実行をWindows OSをインストールすることなしに行うことができます。
このWineが昨年からApple Silicon Macに対応しています。
WineはmacOS上で直接実行されるもの（仮想化は使用しない）なので、Rosetta 2が活用できます。
少し試してみたところRosetta 2らしい高速性が発揮できていることが確認できました（わたしが軽いベンチマークでよく使う7zipのbオプションで、Apple Siliconネイティブのバイナリに比べてIntel x86 Windowsバイナリは2割程度の速度減に収まりました）。
（QEMUやUTMでIntel Windowsを丸ごと実行した場合は3～4倍遅いのに比べると雲泥の差です。）

ただしWineは、Windowsアプリの実行のためのOS環境を互換ランタイムライブラリで代替する方式のため、たとえば.NETなど複雑なランタイムを使用したアプリは互換性が取れなくて実行できません。
わたしが一番使いたかったWindowsアプリであるPaint.NETも実行できませんでした。

しかしながら、Wineで実行できるWindowsアプリでさえあれば、現時点でApple Silicon Mac上で最も高速に実行する方法であることは間違いないと言えます。
ゲームアプリなどでWineが対応しているものもあるようです。

ちなみに、Intel WindowsアプリではなくてIntel Linuxアプリの場合は、前の書き込みの方法の、macOS 13 VenturaのVirtualization Frameworkの新機能を使って、Arm Linux VMの中でRosetta 2を使う方法が最速です。

Apple Silicon macOSのRosetta 2が進化して、仮想Arm Linux内でx86バイナリの実行をサポート

今日はApple Silicon Macの仮想化とIntelエミュレーションに関して2つの話題を書いてみたいと思います。

先日のWWDC22でmacOS 13 Venturaが発表されました。
盛りだくさんの新し機能の中で私が一番だと感じたのは、やはり、仮想環境の中でIntel x86バイナリの実行が出来るようになることです。
ただし、手放しに喜べる機能ではなくて次の使い方に限定されたものです（Apple Developerサイトの解説）。

• Virtualization Frameworkを使ってArm版のLinuxを起動する
• Linux内でmacOSが提供するツールのおまじないを設定する
  
• Arm Linuxの上でRosetta 2を使ってx86用のバイナリを実行できるようになる
  

x86のLinuxを直接実行できるとか、ましてやx86 Windowsを実行できるなどは、まだです。
Linuxではなくて、Arm Windowsの中でx86のWindowsアプリを実行する場合には、引き続きMicrosoftのツールを使うことになります。

Rosetta 2のx86エミュレーションはApple Siliconの非公開機能を使用しているのでとても高速に動作します。
また、現状のmacOSの仮想化機能では、仮想OSの中で仮想化機能を使用すること（Nested Virtualization）はまだできません。
今後も徐々にRosetta 2やVirtulization Frameworkの適用範囲が広がっていってほしいと願います。

 

[2024-06-13] x86バイナリのコンテナもそのまま実行できるような環境が整備されてきました。
Docker DesktopやLimaのコンテナ実行環境で、直接Rosetta 2を利用するための 「Linux内でmacOSが提供するツールのおまじないの設定」が適用されるようになったようです。

macOSはLinuxそのものではないので、Docker DesktopやLimaはコンテナ実行マシーンを作成し、リモート環境としてコマンド接続してコンテナを実行するひつようがあります。
dockerコマンドだと、環境変数 DOCKER_HOST 指定、または .docker/config.json の Host 指定、あるいは context での指定、あるいは廃止になった以前の機能なら docker remote xxx をしているのと同じですね。
もっとシンプルなpodmanコマンドなら --remote と --connection の指定をしているのと同じです。

Kubernetesのkubectl runでdeploymentやjobが作れなくなっているのは仕様変更のため、v1.18 2020-03以降のバージョンにて

唐突ですが、仮想化技術の流れの中、Kubernetes (K8s) をいじくっている、初心者の私です。

Dockerやpodmanからステップアップしてきて、一番最初に使うコマンドは

$ kubectl run NAME --image=IMAGE

だと思います。
Docker/podmanと同じように、指定したイメージを実行するのですが、多くの、というかほとんどの解説書には、

$ kubectl run NAME --image=IMAGE --restart=[Always | Never | OnFailure]

のコマンドを使用すると

• Deploymentが作成される、--restartを指定しないか、デフォルトのAlwaysを指定した場合
• Podが作成される、--restart=Neverを指定した場合
• Jobが作成される、--restart=OnFailureを指定した場合
  

のように書いてあると思います。
でも、実際試してみたら、何度やっても、どうやっても、Podしか作成できません。
これ、自分の環境か、はたまた理解が間違っているんじゃないかって、悩んじゃいますよね。
でも大丈夫、そんなことはありません。

よくよく調べてみると2020年3月リリースのK8s v1.18でkubectl runの仕様が変更（複雑さを排除するため）されていて、kubectl runはPod実行専用になっていました（腹腹開発さんの記事で気付きましたありがとうございます、K8sのchangelogでも確認しました）。
この件、偉い人もあまり取り上げていないようです。
おそらくkubectl runは初心者しか使わなくて、少し専門的になってくるともっぱらYamlでIaC (Infrastructure as Code) しかやらなくなるから、kubectl runの変更は些細な事なんだろうな、と想像しています。

では、Deploymentはどうやって作成・実行するのかと言うと、素直に

$ kubectl create deployment NAME --image=IMAGE

で大丈夫です。
ならば、Podの作成もkubectl create podに統一した方が良いのか、と思いましたがこういうコマンドは残念ながらありません。

また、従来、kubectl run --dry-run -o yamlのコマンドで、DeploymentのYamlを簡易的に生成していたと思いますが、これもv1.18で一緒に仕様が変わっていて、

$ kubectl create deployment NAME --image=IMAGE --dry-run=client -o yaml

となります。
この --dry-run は、--dry-run=[client | server | none] の形式で、clientを指定するとkubectlのコマンド内のロジックのみで処理、serverを指定するとサーバ側で生成される内容を取得、noneはdry-runではなくて実際に実行した内容を表示（つまりdry-run指定しないのと同じ）、となります。
同様にPodのYamlの生成コマンドは、

$ kubectl run NAME --image=IMAGE --dry-run=client -o yaml

となります。
作成済み、実行済みのDeploymentやPodのYamlを取得・逆生成するには、

$ kubectl get deployment NAME -o yaml
$ kubectl get pod NAME -o yaml

です。
サーバ側のYamlは余計な管理情報が付いてきますが、追加のkubectl-neatと言うツールを使えば、ある程度まできれいにできるようです。

なお、作成済み、実行済みのPodやDeploymentの一覧を一発で表示するには、

$ kubectl get all

が便利ですね。

kubectl runで最初の取っつきでつまずいてしまい、あわやK8sを毛嫌いしそうになったわたしの顛末を、あえて共有させていただきました。

 

Apple Silicon MacでこんどはmacOSを仮想化ゲストとして動作可能に（UTM app）

手元の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の制約？のためにまだできないようです。

Apple Silicon Mac上でIntel版Windows 10をインストールする手順（UTM app）

このブログではUTM appを使ってIntel版のWindowsを動かす話題を取り上げてきました。
もう一度言います、UTM appを使えば、Arm版のLinuxやWindowsだけでなく、Intel版のWindowsを動かすことができます。

今回はApple Silicon Mac上でIntel版Windows 10をクリーンインストールする方法です。
少しコツが必要でしたので、その手順を紹介します。
UTM appはLinuxの世界では有名なCPUエミュレータであるqemuを、macOSやiOS/iPadOSで簡単に使えるようにしたアプリで、ここ（App Store版、またはフリー版）から入手できます。

Apple Silicon MacBook Airの8 Coreを全て使えばIntel CPUの実機の1/2〜1/4くらいのパフォーマンスで動作します。
（以前の検証では1/4〜1/8くらいのスピードしか出ず、実験程度にしか使えない状態でしたが、今回改めてWindows 10をクリーンインストールしたら俄然速くなりました。）

以下、Apple Silicon Mac上にIntel版Windowsをインストールする手順です。

1. 準備物は3つ。
   UTM app（App Store版、またはフリー版をあらかじめインストール、現在のバージョンは2.0.27です）、
   Windows 10のインストーラISOファイル（わたしが試したのはWindows 10 version 2004 日本語版）、
   追加ドライバISOファイル（UTM appのサイトのもの）です。
2. UTM appを起動します。
3. ＋ ボタンで新しいVMを作成し、以下の設定を行います。
   [Information] タブの [Name] でVMの名前をつけます（あとでも変えられます）。
   [System] タブの [Architecture] で [x86_64]、[Memory] を 4096MB（わたしは余裕を持たせて6GB）に指定、[Show Advanced Settings] をチェックして、[CPU Cores] で 8Coresを指定します。
   [Drives] タブで、[New Drive] ボタンを押して30GBのシステムディスクを作成します。さらに [Import Drive] ボタンを押してWindowsのISOファイルを指定します。再度 [Import Drive] ボタンを押してダウンロードしたspice-guest-toolsのISOファイルを指定します。3つとも [Interface] は [IDE] です。
   [Display] タブの [Emulated Display Card] に [vmware-svga] を選びます（vmware-svgaがいちばん安全と思います）。
   [Sound] タブの [Emulated Audio Card] に [Intel HD Audio Controller (ich9)] を指定します（デフォルトの [Intel 82801AA AC97 Audio] ではドライバが見つからないため）。
   以上を指定したら、[Save] ボタンを押します。
4. 右三角ボタンで、作成したVMを起動し、Windows 10のインストールを行います。
   インストーラの中で2回のリブート（「ファイルのコピー」の後の「再起動します」のところと「準備しています」の後）がありますが、インストーラ中の自動再起動はうまくいかないので、画面が真っ黒になって、アクティビティモニタで見ていてCPUが約100%で一定になったら（処理中は300%とか500%とかの高負荷）、Windowsの表示ウィンドウのボタンで強制停止したのち起動させます。
   インストーラの最後の方でのシステム更新は、わたしはインストーラを早く終わらせたいので行わないです。
   ユーザの設定等の後、最後の「現在準備中です」のところで「予想よりも少し長くかかっています」と出ますが、無事完了して、Windows 10が起動すると思います。
   インストールは約1時間で終了します（実機に比べてそれほど遅くないですね）。
   
5. 起動したWindows 10にログインします。
   最初は実機でも同様なのですが、デバイスの自動構成（[QEMU USB Keyboard] など）やWindows UpdateやSearch Indexerが動くので負荷が高いです。
   いつも動いてしまうOneDriveは、わたしはタスクマネージャの [スタートアップ] タブで [停止] にしています。
   デバイスマネージャを見ると [PCIシンプル通信コントローラ] が警告状態になっていると思いますので、[ドライバの更新] で E: ドライブを指定してドライバをインストールします（[VirtIO Serial Driver] (Red Hat, Inc.) がインストールされます）。
   それと、ライセンス認証を行います。
   システムが落ち着いてくると、30秒ほどで起動、1分で停止するようになりました。

むかしはWindowsのインストールといえば半日仕事でしたが、上記手順は2時間もあれば完了します。

Apple Silicon Mac上では、ParallelsもVMware Fusionも、もちろんBoot ChampもIntel Windowsへの対応の望みが薄い中、今UTM appは現実に動作する解です。
実行速度の不利さもM2 Macになればすぐに解決すると思います。
いかがでしょうか。

[2021-10-31] CPU Cores数の設定は、初期のM1では全コア数の最大の8がおすすめです。
M1では高性能コアが4つですがM1 PRO/MAXは高性能コアが8つなので結果はかなり違うと思います。
10に設定すると多少でしょうがさらに上がると思われます。

[English version of this post]

Apple Silicon MacでIntel版Windows 10を試す手順 (UTM app) - 「Appleるんるん」オンエア紹介記念！！

Apple Silicon MacBook Air上で動作中のIntel Windows 10

M1 Apple Silicon対応のParallels Desktopがとうとうリリースされました。

しかしながら、Parallelsは純粋な仮想環境ソフトなので、CPUエミュレーション機能は提供されていません。

つまり、Apple Silicon Mac上ではArm版のWindowsやLinuxしか（Intel Mac上ではIntel WindowsやLinuxしか）実行できません（※1）。

このブログで以前から紹介しているUTM app（祝、App Store版、およびフリー版）では、Intel CPUエミュレータのQEMUを使用しているため、Intel版のWindowsも実行することができます。
UTM appのサイトにはArm版の各種Linuxと共に、Intel版のWindows XPとWindows 7のお試しイメージが公開されています。

ここでは、Intel版Windows 10をApple Silicon Mac上で試す、最も簡単と思われる手順を紹介します。

1. UTM app（App Store版、またはフリー版）をインストールします。
2. Vagrant（Linux上で仮想環境を簡単に実行するためにパッケージ化する仕組み）にWindows 10のイメージが公開されているので（Microsoftの評価版をインストールしたもの）これを利用します。
   
   Vagrant形式のWindows 10のサイトはここ、実際にダウンロードすべきファイルのリンクは、現在バージョンが20210401.01なので
   
   https://app.vagrantup.com/peru/boxes/windows-10-enterprise-x64-eval/versions/20210401.01/providers/libvirt.box
   です。
   ダウンロードサイズは7.3GBです。
   中身は英語版のWindows 10 2004です。
   
3. ダウンロードしたファイル libvirt.box を w10-box-20210401.tar.gz に名称変更して、展開します。
   展開すると、box.img が作成されるので、このファイルを w10-box-20210401.img に名称変更します。
4. UTM appを起動します。
5. ＋ ボタンで新しいVMを作成します。
   [Information] タブの [Name] でVMの名前をつけます（あとでも変えられます）。
   [System] タブの [Architecture] で [x86_64]、[Memory] を 4096MBに指定、[Show Advanced Settings] をチェックして、[CPU Cores] で 8Coresを指定します。
   [Drives] タブで、[Import Drive] ボタンを押し、ダウンロードして展開した w10-box-20210401.img を指定します。[Image Type] は [Disk Image]、[Interface] は [IDE] とします。
   [Display] タブの [Emulated Display Card] に [vmware-svga] を選びます（vmware-svgaがいちばん安全と思います）。
   以上を指定したら、[Save] ボタンを押します。
6. 右三角ボタンで作成したVMを起動します。
   初回起動は30分弱かかると思います。
   2回目以降の起動は3分程度です。
   例によって、当面はWindows UpdateやSearch Indexerが走るのでとても重いですが、落ち着くと、ある程度それなりになりの動作になります。
   登録済みユーザは vargrant/vagrant です。

むかしはWindowsのインストールといえば半日仕事でしたが、上記手順は1時間もあれば完了します。
普段はぜんぜん熱くならないApple Siliconですが、右の画面にあるように、8Core全て100%稼働、CPU温度が80℃以上に上がります（Menu Metersの表示による）。

今回は出来合いのイメージを使用しましたが、Windowsのインストーラで一からインストールすることも出来るはずです。
その場合は、Vargantのページから参照されているVIrtIOのドライバか、UTM appのWindows 7のページにあるSPICE toolsのドライバを追加する必要があると思います。
こちらは追って検証したいと思います。

また、Apple Silicon Macでは、Docker Desktopもすでに利用できます。
Docker DesktopにはUTM appと同じく、CPUエミュレーション用にQEMUが入っているので、今回と同様のことができる可能性が高いです。
実態はVMですが、運用をDockerに揃えられるメリットがあるので、こちらも検証していきたいと思います。

ところで、UTM appについて1月に書いた記事が、遂に、かの有名な、レジェンドたる「Appleるんるん」ポッドキャストで2021年4月18日に紹介されました！！
これで、Apple Silicon Mac上のIntel Windows利用技術の裾野がますます広がればな、と思います。
IT技術があれば面白いことがどんどんひらけていきますよね。

（※1: わたしも最初、11月の時点では、Apple Silicon Mac上のVirtualization Frameworkを使ったvftoolで、ArmのLinuxを動かして、その上でqemuを起動し、その中でIntel Windowsを試していました。
今回の方法はApple Silicon Mac上で直接qemuを動かす（UTM appがやってくれる）ので、かなり楽です。
AppleからApple Siliconの仕様が公開されて、qemuが最適化されればもっと高速化する可能性があります。
並行してApple SiliconがM1XやM2になって行けば2倍、3倍の高速化はすぐに達成できそうです。）

なお、下記コメント欄、またはtwitterの方に、ご感想等いただけたら、より一層の励みになりますので、よろしくお願いいたします。

[2021-05-05] Intel Windowsをクリーンインストールする方法を書きました。

[2021-10-31] CPU Cores数の設定は、初期のM1では全コア数の最大の8がおすすめです。
M1では高性能コアが4つですがM1 PRO/MAXは高性能コアが8つなので結果はかなり違うと思います。
10設定にすると多少でしょうがさらに上がると思われます。

Intel/Arm64 WindowsやLinuxをApple Silicon Macで簡単に実行出来るUTM appの一般公開が始まりました

先日ご紹介した、UTM appのwebサイトが https://mac.getutm.app/ に公開されました。

UTM appを使えば、簡単にIntel WindowsやArm64 WindowsやLinuxをApple Silicon Macで実行することができます。

私も書きましたが、Intel x86のOSの実行はArm64のOSを実行するのに比べてパフォーマンス的に不利と明記されています。

webサイトではUTM appのダウンロードリンクに加えて、設定済のゲストイメージや、OSの設定方法がGalleryページに公開されています。
Intel x86のUbuntu、Windows XP、Windows 7などをダウンロードしてすぐに試せるようになっています。
Arm64のUbuntuやWindows 10 に関しては設定方法が記載されています。
他のArm64 Linuxは設定済のものも提供されているものもあります。

一点だけ注意点があって、現在バージョン（v2.0.17）では、ダウンロードしたイメージやISOファイルは ~/Library/Containers/com.utmapp.UTM/Data/Documents というフォルダに置く必要があります。

[English version of this post]

Apple Silicon MacのUTM appを使えばWindows for Intelが簡単に動く、そして熱い

macOS Big Sur 11ではRosetta 2によって、Intelコードで書かれた従来のMacアプリを、Apple Silicon上でスムーズに実行することができますが、あくまでMac用に書かれたアプリ限定です。
仮想化のためには、Hypervisor Frameworkと、Linux向けに簡易化したVirtualization Frameworkが提供されていますが、これらではIntel向けのOSを実行することはできません。
Arm用のWindowsはMicrosoft Surface Pro X向け限定でリリースされていますが、それ以外の環境での利用は現時点では（評価版以外は）許されていませんし、それ以前にArm向けのアプリはとても少ないです。

Windowsの主流はやはりIntel版（Wintelという言葉があるくらい）。
これをそのままApple Silicon Macで実行できないことには、ユーザにとってのメリットが少ないと思えます。

なぜか他ではまだなかなか紹介されていないのですが、iOS上でWindows XPを実行するという離れ技をやってのけたUTM appというアプリがあります。
このUTM appがApple Silicon Macにも対応（dmgがまさにmacOS用のインストーラ）しました。

右のスクリーンショットは、UTMを使って、Intel Windows とArm Windowsの両方を、Apple Silicon MacBook Airで実行したところです。
Intel WindowsもArm Windowsも評価版をダウンロードして、UTMで仮想ゲストを作成し、Cドライブとして設定して実行しました。

Arm Windowsはフルスピードで実行されます。
これはUTMが、内部的にHypervisor Frameworkを使って（実際にはQEMUがhvfに対応）ハードウェア仮想化技術を利用できているためです。
Arm Windowsの注意点は、起動ディスクのvhdはNVMeとして（おまじないとして）設定しないと起動しないこと、ネットワークはvirtio用ドライバを追加でインストールしないと通信できないこと、それ以外のデバイスもDevice ManagerでUnknownが多数残ってしまうことです。
画面サイズの変更もできません。
まだまだドライバ周りなどで未対応のものが残っているようです。

Intel Windowsを動かすと、UTMが内部のQEMU（Linux上で有名なCPUエミュレータ）を使って、Apple Silicon上でIntelコードをエミュレーションします。
そのため、パフォーマンスは1/4〜1/8程度、大昔のSoftPCやVirtual PCを見ている感じです。
ですが確かにIntel WindowsがApple Silicon Macで動きます。
vagrant用に設定済みのWindows 10イメージで試したこともあって（別記事に設定手順）、デバイスの認識は問題ありません。

ここで面白いのが、Intel Windows上で何かを動かしている最中は、Apple Siliconの8個のCPUコアがフル回転になって、なんとMacBook AirのF6キー辺りとその裏側が徐々に熱くなることです。
他のアプリで負荷をかけても、なかなかこういう状況を作り出すのは難しいのですが、WindowsのようなOSを丸ごとエミュレーションさせると、いくらApple Siliconといえどもフルパワーを発揮せざるるを得ない状況になるようです。
まさに『アツいぜ！Apple Silicon』です。

[English version of this post] 

[2021-01-08] タイトルを
「UTM appを使えば容易にIntel x86_64 WindowsやArm WindowsをApple Silicon M1 Macで実行でき、Apple Siliconがもっと熱くなる」
から
「Apple Silicon MacのUTM appを使えばWindows for Intelが簡単に動く、そして熱い」
に変えました。
[2021-01-10] Arm Windowsの動作上の制約について追記しました。
[2021-01-17] UTM appが専用webページで一般公開されて、すぐ使えるゲストイメージも公開されたので記事を書きました。
[2021-03-04] UTM appが使用しているQEMUのIntelエミュレーションが、たとえ現在はM1 Macで実用的な速度を出せない状況だとしても、M1XまたはM2のApple Siliconなら馬力で解決できるはず、という記事を書きました。
[2021-04-19] 有名なポッドキャスト「Appleるんるん」でこの記事が紹介されました、ありがとうございます。
お試しでIntel x86 Windows10をApple Silicon Macで実行する最短の手順を書きました。
[2021-05-05] Intel x86 Windows 10をApple Silicon Macにインストールする手順を書きました。
クリーンインストールすることでWindowsが以前よりも高速に動作しています。
[2022-01-08] UTM appでmacOSの仮想化ゲストも実行できるようになりました。

Mac miniで仮想化三昧 - VirtualBox, VMware, OpenStack

メイン環境を、Mountain Lion 10.8でとうとうサポートされなくなってしまった Mac mini early 2006 + Core 2 Duo 1.5GHz (macmini2,1) から、Mac mini late 2012 16GB (macmini6,1) に移行して3ヶ月経ちました。

Mountain Lionが使いたかったのもあるのですが、Mac上でUbuntu Linuxを動かし、仮想環境上でMountain Lionを動かせば、スムーズに使えて、一石二鳥ではないかと目論んでいました。
16GBは仮想環境を見越しての構成です。
本物のMac上の仮想環境でMac OS Xを動かすのはAppleも許している使い方です。
Ubuntu上の仮想環境はというと、

• VitrualBox 4.2.xでは、まだMountain LionはゲストOSとしてインストールできませんでした。
• VMware Playerでは、unlockパッチを使うと、Mountain LionをゲストOSとしてインストールできました。つい先日これを試しました。動作は多少もたつき、サウンドも出ません。メイン環境的に使うには到底無理がありそうです。また、Playerは無償版なので、スナップショット機能が使えないなど、機能制約があります。

という状況。

当初、Mountain LionとUbuntu Linuxをデュアルブートに設定していたのですが、ブートし直すのが面倒で、ほとんどUbuntuの方に切り替えることはありませんでした。
Ubuntu上でVMware Playerがうまく行ったので、こんどはMountain Lion上で、VMware Fusionを試してみました。

•  VMware Fusion 5では、何の苦労もなくMountain LionをゲストOSとしてインストールし、スムーズに稼働しました。期間限定無償評価版があるので、その気になりさえすれば、いつでも試せます。

並行して、どうしてもMS Officeが必要なことから、仮想環境上でWindows 7を動かしていたのですが、

• VirtualBoxでは、Windows Updateを実行するとOSが立ち上がらなくなる現象を何度か経験してしまいました。Windows Updateを実行する前にはバックアップとしてスナップショットを必ず取得し、おかしくなったら戻せるようにする必要がありました。私の環境だけかもしれませんが、不安要因です。
• VMware Fusionでは、VirtualBoxで起こっていた不安定さは今のところ出ていません。

という状況から、VMware主体に移行したいという思いが強くなりました。

Ubuntuでは、仮想化からもう一歩進んで、クラウドのOpenStackが標準？提供されています。
VMware Fusion 5では、nested virtualizationつまり仮想化の入れ子ができます。
ゲストOS上でOpenStackを動かして、その中で仮想環境を使えます。
実は当初の目論見としてもうひとつ、OpenStack上でWindowsやMountain Lionを稼働させる実験もあったのですが、まだまだOpenStackは敷居が高く、なかなか手が回っていませんでした。
今回は、

• Mountain Lion上のVMware Fusion上にUbuntu Serverをインストールし、haglx9さんの「Openstackインストール手順 (Grizzly) Ubuntu 13.04 (パッケージ)編」に忠実に従い、OpenStackの仮想インスタンスが起動するところ（右の上の画面）までやっとこぎ着けました。ただし、現状では仮想インスタンスがNo bootable device. で止まってしまっていますが。。。

までできています。
OpenStackは、一つの仮想化ソフトに閉じた世界での動作ではなく、複数マシンやAmazonクラウドまで制御・拡張できる夢があると感じています。

引き続き勉強してきたいと思っています。