1. 偷天换日：NixOS宿主系统

计划

核心目标：旧 Windows 物理机退出，NixOS 接管硬件，Windows 以 VM 形态运行

【2026-10-08 节奏重排】存储定案 ext4，放弃 ZFS 与 /dataset。本计以「旧系统已打包 + D 盘空间已释放 + 盘2 NixOS 宿主机可用」为终点；盘1 分区归「2. 釜底抽薪」，克隆入盘1 / 双引导 / 主机完善归「3. 反客为主」，Win VM 的转换点亮与验收移于「5. 浴火重生」

【现行主线（2026-10-05 变更，见 C2）】转格式 + 离线注入 VirtIO 驱动 + 生成 libvirt 域，由 virt-v2v 在 NixOS 侧一条命令完成；下方第 1、4、11、12 步已取消，保留原文备查

【旧 Windows 环境（迁移前）】
  1. 安装 virtio-win-guest-tools（注入 VirtIO 存储和网卡驱动，防蓝屏）〔已取消（C2）：改由 virt-v2v 离线注入，无需预装〕
  2. 傲梅系统备份（生成 .adi 镜像）
  3. 傲梅“浏览镜像”恢复为 VHDX（.adi 是专有格式，qemu-img 无法直接识别）
  4. qemu-img 转换 VHDX → QCOW2：
     qemu-img convert -p -f vhdx -O qcow2 WinVM.vhdx Win10ltsc2021.qcow2
  5. Win10ltsc2021.qcow2 存入移动硬盘（作为 NixOS 环境的重建源）〔现行（C2/P4）：该文件不再产生，移动硬盘上保存的是 VHDX〕

【NixOS 环境】
  6. 底层构建：拔除硬盘1（防呆），在硬盘2（120G）安装 NixOS
  7. 存储骨架：硬盘1格式化为 ZFS，挂载 /dataset，创建 dataset：vms/ s500data/ repos/ docker/
  8. 移入镜像：将移动硬盘的 Win10ltsc2021.qcow2 放入 /dataset/vms/〔被 V1 覆盖（C2）：不再手工移入；V1 直接从移动硬盘读 VHDX，转换输出直接落 /dataset/vms〕
  9. 声明式虚拟化 (configuration.nix)：libvirtd + virtiofsd
     virtualisation.libvirtd.enable = true;
     qemu.vhostUserPackages = [ pkgs.virtiofsd ]; # 启用 VirtioFS
     networking.firewall.trustedInterfaces = [ "virbr0" ]; # 信任默认网桥
 10. 网络初始化：virsh net-start default && virsh net-autostart default
 11. 安全点亮：创建 Win VM，首次开机磁盘总线务必设为 IDE（确保能引导）〔已取消（C2）：virt-v2v 直接生成 VirtIO 域〕
 11. 安装 VirtIO 驱动后切回 VirtIO〔已取消（C2）〕
 12. 性能释放：进入系统确认 VirtIO 驱动挂载成功后关机，将磁盘和网卡总线切换为 VirtIO〔已取消（C2）〕

执行清单

路线：以 libvirt 官方转换工具 virt-v2v 为唯一主线。旧 Windows 侧只负责产出一个离线可引导的磁盘镜像；转格式、离线注入 VirtIO 驱动、生成 libvirt 域这三件事全部由 virt-v2v 在 NixOS 侧一次完成，不再需要先在 Windows 里装驱动，也不需要首次开机走 IDE 总线再切回 VirtIO。

编号规则：C = 前置确认；P = 旧 Windows 侧（下机前必须做完）；N = NixOS 宿主侧。本计终点是「盘2 NixOS 宿主机可用」（含运行 VM 的基础环境，因为克隆前必须就位）。盘1 分区归「2. 釜底抽薪」，克隆入盘1 / 双引导归「3. 反客为主」，Win VM 的转换、点亮与验收归「5. 浴火重生」。每条标题末尾带一个分工标记：〔手工〕= 只能你本人完成；〔Hermes〕= 我直接交付可执行产物。

