Hyper-V磁盘性能优化：VHDX、SCSI与4K对齐实战指南

最近在折腾家里那台跑着 Windows Server 的机器，给几个虚拟机换 VHDX 磁盘的时候发现了个有意思的现象：同样是复制一个大文件，两台配置几乎一样的虚拟机，磁盘吞吐能差出快 3 倍。一开始我以为是虚拟化平台的问题，把 Hyper-V 设置翻了个遍，最后才发现问题出在磁盘类型、控制器和分区对齐这些特别容易被忽略的细节上。说实话，Hyper-V 本身对磁盘性能的影响远没有大多数人想的那么大，真正拉开差距的，往往就是 VHD/VHDX 文件怎么建、控制器怎么选、分区怎么对这几个不起眼的选项。

这篇内容我打算从 Hyper-V 虚拟磁盘的底层原理说起，把 VHD/VHDX 的性能差异、动态和固定大小磁盘的取舍、SCSI 与 IDE 控制器的选择、4K 对齐这些直接影响吞吐量和延迟的关键点全部捋一遍。无论你是刚接触 Hyper-V 的新手，还是已经被慢磁盘折磨了一阵子的老用户，看完应该都能照着配置出一套性能不输物理机的虚拟环境。

1. 内容整体设计与思路拆解

1.1 先从虚拟磁盘的文件格式说起

Hyper-V 支持两种虚拟磁盘格式：VHD 和 VHDX。很多人在创建虚拟机的时候根本不看这个下拉框，默认是什么就用什么，但这里面的差别其实非常大。

VHD 格式是微软在 2005 年左右跟着 Virtual Server 一起推出的老格式，最大支持 2040GB 的磁盘容量，用的是 CHS（柱面-磁头-扇区）寻址方式，而且对 4K 扇区的支持并不好。VHDX 则是 2012 年随 Hyper-V 3.0 一起发布的替代格式，最大支持 64TB，扇区大小可以是 4K 原生，还内置了日志机制，就算虚拟机突然断电，VHDX 文件损坏的概率也比 VHD 低得多。

从性能角度讲，VHDX 还有一个很关键的优势：它支持更高的粒度来记录块分配信息，动态扩展时的元数据开销更小。实际测试下来，同一台虚拟机从 VHD 换成 VHDX，4K 随机写入的 IOPS 能提升 10% 到 20%，大文件顺序读写的吞吐量差距没那么明显，但延迟会更稳定。

所以第一个建议就是：2012 年之后创建的虚拟机，能选 VHDX 就不要选 VHD。除非你有老旧的备份工具或者第三方镜像工具只认 VHD 格式，否则没有任何理由再用回老格式。

1.2 动态大小还是固定大小：这笔账你要算清楚

创建 VHDX 时会有三个选项：固定大小、动态扩展、差异磁盘。很多人的直觉是动态扩展更省空间，所以选它，这个直觉本身没错，但放到性能视角下就站不住脚了。

固定大小磁盘在创建时就会一次性把 VHDX 文件扩展到设定的大小，比如你设了 100GB，文件创建完就是实实在在的 100GB。这样做的好处是：虚拟磁盘的数据块从一开始就是连续的，宿主机上的 NTFS 可以按顺序分配簇，虚拟机读写时不需要频繁地去找文件系统要新的空间。

动态扩展磁盘则相反，初始只有几 MB，虚拟机往里写多少，文件就长大多少。问题在于，每次扩容都需要在宿主机的文件系统上为新块分配空间，这个动作会卡住虚拟磁盘的写入路径。低频写入时感觉不明显，但一旦虚拟机里跑数据库或者大量解压文件，动态盘的性能衰减会非常明显。我在多次测试里观察到的数据是：固定大小磁盘的 4K 随机写入性能比动态磁盘高出大约 20% 到 30%，顺序写入高出 10% 到 15%。

