拍照：VM 快照與磁碟映像

第一種是拍照。VM 快照和磁碟映像（Clonezilla、dd）做的事是把整台機器某一刻的完整狀態凍結存檔——整個虛擬硬碟的 block-level 複製，有時連記憶體狀態都包含。還原就是把映像寫回去，系統回到那一刻，像時光倒流。Docker 的 docker commit 也屬於這個方向：把正在跑的 container 的檔案系統快照成一個 image。

拍照產出的是黑盒子。一個磁碟映像是二進制檔案，沒人能看出裡面到底做了什麼設定、裝了什麼、改過什麼。它大（動輒 GB 級）、跟硬體耦合（換不同架構或不同顯卡可能開不起來）、無法做 diff 或 code review。

重建指令：Dotfile repo + install script

第二種是重建指令。Dotfile repo + install script 描述的是「怎麼從一台空白機器組出這個環境」，每次都從零開始執行。Dockerfile 也是重建指令——一份「照著做就能重現」的食譜，描述每一步該安裝什麼、複製什麼、怎麼啟動。

重建指令產出的是白盒子。每一步都是可讀的文字——這行裝 zsh、那行設定 Hyprland 的 keybind——可以被 review、被 diff、被另一個人讀懂。它小（通常幾十 KB）、跨硬體（同一份 script 加 OS 判斷就能跑在不同機器）、可以進版控走 PR 流程。

dotfile 管理選的是重建指令這條路。代價是你必須把環境建構的過程記錄清楚——每裝一個新工具、每改一個配置都要同步更新 repo。回報是任何一台機器、任何時間點，都能用一份 Git repo 重現你的工作環境。

場景判讀

兩者不互斥——常見的組合是：用 dotfile 管理配置（長期可維護的基線），VM 快照用於短期實驗保護（改爛了可以秒回）。

遠端機器突然連不上：先分清是哪一段斷

一台昨天還能 SSH 的機器今天連不上，第一步是確認「網路層通不通」，跟「SSH 服務在不在」分開。連線在 TCP 就 timeout（連 port 22 卡住沒回應），多半是網路層或機器沒在跑；連線有回應但被拒（Connection refused），是網路通、但那台機器上沒有服務在聽 port 22。

對虛擬機或同網段的機器，一個很有用的權威來源是鄰居表（IP 對 MAC 的對應）。要填起來需要對方在鏈路層有回應，所以它直接反映「對方在不在」。用 ip neigh 看目標 IP 的條目——優先用 ip neigh 而不是 arp -a，因為 ip（iproute2）在現代最小系統一定有，arp（net-tools）常常沒裝、跑了會 command not found 反而誤導。如果狀態是 INCOMPLETE（arp -a 顯示的是 incomplete），代表這個 IP 在鏈路層上根本沒有機器回應——不是 SSH 的問題，是那台機器的網路沒起來、或根本沒在跑。一個實際案例：一台虛擬機 SSH timeout，鄰居表顯示整個網段的 guest 位址全是 incomplete、只有閘道（宿主那側的橋接介面）是好的——這就定位到「宿主的橋沒問題，但橋的另一頭沒有 VM 在講話」，方向立刻從「調 SSH」轉到「去看 VM 的網路或開機狀態」。

定位到「機器在跑但網路沒起來」後，去那台機器的主控台（不是 SSH，SSH 正是連不上的東西）確認：ip -brief a 看有沒有拿到 IP、systemctl status <網路服務>（dhcpcd / systemd-networkd）看網路服務起了沒，需要時 sudo systemctl restart <網路服務> 重拉。IP 回來、鄰居表的條目從 incomplete 變成有 MAC，就通了。

還有一個常見誤區是 IP 變了。SSH 的別名、金鑰、known_hosts 都綁在特定機器身分上；換機器 / 重裝 / DHCP 重配後 IP 或 host key 變了，用舊別名會連錯或被 host key 檢查擋。這條的判讀與修法（ssh user@新IP 直連、ssh-keygen -R）見 外部連入與無 key 的 bootstrap 路徑。

網路通、但域名解析不了

有一種故障看起來像「網路壞了」，其實是 DNS 解析斷了：能連 IP、卻連不上任何用域名的東西——ping 8.8.8.8 通、但 ping google.com、pacman -Sy、curl https://... 全失敗。判讀要跟前面「網路沒起來」分開，因為網路層是通的，斷的是「域名 → IP」這一步。權威檢查：ping <IP> 通而 ping <域名> 不通、或 getent hosts <域名>（resolvectl query <域名> 若有 systemd-resolved）解不出位址，就定位到 DNS。常見成因是 /etc/resolv.conf 沒有可用的 nameserver（新裝或網路重設後沒填），或負責 DNS 的服務沒起來。修：確認 /etc/resolv.conf 有一行 nameserver（如 nameserver 1.1.1.1）、systemctl status systemd-resolved（若用它）。這一層在剛裝好的最小系統特別常撞到——ip -brief a 明明有 IP，pacman 或 bootstrap 卻抓不到套件，看起來像「網路好好的卻裝不了東西」，根因是 DNS 沒設。