前置确认

    • 冲突点：计划第 6 步假设有「硬盘1 + 硬盘2（120G）」两块盘
    • 实测现状：只有一块 2 TB NVMe，GPT 三段，ESP 0.54 GB + C 295.12 GB + D 1607.19 GB
    • 处理：先确认机器有无第二个 M.2 插槽（枚举到两个 NVMe 控制器 VEN_1987 / VEN_1C5C，第二个口疑似空着）；有则照原案另插 120G 盘，无则从 D: 划空间给 NixOS
    • 2026-10-05 复扫（修正上一条「第二个口疑似空着」的推测）：第二块 128 GB NVMe 已在位——disk1 = BC711 NVMe SK hynix 128GB（BusType=NVMe，非引导盘 IsBoot=False / IsSystem=False）；其上现有 NTFS 卷 F: GPDwin11（约 118 GB，剩 84 GB）与两个 EFI 分区（32 MB VTOYEFI、1.29 GB BC711EFI）；原案「有则照原案另插 120G 盘」这一步等于已具备，剩下要定的是该盘上现有的 GPDwin11 是否保留（不保留！）
    • 原计划：Windows 侧预装 virtio 驱动 → qemu-img 转 QCOW2 → 首次开机设 IDE 总线 → 装驱动后切回 VirtIO
    • 新主线：virt-v2v（libvirt 官方转换工具）一条命令完成「转格式 + 离线注入 VirtIO 驱动 + 生成 libvirt 域」
    • 因此取消三步：计划第 1 步预装 virtio-win-guest-tools、第 4 步 qemu-img 手工转换、第 11 至 12 步 IDE 总线保底与切回
    • 保留不变：傲梅系统备份产出镜像、libvirtd + virtiofsd 声明式虚拟化、网络初始化
    • 已执行（2026-10-05）：计划块已就地标注——第 1、4、11、12 步加〔已取消（C2）〕，第 5 步标注对象改为 VHDX，并在计划块首行写明现行主线；取消项与保留项按本条口径落地，其余计划原文逐字保留未删
    • 补充（2026-10-05）：计划第 8 步（移入镜像）同样为旧路线残留，已就地标注〔被 V1 覆盖（C2）〕——新路线下不再手工移入，V1 直接从移动硬盘读 VHDX、转换输出落对应目录
    • 补充（2026-10-08）：计划第 7 步（ZFS 骨架）与第 8 步的 /dataset 路径随 ext4 定案作废，执行清单里已直接清掉；计划原文保留备查
    • 冲突点：计划第 11 步只写了「首次开机磁盘总线设为 IDE」
    • 实测现状：固件是 UEFI，磁盘 GPT，ESP 段为 FAT32、卷标 BWINEFI
    • 处理：计划缺了固件类型这一条，VM 必须 OVMF/UEFI 引导；IDE 总线只是保底，替代不了固件类型
    • 2026-10-05 现场复核：$env:firmware_type = UEFI；BiosFirmwareType = Uefi；Confirm-SecureBootUEFI = False；disk0（系统盘）PartitionStyle = GPT；ESP = p1 type=System 577,744,896 字节（约 0.54 GB，FAT32 卷标 BWINEFI）；BCD 证据：{bootmgr} device = partition=\Device\HarddiskVolume1、path = \EFI\Microsoft\Boot\bootmgfw.efi，{current} path = \windows\system32\winload.efi —— 纯 EFI 引导链，无 BIOS/CSM 成分
    • OVMF 落地方式（待上机核）：NixOS 的 libvirtd 模块把 OVMF 固件放在 /run/libvirt/nix-ovmf/（OVMF_CODE.fd / OVMF_VARS.fd），域侧只需在 os 段写 firmware='efi'；上机核对两条命令 —— ls /run/libvirt/nix-ovmf/ 与 virsh capabilities | grep -i firmware
    • 源机 SecureBoot = False，所以取普通 OVMF_CODE.fd，不要用 .secboot（Microsoft 签名）变体，否则源映像会因签名校验起不来
    • 冲突点：计划未提及激活
    • 实测现状：OA3xOriginalProductKey present = False（密钥不在固件，激活通道 OEM_COA_NSLP）；vlmcsd（KMS 模拟器）在自启
    • 处理：虚拟化后硬件指纹变化，可能需要重新激活，先准备预案
    • 由我自己解决