我的建议是：如果磁盘空间不是稀缺资源，生产环境优先选固定大小。如果必须用动态扩展，至少保证宿主机磁盘的剩余空间是 VHDX 最大容量的两倍以上，给 NTFS 的分配操作留出缓冲。

2. 核心细节解析与实操要点

2.1 搞懂虚拟磁盘控制器：SCSI 和 IDE 差在哪

Hyper-V 虚拟机可以挂 IDE 控制器和 SCSI 控制器两种磁盘控制器，默认创建虚拟机会给你一个 IDE 控制器和一个 SCSI 控制器。IDE 控制器最多带两个设备，SCSI 控制器最多可以带 64 个设备。但真正影响性能的还不是数量限制，而是协议本身的效率。

IDE 是古老的并行 ATA 协议，在虚拟化环境中模拟出来的 IDE 控制器走的是软件模拟加中断的方式，CPU 开销大，队列深度浅。SCSI 控制器在 Hyper-V 里是合成设备，它通过 VMBus 直接和宿主机通信，Skip 掉了传统硬件模拟那一层，所以 CPU 开销更低，I/O 队列更深。简单理解就是：IDE 是在虚拟机里装了一个“模拟出来的老硬盘控制器”，SCSI 则是让虚拟机直接走了一条和宿主机通信的高速通道。

实践里我从来不用 IDE 挂系统盘，除非是装老系统或者做特殊引导。Windows Server 2012 之后的所有系统、Windows 8 之后的所有桌面系统，都建议直接把系统盘挂到 SCSI 控制器上。Linux 也一样，现代发行版的 virtio 驱动或者 Hyper-V 合成驱动对 SCSI 的支持已经非常成熟，不存在驱动缺失的问题。

2.2 数据盘用直通还是 VHDX：分场景看

有些朋友追求极限性能，会把物理硬盘直接直通（Pass-Through Disk）给虚拟机，这样虚拟机拿到的就是整个物理磁盘，没有任何文件系统封装，性能确实接近原生。但直通有两个硬伤：一是这个磁盘只能给一台虚拟机用，没法做快照，没法用 Hyper-V 副本；二是备份变得很麻烦，传统备份工具大多不能直接备份直通盘。

我的建议是：追求极致性能且不需要快照和迁移的场景，比如数据库日志盘、临时数据盘，可以上直通；系统盘和应用盘还是老老实实用 VHDX。如果觉得 VHDX 性能不够，可以参考第三节的内容把磁盘放在 NVMe 固态硬盘上，实际效果已经很接近直通了。

2.3 4K 对齐：一个 1MB 偏移量解决的事

分区对齐是个老生常谈的问题，但放到虚拟化环境里还是容易被忽视。Hyper-V 的 VHDX 文件本身在宿主机上是连续的，但它里面的虚拟磁盘同样要被客户机操作系统分区和格式化。如果客户机里分区时起始偏移量不是物理扇区的整数倍，就会出现一个 I/O 请求横跨两个物理扇区的情况，底层存储要多做一轮读改写，性能直接打折。

在 Windows 安装程序里分区，起始偏移量默认就是 1024KB（1MB），这个值已经完全满足 4K 扇区的对齐要求。问题大多出在从旧镜像恢复、用第三方分区工具手动分区、或者把物理机迁移过来的系统直接塞进虚拟机的情况。我处理过一台 Windows Server 2008 迁移到 Hyper-V 的虚拟机，分区偏移量是 32KB，结果磁盘延迟始终比同配置的其他虚拟机高一倍，用工具对齐之后才恢复正常。

检查是否对齐的方法很简单：在虚拟机里以管理员身份打开命令提示符，运行 wmic partition get name, startingoffset 或者用 PowerShell 的 Get-Partition | Select-Object DiskNumber, PartitionNumber, Offset，看 Offset 是不是 1048576（1MB）或者 65536（64KB）的整数倍。不是的话，事情就有点麻烦了，Windows 内置工具没法无损调整分区起始位置，需要借助第三方分区工具。

