UTM on Apple Silicon 設定

Apple Silicon Mac 用 UTM（基於 QEMU）跑 ARM64 Linux VM：

• CPU：UTM 使用 Apple Hypervisor.framework，ARM64 guest 接近原生速度
• GPU：使用 virtio-gpu-gl-pci（UTM v4.1+ 新建 Linux VM 的預設）。UTM v5.0.0+ 的 GitHub release 版支援 Venus driver（guest Mesa → host MoltenVK → Apple Metal 的 Vulkan 轉送路徑），這是目前最好的 GPU 加速方案
• Linux ISO：Arch Linux ARM（archlinuxarm.org）或 Fedora aarch64
• 建議配置：4 CPU cores、4GB+ RAM、40GB+ disk

UTM 建 VM 的注意事項

• 第一頁選 Virtualize，不是 Emulate——同架構（Apple Silicon 跑 ARM64 guest）兩條都是 QEMU，差在 Virtualize 走 hvf 硬體虛擬化（CPU 接近原生）、Emulate 走 TCG 純軟體模擬（CPU 慢一個數量級；實測 C++ 大型編譯一小時只跑 1/3）。Emulate 只在跨架構（ARM Mac 跑 x86_64 guest）才需要。判別現有 VM：guest 裡 lscpu 的 Model name 是 - 為直通、顯示具體型號（如 Cortex-A72）為模擬
• 選 「Linux」 虛擬機類型，不是 「Other」
• Display Card 選 virtio-gpu-gl-pci（有 3D 加速），不是 virtio-gpu-pci（無加速）；Emulate 精靈預設給無加速的 virtio-gpu-pci、Virtualize 精靈通常直接給對
• VM 視窗可能停在序列視圖、圖形顯示是另一個視圖——Virtualize 精靈預設多附一個序列裝置，UTM 視窗開機後可能顯示的是序列 console（文字登入、guest 裡 who 顯示登入在 pts/0），跟 virtio-gpu 的圖形輸出是兩個獨立視圖。切換：VM 視窗工具列的顯示器下拉選單 → 選 Display 1 (virtio-gpu)。判讀圖形裝置本身有沒有掛上看 guest 的 ls /dev/dri/（有 card0 = 裝置在、只是視窗看錯視圖）。不想每次切就到 VM 設定移除序列裝置。compositor 要在圖形視圖那側的 VT 上啟動、序列 console 起不了 Hyprland
• 如果用 App Store 版的 UTM（不含 Venus），只有基本的 virtio-gpu-gl 加速
• GitHub release 版的 UTM 支援 Venus/MoltenVK，效能更好但仍不及裸金屬
• 修飾鍵：Mac 的 ⌘ 對應 guest 的 SUPER，但 macOS 會先攔截部分 ⌘ 組合——Hyprland 的 keybind 幾乎都以 SUPER（Meta）當主修飾鍵（見 核心配置的修飾鍵段），而 UTM 裡 Mac 的 Command ⌘ 通常就是那顆 SUPER。問題是 macOS 自己會先吃掉某些 ⌘ 組合（⌘+Q 結束 app、⌘+Space Spotlight…），VM 收不到。判讀：SUPER 綁定沒反應、但焦點視窗打字正常，多半是宿主層攔截、不是 Hyprland 配置錯。解法：先確認 VM 視窗有 focus；在 UTM 的鍵盤/輸入設定開「把系統快捷鍵送進 VM（capture input）」讓 ⌘ 組合進 guest。臨時繞過：需要重載配置這類動作，直接在已開的終端機下指令（如 source / hyprctl reload），不必卡在 ⌘ 鍵上

VM 必要環境變數

在 Hyprland 配置裡加入以下環境變數（只在 VM 中使用，實機要移除）：

1-- VM-only environment variables
2env = {
3    "WLR_RENDERER_ALLOW_SOFTWARE, 1",  -- 允許軟體渲染 fallback
4    "WLR_NO_HARDWARE_CURSORS, 1",      -- 停用硬體 cursor（VM 常見問題）
5    "LIBGL_ALWAYS_SOFTWARE, 1",        -- 強制 Mesa 軟體渲染
6}

如果上述仍無法啟動（virtio-gpu vGPU passthrough 的情況）：

1env = {
2    "AQ_NO_KMS_REQUIREMENT, 1",       -- 繞過 KMS 需求
3    "WLR_RENDERER, pixman",            -- 強制 pixman 軟體 renderer
4}

[已驗證] Hyprland 0.55（Aquamarine）+ UTM virtio-gpu-gl-pci 實測：GPU 加速模式下 Hyprland 直接走 VirGL/Venus，不需要 WLR_RENDERER 或 WLR_RENDERER_ALLOW_SOFTWARE。AQ_NO_KMS_REQUIREMENT 仍有效。軟體渲染 fallback 路徑（WLR_RENDERER=pixman）未測試——有 GPU 加速時不需要走這條。

VM 中應該關閉的效果

軟體渲染下，視覺效果是最大的效能殺手。建議在 VM 配置中停用：

 1hl.config({
 2    decoration = {
 3        blur = { enabled = false },     -- 模糊是 GPU 最重的效果
 4        shadow = { enabled = false },
 5        rounding = 0,
 6    },
 7    animations = {
 8        enabled = false,                -- 或設定極簡動畫
 9    },
10})

這些效果關閉後，基本的平鋪操作（切換視窗、移動 workspace、開關 app）在 VM 中應該足夠流暢。

效能預期

VM 的價值在於驗證配置邏輯，不在於評估視覺體驗。如果在 VM 裡覺得「卡」，不代表 Hyprland 本身慢——多數情況是 VM 圖形加速的限制。

Sway 作為 VM 初步驗證工具

如果 VM 中 Hyprland 跑得太吃力，可以先用 Sway 驗證 VM 的 Wayland 圖形棧是否正常：

1sudo pacman -S sway foot
2sway

Sway 比 Hyprland 輕量（基於 wlroots、沒有華麗動畫），如果 Sway 能跑，代表 VM 的 Wayland 環境是正常的，Hyprland 的問題只是效能不夠。如果連 Sway 都跑不動，要回去檢查 VM 的 GPU 設定。

VM vs 實機測試矩陣

VM 中可完整驗證

需要實機測試

務實的 VM 使用策略

VM 階段的目標是「把配置寫好、驗證邏輯、確認 bootstrap script 能跑」，不是「體驗 Hyprland 好不好用」。具體做法：

1. 在 VM 中完成 Arch Linux 安裝 + Hyprland 套件安裝（怎麼把那台 Linux 從 ISO 裝起來、安裝程式選項怎麼判讀、裝完怎麼驗工具與連入，見 Linux 安裝與機器初始化）
2. 關閉所有視覺效果（blur / animation / shadow）
3. 寫好完整的 Hyprland 配置（keybind / rules / workspace / autostart）
4. 寫好 waybar / wofi / mako 配置
5. 測試 stow 部署流程（從 dotfile repo clone → stow → 配置生效）
6. 測試 bootstrap script（install.sh 從零到完整桌面）
7. 把驗證過的配置 commit 進 dotfile repo

到實機時，clone dotfile repo → 跑 install.sh → 補上硬體相關設定（monitor、GPU 驅動、觸控板）→ 打開視覺效果。VM 階段的工作在實機上幾乎不用重做。