第一部分｜旧 Windows 侧（下机前必须做完）

    • 动作：管理员 CMD 执行 powercfg /h off
    • 理由：休眠与快速启动会让 NTFS 处于 dirty 状态，镜像与后续转换可能不一致；顺带回收 23.93 GB
    • 复核：C:\ 根目录的 hiberfil.sys 消失；必须用 Get-ChildItem C:\ -File -Force 查看，不要用 Test-Path（它对受保护系统文件返回 False，会误判成不存在）
    • 注意：pagefile.sys 9 GB 不要动，崩溃转储取证链依赖它
    • 动作：无需动作，只做记录
    • 复核：C: 与 D: 均已是 FullyDecrypted / ProtectionStatus = Off
    • 注意：重建后注意别让系统自动开启设备加密
    • 复核（2026-10-05 现场执行）：Get-BitLockerVolume 结果 —— C: / D: / E: / F: 全部 VolumeStatus=FullyDecrypted、ProtectionStatus=Off、EncryptionPercentage=0、EncryptionMethod=None（两个无盘符的 VTOYEFI 卷同样未加密）→ 整机确认无 BitLocker，镜像与转换不存在解密障碍
    • 动作：只勾选 C: 与 ESP 分区，D:（1607 GB 数据盘）不进镜像；中间产物落盘路径选 D:（C: 只剩 91.23 GB）
    • 复核：.adi 的内容树里能看到那个约 0.54 GB 的 FAT32 ESP（卷标 BWINEFI）；没有 ESP 的镜像恢复出来不可引导
    • 说明：这是整条路线上唯一仍需第三方工具的一步，目的是产出一个离线可引导的磁盘镜像
    • D:\软件数据备份\EasyBackup_v6.10_免费安装版\max2_win10ltsc\max2_win10ltsc3.adi
    • 动作（原文，已作废 2026-10-05）：傲梅「浏览镜像」→ 恢复为 VHDX，直接落到移动硬盘
    • 复核：VHDX 含 ESP + 系统分区两段、GPT；virt-v2v 与 libguestfs 可直接读取 VHDX，无需预先转格式
    • 注意：不再执行 qemu-img convert，省掉一次对 200 GB 量级镜像的全量重写
    • 事实更正（作废原因）：傲梅轻松备份 6.10.1 没有「导出/恢复为 VHDX」这个功能 ——「浏览镜像」只能把镜像里的分区挂载成 Windows 里的虚拟分区/驱动器（只读浏览，不可导出）；已全量扫其界面字符串表 lang\zh-CN.txt 与 lang\en.txt，两套都没有 VHD/VHDX 词条
    • 现行做法：用 Sysinternals Disk2vhd 把当前系统直接转成 VHDX（VHDX 格式由扩展名决定；它保留源盘分区表，只拷贝选中卷的数据）
    • 工具入库：D:\softWin\installer\0_系统安装\Disk2vhd\（disk2vhd64.exe 等；签名 Valid、签发者 Microsoft Corporation、版本 2.02；原 zip 一并留存便于复用）
    • 实际执行：disk2vhd64.exe -accepteula -c C: X: E:\vms\max2_win10ltsc_system.VHDX —— 返回码 0，产物 175,190,835,712 字节（约 163.2 GiB）
    • 为什么必须 -c：VSS 不支持 FAT32，而 ESP 是 FAT32；若用默认的 VSS 模式，ESP 会被跳过成为空分区、VM 无法引导。 -c = 不建快照、按卷块直接拷贝
    • ESP 没有盘符，而命令行只能按盘符选卷：先用 mountvol X: /s 把 ESP 临时挂成 X:，任务结束后 mountvol X: /d 撤销（已确认 X: 已移除）
    • 复核方式：离线解析 VHDX（不挂载到系统）—— 因为镜像是运行中系统的克隆，其卷 GUID 与活着的 C: 完全相同，挂载有「Windows 把活卷置为脱机」的风险
    • 复核结果（容器与容量）：vhdxfile 头；虚拟磁盘 2.000 TiB = 源盘大小；BAT 1,048,576 项 × 2 MB 块 = 2 TiB 自洽；已分配 83,532 块 = 163.15 GiB，与文件大小吻合
    • 复核结果（分区表与源盘逐项相同）：ESP 577,744,896 字节（类型 EFI System，GUID 0e6cdb8a…）/ C: 316,879,667,200（GUID 503428e5…）/ D: 1,725,707,918,848（GUID 6eaa9bc4…）
    • 复核结果（数据是否真进了镜像）：ESP 首扇区 = MSDOS5.0 + FAT32 + 55aa，且带 FAT32 备份引导扇区 → ESP 数据已入镜像；C: 首扇区 = NTFS + 55aa，且 +50 GiB / +140 GiB 处均有数据 → C: 数据已入镜像；已分配量 ESP 0.04 GiB、C: 163.08 GiB、D: 0 GiB（正确：只选了 C: 与 ESP，D: 只保留分区壳）
    • 注意（-c 的代价）：得到的是「崩溃一致」镜像而非 VSS 时点快照，首次开机 NTFS 会回放日志、可能提示检查磁盘；傲梅的 .adi 仍是无损参考副本。若坚持时点一致，可另用 VSS 模式只做 C:（代价是 ESP 仍拿不到）
    • 注意（最终判据）：结构完整只说明「没丢东西」，不等于「一定能启动」—— 可引导性最终要在 VM 里验证（归计5）
    • 已完成（2026-10-05）：成品改名为 E:\vms\max2_win10ltsc_system.VHDX（与 .sha256 同名文件放一起，便于后续搬运比对）
    • 复核：移动硬盘剩余空间不少于 250 GB（按 C: 已用 203.89 GB 估）
    • 复核：拷贝完成后校验哈希一致
    • 动作：对 D:\DCIMData\1爱好\旧中国老照片 生成清单 CSV（相对路径 / 大小 / 修改时间 / 创建时间），并在移动硬盘上建动态 VHDX（内 NTFS）把整集灌入，用 /COPY:DAT /DCOPY:DAT 保住时间戳；再算逐文件 SHA256 清单
    • 实测规模：38,265 个文件、8,966,022,028 字节（约 8.97 GB）、79 个子目录；日期范围 1800-03-10 至 2023-03-11，其中 1970 前 29,465 个、1901 前 836 个
    • 理由：这批日期只有 NTFS（1601 起）能承载——ext4 / XFS 下限 1901，HFS+ 1904，ZFS 存疑，exFAT 1980；且 Windows 写 NTFS 走原生路径日期必然保真，拖到 Linux 侧要赌 ntfs3 的写路径
    • 复核：清单行数 = 38,265、总字节 = 8,966,022,028；VHDX 内抽查最早日期应为 1800-03-10（被夹到 1970 即失败）；镜像内文件数与字节与源一致
    • 注意：盘1 的 C: 与 D: 在同一块物理盘上，迁移中整体消失，所以镜像与清单必须落在移动硬盘（E:，迁移中唯一幸存介质）
    • 实测与落盘（2026-10-05 已完成）：清单 manifest_old-china-photo.csv 38,265 行 / 6,126,077 字节；镜像 photo-archive.vhdx 9,231,663,104 字节（动态 VHDX，内 NTFS 卷标 PHOTOARCH）；逐文件日志 robocopy.log
    • 三层复核全过：拷贝侧 MISSING=0 / DIFFVAL=0；1970 前 29,465、1901 前 836 与源逐项相等；最早时间戳 1800-03-10 21:10:29 未被夹到 1970；脱离拷贝现场后只读重挂并用清单反向核对 38,265 条全中
    • 容器指纹：photo-archive.vhdx 的 SHA256 = 846EC34810186A6AE14FB3F117D1C7743B55A7FE3ADDF7A96BFD10EB182DD77D（已落 photo-archive.vhdx.sha256）；容器级哈希换格式即失效，只用于「还是那一份」的自证
    • 逐文件哈希清单：manifest_old-china-photo.sha256.csv（相对路径 / 大小 / 修改时间 / SHA256）——跨格式、跨文件系统的唯一完整性基线，raw 与 VHDX 两侧应算出同一组哈希
    • 双形态定案：raw 给 Linux（内建 loop，一等公民）、VHDX 给 Windows（原生附加，一等公民）——不做折中，各用各的最优格式
    • 动作：裸机 Windows 上分别用 780M 与 4060 各跑鲁大师（可另加一次 3DMark 作参考），记录分数、驱动版本、跑分顺序与当时温度 / 时钟
    • 理由：迁移后要在 Win VM 内用同一工具复测，才能量出「NixOS 管显卡 + 虚拟化供给」与「GPU 直通」各自损失多少；基线的唯一采集窗口就是下机之前
    • 复核：每个 GPU 至少 3 轮取中位数，原始日志与截图落盘；4060 的 eGPU 链路代数与宽度一并记录（此前实测出现过 gen1 与 gen4 跳变、宽度 w4）
    • 注意：跑分前把 VIDEOCONLOCK 置 0（当前 30 秒，锁屏会关屏并触发一次 HPD / 显示重配置，静默污染结果）；锁屏下 SetForegroundWindow 返回 False，全屏基准可能起不来；nvidia-smi 的 power.draw 在负载跳变时不可靠，功耗用遥测脚本采
    • 动作：把 P6 清单、P7 原始日志与截图、工具版本与分辨率统一归档到移动硬盘（与 savedata/egpu-forensics 同风格）
    • 复核：迁移后打开就能看到「旧裸机 780M」与「旧裸机 4060」两组基准值，且能与计5 的结果直接并表
    • 之前已有记录 E:\S500data\DEVICE_ini\笔记本-GPDWinMax2\性能测试 和 E:\S500data\DEVICE_ini\归档\显卡坞-诺方恒科n-p114-a直插启停-麻糬儿r\4060性能测试