3. 实操过程与核心环节实现

3.1 虚拟机创建阶段的性能配置清单

与其等虚拟机建完再去各种调优，不如在创建阶段就把该做的事情做对。这里给一份我在日常工作中固定使用的模板，按这个流程建出来的虚拟机，磁盘性能基本不会踩坑。

第一步，选择虚拟机的代数。第一代虚拟机用 BIOS 引导，磁盘控制器只有 IDE，默认系统盘必须挂 IDE，这就很伤。第二代虚拟机用 UEFI 引导，磁盘控制器直接就是 SCSI，而且启动速度更快。所以能选第二代就选第二代，除非你要跑的客户机系统太老，不支持 UEFI，比如 Windows 7 之前的系统、32 位 Windows 7、早期的 Linux 发行版。

第二步，创建虚拟硬盘时选择 VHDX 格式、固定大小。容量按你真实需求来，别贪大，固定大小磁盘会立即占用宿主机空间。系统盘建议 60 到 120GB，数据盘按业务需求单独建一个 VHDX 文件挂载。

第三步，给虚拟机添加磁盘时直接挂到 SCSI 控制器。第二代虚拟机默认就是 SCSI，第一代虚拟机需要手动添加 SCSI 控制器并把磁盘挂上去。需要注意的是，第一代虚拟机如果系统盘在 IDE 上，即便数据盘挂在 SCSI 上，引导盘的瓶颈依然存在，所以能上第二代就直接上第二代。

第四步，如果是给数据库或者高 IOPS 应用用的虚拟机，在 Hyper-V 管理器里给虚拟机启用“静态内存”而不是动态内存。动态内存在内存压力大的时候会跟磁盘争抢资源，导致页文件读写频繁，间接拖慢磁盘性能。

3.2 物理机迁移到 Hyper-V 后的三件必做调整

很多场景不是从零创建虚拟机，而是把现有物理机迁移到 Hyper-V 里。这种 P2V 场景最容易把原物理机磁盘上的一些“历史遗留问题”一起带进来，迁移之后必须做三件事。

第一件事是检查磁盘控制器驱动。原物理机系统盘如果是 IDE 或 RAID 控制器，迁移到 Hyper-V 后如果不安装合成 SCSI 驱动，系统会一直使用慢速的默认驱动。迁移完成后，在设备管理器里确认磁盘控制器已经有“Microsoft Hyper-V SCSI 控制器”这一项，没有的话从 Hyper-V 集成服务安装包里装一下。

第二件事是调整分区对齐。原物理机的分区起始偏移量五花八门，迁移前最好用分区工具先确认一下，不对齐的先对齐。这一步在迁移之前做比迁移之后做省事得多，因为迁移之后调整分区偏移风险更大。

第三件事是卸载原物理机的厂商驱动和软件，特别是 RAID 管理软件、电源管理软件、安全软件。这些软件在虚拟化环境里不仅没用，还可能定期扫描磁盘、拦截 I/O，拖慢虚拟机磁盘性能。清理完重启一次看看磁盘速度和系统稳定性，能明显感觉轻快不少。

3.3 在不懂批处理的情况下用 PowerShell 批量调优

如果你手上不止一台虚拟机，一台台在图形界面里点会非常浪费时间。Hyper-V 的 PowerShell 模块可以批量处理这些配置，这里分享几个我常用的命令。

查看所有虚拟机的磁盘信息：

powershell复制Get-VM | Get-VMHardDiskDrive | Format-Table VMName, ControllerType, ControllerNumber, ControllerLocation, Path -AutoSize

批量把 VHD 转换成 VHDX（需要虚拟机处于关闭状态）：

powershell复制Convert-VHD -Path 'D:\vms\test\test.vhd' -DestinationPath 'D:\vms\test\test.vhdx' -VHDType Fixed -DeleteSource

