Hyper-V 本身不直接提供跨多宿主机的负载平衡功能，需结合故障转移群集、Live Migration 与 NLB 等机制协同实现：群集启用 VM 负载均衡策略自动迁移虚拟机以平衡资源；NLB 将客户端请求分发至多台虚拟机提升服务吞吐；大规模环境可借助 Azure Local 或 SCVMM 实现智能调度与闭环响应。
hyper-v 本身不直接提供跨多台宿主机的负载平衡功能，它主要负责单台物理服务器上的虚拟机调度与资源分配。要实现多宿主机间的负载平衡，需结合 windows server 故障转移群集（failover cluster）与虚拟机动态迁移（live migration），再配合外部或平台级负载分发机制（如 nlb、azure load balancer 或硬件负载均衡器）协同完成。
使用故障转移群集 + 动态迁移实现自动负载再分配
这是 Hyper-V 生态中最标准的多宿主机负载优化方式，适用于 Windows Server Datacenter 版本：
- 将多台 Hyper-V 宿主机加入同一个 Windows 故障转移群集，共享存储（如 SMB 3.0 共享、iSCSI 或 CSV）
- 启用“虚拟机负载均衡”（VM Load Balancing）策略：系统每 30 分钟自动评估各节点的内存压力与 CPU 使用率（5 分钟滑动平均），识别超载节点，并通过 Live Migration 将部分 VM 迁移至负载较轻的宿主机
- 确保所有宿主机网络配置一致（同名虚拟交换机、相同 VLAN 设置、时间同步）、启用 Kerberos 身份验证和 CredSSP 加密通道以支持无中断迁移
- 注意：该功能仅在群集启用了“虚拟机负载均衡”角色且运行 Windows Server 2016 及以上版本时可用；默认不开启，需通过群集管理器或 PowerShell 手动启用
搭配网络负载均衡（NLB）对外服务做流量分发
NLB 不平衡宿主机资源，而是将客户端请求分发到多个运行相同应用的虚拟机（可跨不同宿主机），从而提升整体服务吞吐与可用性：
- 在每台目标虚拟机（无论位于哪台宿主机）上安装并启用 Windows 的“网络负载均衡”功能
- 创建 NLB 群集，指定一个虚拟 IP（VIP）和虚拟 MAC 地址；所有成员 VM 都绑定该 VIP，对外表现为单一服务入口
- 选择操作模式：推荐使用多播模式（或 IGMP 多播），避免单播模式下交换机 MAC 表混乱；若使用 VMBus 虚拟网卡，需手动在 VM 设置中锁定 NLB 使用的 MAC 地址
- NLB 群集本身不感知宿主机状态，因此需配合群集健康检查（如通过 PowerShell 脚本定期探测 VM 可达性）或与故障转移群集联动实现节点自动剔除
利用 Azure Local 或 System Center Virtual Machine Manager（SCVMM）集中调度
当环境规模扩大、需精细化控制时，建议引入更高层管理平台：
- Azure Local 内置 VM 负载均衡引擎，支持基于内存压力与 CPU 利用率的周期性重平衡，且能感知新增宿主机并自动触发迁移
- SCVMM 提供统一仪表板，支持定义容量阈值、设置自动化策略（如“当某宿主机内存使用 >85% 持续 10 分钟，则迁移最多 2 台低优先级 VM”），还可集成监控（如 Azure Monitor）实现闭环响应
- 两者均要求宿主机已加入群集、启用 Live Migration 并配置好信任关系；SCVMM 还需额外部署管理服务器与数据库
关键注意事项与避坑点
实际部署中几个容易被忽略但影响成败的细节：
- 存储性能瓶颈比 CPU 更常见：NLB 或群集迁移产生的 I/O 放大效应，可能让共享存储成为瓶颈；建议将高 I/O VM 分散到不同物理磁盘或 NVMe 设备上
- 网络带宽与延迟必须达标：Live Migration 默认走管理网络，若未单独规划 10GbE 迁移专用通道，大内存 VM 迁移会显著拖慢业务响应
- 不要混用不同代际的虚拟机配置：例如同时存在 Gen1 和 Gen2 VM、不同版本 Integration Services、或部分 VM 关闭了 Heartbeat/Shutdown 等整合服务，会导致群集无法准确判断 VM 健康状态
- 生产环境务必先测试迁移影响：内存密集型或状态频繁变更的应用（如实时交易中间件），迁移过程中可能出现毫秒级暂停，需在非高峰时段验证业务容忍度