第二部分｜NixOS 宿主侧（盘2）

    • 动作：按 C1 的结论决定装到哪块盘（盘2，128G）
    • 复核：固件 UEFI、Secure Boot 关闭（现固件 SecureBoot = False，保持一致即可，无需额外处理）

    • 引导安装：uefi引导ventoy，选择iso文件，标准普通模式，选gnome桌面installer, 7.2.8内核，进安装桌面后界面操作连wifi和代理，我用的手机热点和代理设置到终端变量再sudo 启动安装器

      export http_proxy=http://127.0.0.1:7890
export https_proxy=http://127.0.0.1:7890
sudo -E calamares
    • 安装设置：四空和cc6，后续使用选plasma适合多屏，安装分区ESP给1G，剩下ext4格式全给/，先不划swap，后续用 zramSwap动态压缩
    • 首次设置：第一次启动大概率是黑屏，need unplugin ext screen, or 按ctrl+alt+F2进终端
    • 安装后，修改nixos配置后重建初始配置

    • mihomo proxy install docker mihomo 网速慢问题

      docker mohomo
curl -sS -x http://127.0.0.1:7890 -o /dev/null -w "%{http_code}\n" https://www.gstatic.com/generate_204

    • 立刻安装hermes：Hermes desktop安装报错 操作命令

      curl -fsSL https://hermes-agent.nousresearch.com/install.sh | bash
hermes import /run/media/cat/Ventoy/S500data/软件数据备份/hermes备份/hermes-backup-20261006-091735.zip
    • rime输入法薄荷方案 rime 输入法无法输入拼音