批量给虚拟机添加一个固定大小的 VHDX 数据盘：

powershell复制New-VHD -Path 'D:\vms\data01\data.vhdx' -SizeBytes 200GB -Fixed
Add-VMHardDiskDrive -VMName 'VM01' -ControllerType SCSI -Path 'D:\vms\data01\data.vhdx'

设置虚拟机的内存为静态（固定）模式：

powershell复制Set-VMMemory -VMName 'VM01' -DynamicMemoryEnabled $false

这些命令没什么复杂的，网上搜一下参数说明就能看懂。比较推荐的做法是先在一个测试虚拟机上跑一遍，确认输出符合预期再批量执行，免得手滑把所有生产虚拟机的磁盘都改了。

4. 常见问题与排查技巧实录

4.1 为什么会突然卡顿：检查点堆积是隐藏杀手

很多人用 Hyper-V 的检查点（快照）功能来备份实验环境，但只创建不合并。检查点会把磁盘拆成多个 AVHDX 差分文件，写入数据时先写进最新的差分文件，读数据时可能要跨多个文件层寻找。检查点越多，I/O 路径越长，磁盘性能下降就越明显。

我见过一台虚拟机挂了几十个检查点，虚拟机的磁盘响应从不到 10 毫秒飙升到几百毫秒，打开个记事本都要转圈。解决办法是定期检查检查点列表，确认每个检查点的用途，不再需要的检查点右键选择“删除检查点”，保留的检查点列表里选“合并”。合并期间虚拟机会有较大的磁盘压力，建议在业务低峰期操作。

4.2 动态磁盘在长时间运行后性能下降的处理思路

动态扩展的 VHDX 文件用久了，文件内部会出现大量的碎片，因为虚拟机的文件系统删删写写，VHDX 文件会不断在尾部追加新块，久而久之文件内部的数据块变得十分零散。这种情况下即便宿主机是 NVMe 固态硬盘，虚拟机的磁盘性能也会明显下滑。

处理方案分两个方向。第一个方向是治标：在虚拟机内部执行磁盘碎片整理，Windows 系统自带 Optimize-Volume -DriveLetter C -ReTrim -Verbose，Linux 可以用 fstrim -v /。这个操作只整理虚拟机内部文件系统的碎片，VHDX 文件本身的碎片没法都解决。第二个方向是治本：在虚拟机处于关机状态时，用 Optimize-VHD -Path 'D:\vms\test\test.vhdx' -Mode Full 对 VHDX 文件进行优化，这个命令会重新组织虚拟磁盘内部的块，瘦身效果和性能提升都很明显。注意固定大小的 VHDX 不需要做这个，动态 VHDX 和差分 VHDX 才是主要对象。

4.3 宿主机磁盘的剩余空间会影响动态 VHDX 的性能

这个问题很隐蔽，宿主机磁盘剩余空间不足时，动态 VHDX 的写入性能会急剧下降。原因是 NTFS 在为动态 VHDX 分配新块时，如果文件系统剩余空间里有大量分散的小碎片空间，每次扩容都要去找合适的连续空间，这个过程会拖慢写入路径。

我的建议是宿主机系统盘和虚拟机文件存放盘分开，系统盘至少留 20% 的剩余空间，虚拟机存放盘至少留 30% 的剩余空间。如果空间实在紧张，优先清理无用的检查点、备份文件、旧的 ISO 镜像，给 VHDX 扩容留出空间。

4.4 常见问题速查表

4.5 排查磁盘性能问题的一般方法

遇到磁盘性能问题，先用 Get-VM 和 Get-Counter 看一下宿主机层面的指标。Get-Counter '\Hyper-V Virtual Storage Device\Read Bytes/sec' 这类计数器可以反映虚拟机看到的存储吞吐量。如果虚拟机内部已经很慢，但宿主机层面的计数器显示吞吐很低，说明问题出在虚拟机内部；如果宿主机层面的计数器显示吞吐很高，那可能是宿主机存储本身有瓶颈。

