Server 2012R2虚拟机Get-VHD返回0及Hyper-V脚本调度与模块并行问题

我碰到过好几次类似的情况，大概率是这几个原因导致的：

• Runspace权限上下文不匹配：默认Runspace作业通常以本地系统账户运行，如果VHD文件存放在CSV集群共享卷或远程存储上，这个账户可能没有足够的读取权限去获取真实文件大小。解决办法是创建Runspace时指定具备存储访问权限的凭据（比如域账户），或者确保Runspace的执行上下文和你手动运行Get-VHD时完全一致。
• 动态VHD实时读取限制：Server 2012R2的Hyper-V模块对运行中的动态扩展VHD存在读取盲区——如果Runspace没有正确关联Hyper-V的实时数据通道，可能只会读取VHD的初始占位大小（也就是0或极小值）。你可以先在Runspace里用Get-VM确认虚拟机状态，再针对关机的虚拟机测试Get-VHD；如果结果正常，那就是运行时的实时读取问题，这时候可以尝试用Get-VHD -DiskPath <VHD路径> -Dynamic参数，或者直接调用WMI类Win32_VirtualDisk来获取更准确的数值。
• Hyper-V模块加载不完整：Runspace默认不会自动加载模块的全部依赖项，尤其是2012R2的旧版本Hyper-V模块。建议在Runspace初始化脚本里手动导入完整模块：Import-Module Hyper-V -Force -DisableNameChecking，否则部分命令的返回值会缺失或异常。

你已经实现了按虚拟机分配独立作业，这个基础非常扎实，针对不同版本集群的兼容和调度优化，我给你几个实用方向：

1. 按集群版本隔离Runspace池 #

不要在同一个Runspace池里混用不同版本的模块，而是先将集群按WS 2012R2和WS 2016分组：

• 为每个版本创建独立的Runspace池，池内Runspace初始化时导入对应版本的Hyper-V模块。比如针对2012R2的池，指定旧版本模块路径导入：Import-Module "C:\Windows\System32\WindowsPowerShell\v1.0\Modules\Hyper-V\Hyper-V.psd1" -RequiredVersion 2.0；2016的池直接导入默认模块（版本3.0+）。
• 这种方式彻底避免了模块版本冲突，每个池的作业都能稳定使用对应版本的命令，无需在作业中途切换模块。

2. 优先采用PowerShell远程执行，规避本地模块兼容问题 #

更高效的思路是直接在目标Hyper-V节点上执行命令，不用在本地加载不同版本的模块：

• 为每个集群节点建立PowerShell远程会话（New-PSSession），在会话内执行Get-VM、Get-VHD等命令——这样所有命令都在节点本地运行，使用节点自带的Hyper-V模块，完全不存在版本兼容问题。
• 并行化方面，可以同时创建多个远程会话，每个会话处理一个节点的虚拟机；或者用Invoke-Command -ComputerName <节点列表> -ScriptBlock { ... } -AsJob批量触发远程作业，PowerShell会自动调度这些作业的并行执行。

3. 作业调度的效率优化技巧 #

• 节点负载感知分配：在分配作业前，先获取每个Hyper-V节点的CPU、内存使用率（比如用Get-Counter "\Processor(_Total)\% Processor Time"或Get-WmiObject Win32_OperatingSystem），将更多作业分配到负载较低的节点，避免单节点资源耗尽。
• 并发节流控制：不要一次性启动所有作业，比如限制每个Runspace池的并发作业数（比如最多10个），避免对存储或网络造成过大压力——尤其是CSV存储，并发读取过多VHD文件会显著降低性能。
• 错误重试机制：给作业添加重试逻辑，比如当某个虚拟机的命令执行失败（如临时存储连接问题）时，自动重试2-3次，而非直接标记失败，减少人工干预成本。

4. 缓存节点版本信息 #

首次运行脚本时，扫描所有集群节点的Hyper-V版本并缓存到变量或临时文件中，后续作业直接调用缓存信息选择执行方式，避免重复检测版本，节省执行时间。

内容的提问来源于stack exchange，提问作者Brendan McCoy