虛擬機開不起來：分清 guest 內部還是宿主側

虛擬機開機失敗時，關鍵判斷是「錯誤來自 guest 內部（作業系統層）還是宿主側（虛擬化軟體 / QEMU 層）」。宿主側的錯誤訊息通常來自虛擬機軟體本身、在 guest 還沒開始開機前就跳出來，跟 guest 裡裝了什麼無關。

一個實例是 QEMU 報「找不到某個 ROM 檔」（例如 efi-virtio.rom）而拒絕啟動。第一反應可能是「檔案不見了要重裝」，但正確的第一步是去確認那個檔在不在——實際去虛擬機軟體的安裝目錄裡找（find <安裝目錄> -name '<rom名>'），會發現 ROM 檔明明就在。既然檔案在，「找不到」就不是缺檔，是 QEMU 執行時在它預期的路徑下找不到——成因隨宿主 OS 不同。在 macOS + UTM 宿主上，最常見的是 Gatekeeper app translocation：帶隔離屬性的 app 被搬到一個隨機唯讀路徑跑，讓 QEMU 解析資源的相對路徑失效，明明存在的檔案在那個執行路徑下就找不到。在 Linux 宿主上（沒有 translocation 這回事），同樣的「找不到 ROM」通常是缺對應套件（ovmf / ipxe-roms / edk2-ovmf）、libvirt XML 指的 ROM 路徑錯、或檔案權限不對——一樣先確認檔在哪、QEMU 是用哪個路徑去找。

另外兩個常見的「VM 起不來」故障也順手一起排除，它們不會特定產生「找不到 ROM」但常伴隨出現：上一次崩潰殘留的 helper 行程卡著（pgrep -af 'qemu|<虛擬機軟體名>' 找，沒清乾淨會佔住資源），以及宿主磁碟滿（df -h，啟動要寫暫存 / 狀態檔）。多數情況下，完全退出虛擬機軟體（連殘留 helper 一起清）+ 清出宿主磁碟空間 + 重新啟動，就恢復了。

判讀通則：虛擬機開不起來，先讀錯誤訊息判斷是 guest 還是宿主側；宿主側報「找不到某資源」而資源其實存在時，往「QEMU 是用哪個路徑找、那條路徑對不對」查（macOS 是 translocation、Linux 是缺套件 / 路徑 / 權限），再順手排除殘留行程與磁碟滿，而不是急著重裝。

磁碟滿是連鎖故障的共同根因

很多看起來各自獨立的故障，共同根因是磁碟滿。磁碟一滿，寫入就會失敗，而系統裡太多東西依賴寫入：SSH session 可能因為寫不了而被斷、正在跑的編譯 / 安裝會中途失敗、log 寫不進去、虛擬機狀態檔存不下導致連不上或開不起來。所以當你在短時間內撞到「連線斷了 + 某個任務失敗 + 服務怪怪的」這種一串症狀時，df -h 應該是很早就要做的檢查——一個廉價的檢查就可能一次解釋掉全部。

這裡有一個容易搞錯的點：清錯了地方。宿主跟 guest 是兩個獨立的檔案系統；虛擬機的宿主磁碟滿，跟 guest 內部磁碟滿，是兩件事。如果你 SSH 進 guest 裡 df 看到還有空間就以為沒事，但真正滿的是宿主的磁碟，那問題不會解決。判讀時要分清這串故障是「哪一台機器的哪個檔案系統」滿了——在宿主上 df -h 看宿主、在 guest 裡 df -h 看 guest，兩邊都要確認。清空間也要清在對的那一側。

判讀路由

• SSH timeout（TCP 卡住）→ 網路層或機器沒跑，查 ip neigh（INCOMPLETE = 對方沒回應）→ 去主控台看 ip -brief a / 網路服務。
• Connection refused → 網路通、但沒有服務在聽 → 去機器上確認 sshd 起了沒。
• 能 ping IP、不能用域名（pacman / curl 失敗）→ DNS 解析問題，查 /etc/resolv.conf 有沒有 nameserver、systemd-resolved 起了沒，不是網路層斷。
• 連錯 / host key 被擋 → IP 或身分變了，見 外部連入與無 key 的 bootstrap 路徑。
• 虛擬機開不起來、宿主側報「找不到資源」但資源在 → 主因查路徑隔離，再排除殘留行程（pgrep -af 'qemu\|...'）/ 磁碟。
• 一串症狀同時發生 → 早點 df -h，宿主與 guest 兩側都查，磁碟滿常是共同根因。

連不上只是最終症狀，真正的定位靠網路表、服務狀態、資源用量這些權威來源一層層往回推——完整的判讀紀律見 診斷心法。

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 階段的工作在實機上幾乎不用重做。