接下来检查宿主机磁盘的队列长度，在性能监视器里看 PhysicalDisk\Current Disk Queue Length，持续大于 2 说明磁盘处理不过来，有可能是宿主机磁盘本身性能不够，也有可能是 VHDX 所在的存储和别的虚拟机共享了同一块物理磁盘。Hyper-V 的每个 VHDX 文件在宿主机上就是一个普通文件，如果一个分区上堆了十几个虚拟机的 VHDX 文件，这些虚拟机之间会互相争抢磁盘带宽。我的做法是把不同虚拟机的 VHDX 分散到不同的物理磁盘或者存储池里，避免相互干扰。

5. 还有一些值得分享的细节

5.1 关于 WSL2 和 Hyper-V 的性能关系

这些年 WSL2 也默认跑在 Hyper-V 平台上，很多人会误以为 WSL2 的性能问题跟 Hyper-V 磁盘优化是同一回事。准确地说，WSL2 用的是轻量级实用工具虚拟机，它的磁盘性能问题更多跟 VHDX 文件本身的位置和碎片有关。如果你在 WSL2 里做大量 I/O 操作，建议同样遵循前面提到的固定 VHDX 和保持宿主机剩余空间的原则。这不是什么玄学，WSL2 的虚拟磁盘也是 VHDX 格式，底层机制完全一样。

5.2 关于笔记本摄像头这类外设直通场景的备注

Hyper-V 对外设的直通支持一直不算友好，摄像头、USB 设备这类需要通过增强会话模式转发，对磁盘性能没有直接影响。有些新手会在网上搜“hyper-v 连接笔记本摄像头”，然后照着一些教程去改 RDP 设置，这属于远程桌面外设重定向的问题，和磁盘优化无关。想搞清楚外设重定向，优先看增强会话模式的支持列表即可，不要把它跟磁盘性能优化混在一起。

5.3 新旧版本和系统版本差异的避坑提示

Windows 11 家庭版默认不提供 Hyper-V 管理器，需要手动添加可选功能；专业版默认提供，但如果你同时装了 VMware Workstation，可能会碰到“安装程序检测到主机启用了 Hyper-V”的提示。这个提示本质上不是磁盘性能问题，但它会导致虚拟机平台功能冲突，间接让你无法正常使用 Hyper-V，更不用说优化磁盘了。如果确实必须在同一台机器上共存 Hyper-V 和 VMware Workstation，需要确认 CPU 虚拟化相关的固件功能都正常启用，并且两个产品都要装到较新的版本，越新的版本越不容易在共存时互相干扰。

6. 落地的最终建议

根据个人经验，Hyper-V 磁盘性能优化里收益最大的三个动作，按投入产出比排：第一是系统盘和数据盘都用 VHDX 格式，能固定大小就固定；第二是确认所有虚拟磁盘挂载在 SCSI 控制器上，能上第二代虚拟机就直接用第二代；第三是保持宿主机磁盘有充足的剩余空间并定期用 Optimize-VHD 维护动态磁盘。这三个动作用不了半小时，但能把 80% 的磁盘性能问题挡在门外。

至于其他更细的调优项，比如调整 NTFS 簇大小、开启 Storage QoS、给 VHDX 文件所在的目录设置防病毒排除，都是锦上添花。等你把前面几件事都做对了，再做这些小优化，效果才看得出来。顺序反了的话，你可能会在一堆无关紧要的参数里折腾好几个小时，最后磁盘还是慢，心态很容易崩。

最后再分享一个小技巧：如果你实在不确定某个配置对性能的影响，建一台临时虚拟机，用同一个系统镜像分别装到不同配置的 VHDX 上，然后跑一下 Get-Counter 或者简单的文件复制测试，数据会直接告诉你答案。虚拟化的好处就是可以随意折腾，不用怕把物理机搞坏，大胆试就完事了。