本技术资料把 Windows Server 2025 上的 Hyper-V 架构整合在一个视角中：虚拟化管理程序和根分区、虚拟机与 NUMA、存储与虚拟网络、高可用，通过 Windows Admin Center、System Center VMM 和 Azure Arc 实现的混合管理，以及 Windows Server 和 System Center 的许可。
目标是同时服务三类读者——架构与工程、基础设施运维，以及技术与财务决策——其中的数值化容量示例属于工程模型，而不是实验室基准测试。
关于本资料：内容整合自微软的公开文档（Microsoft Learn 和许可页面），参考资料查阅于 2026 年 9 月 2 日。许可规则因商业计划、软件保障（Software Assurance）、CSP、企业协议和地区而异——最终应与负责合同的经销商或许可专家核实。
Hyper-V 是什么，适用于哪里
Hyper-V 是微软集成在 Windows Server 中的 Type 1 虚拟化管理程序。启用该角色后，Windows Server 会开始运行在虚拟化管理程序之上：管理操作系统运行在根分区（root partition）中，而虚拟机运行在相互隔离的子分区中。这使它有别于托管型（Type 2）虚拟化管理程序，后者的传统操作系统仍然直接运行在硬件上。
生态组件
| 组件 | 在环境中的角色 |
|---|---|
| Hyper-V | 对 CPU、内存、存储、网络和设备进行虚拟化。 |
| 故障转移群集（Failover Clustering） | 为宿主机和虚拟机提供高可用，支持故障转移和 Live Migration。 |
| Windows Admin Center | 用于管理宿主机、集群、虚拟机、存储、网络和混合服务的 Web 仪表盘。 |
| System Center VMM 2025 | Fabric 管理、模板、私有云、逻辑网络与存储、放置和自动化。 |
| Azure Arc | 把 Azure 控制平面延伸到本地和多云的服务器及虚拟机。 |
| Microsoft Entra ID | 混合管理平面中的身份与 RBAC；并不在每一种集群场景中都取代 AD DS。 |
产品状态
不存在与旧版独立产品对应的免费“Hyper-V Server 2022/2025”。Hyper-V Server 2019 是最后一个独立版本，其扩展支持将于 2029 年 1 月 9 日结束。对于新项目，参考点是作为 Windows Server 2025 角色的 Hyper-V，或 Azure Local。
最适用的场景
- 以微软为中心、基于 Windows Server 和 Active Directory 的私有云。
- 希望降低对 VMware 依赖，同时保留企业级集群能力的环境。
- 宿主机很少的分支机构和边缘站点，使用 Windows Admin Center 和 Azure Arc。
- 高度虚拟化的数据中心，其中 Windows Server Datacenter 和 SCVMM 提供虚拟化权利和集中管理。
- Linux 工作负载和设备，前提是已对照厂商的支持矩阵验证。
- Windows Server 2025 上的 GPU 工作负载，包括受支持场景中的 DDA 和 GPU 分区（GPU Partitioning）。
起点：选择 Hyper-V 作为平台时，应把架构和许可放在一起考虑——在大量虚拟化的 Windows 环境中，Datacenter 版本会显著改变经济性。
虚拟化管理程序架构
虚拟化管理程序负责分区之间的隔离和调度。根分区包含管理栈和物理驱动。现代虚拟机使用合成设备和 VMBus，避免了模拟设备的性能损失。集成服务和更新的驱动降低了 CPU 开销并改善了 I/O。
第 1 代与第 2 代
| 特性 | 第 1 代 | 第 2 代 |
|---|---|---|
| 固件 | 传统 BIOS | UEFI |
| 启动 | IDE / 传统 | SCSI / UEFI |
| Secure Boot | 否 | 是 |
| vTPM | 有限 / 间接 | 视操作系统和配置而定，受支持 |
| WS2025 上的 vCPU 规模 | 最多 64 | 最多 2,048 |
| 建议 | 传统与兼容性 | 新工作负载的标准 |
推荐标准：对于新项目，使用第 2 代虚拟机、UEFI、受支持时启用 Secure Boot，以及位于虚拟 SCSI 控制器上的 VHDX 磁盘。VMM 2025 现在默认也创建第 2 代虚拟机。
安装与硬件要求
宿主机应被视为基础设施设备（appliance）：固件保持一致、启用硬件辅助虚拟化、DEP/NX、经认证的驱动、一致的 NUMA 配置，以及设置为合适性能模式的 BIOS。在集群中，各节点保持同构可以简化 Live Migration、维护和排障。
| 层 | 实用建议 |
|---|---|
| CPU | Intel VT-x/VT-d 或 AMD-V/IOMMU；SLAT；保持各节点的 CPU 系列和微码相互兼容。 |
| 内存 | ECC；规划宿主机预留；避免持续的内存压力。 |
| 宿主机启动盘 | 镜像/RAID1 或具备弹性的设备；把操作系统与虚拟机存储分开。 |
| 网络 | 生产环境至少 10/25 GbE；超融合、大量迁移或 NVMe 场景用 25/100 GbE。 |
| 存储 | 依据架构选择 NVMe/SAS/SAN/SMB3；验证延迟、排队和弹性。 |
| 安全 | TPM 2.0、Secure Boot、已签名的固件和补丁策略。 |
| 管理 | 在运维允许的情况下优先使用 Server Core；通过 WAC 和 PowerShell 远程管理。 |
组建集群前的验证
- 运行 Test-Cluster，并在上线生产之前修复相关警告。
- 统一固件、网卡/HBA 驱动、BIOS 和补丁级别。
- 依据架构的需要，验证 DNS、NTP，以及 AD DS 或工作组集群模型。
- 为管理、虚拟机、存储和 Live Migration 定义相互独立或逻辑隔离的网络。
- 在放行工作负载之前，测试故障转移、Live Migration、备份和恢复。
虚拟机、CPU、内存与 NUMA
Hyper-V 并不强制规定 vCPU 与逻辑处理器之间的固定比例。这并不意味着超配是免费的：合适的比例取决于可容忍的延迟、突发行为、观测到的等效 CPU ready 时间、虚拟机大小、NUMA 拓扑和工作负载特征。
| 项目 | Windows Server 2025——Hyper-V 最大值 |
|---|---|
| 每台第 2 代虚拟机的 vCPU | 2,048 |
| 每台第 2 代虚拟机的内存 | 240 TB |
| 每台宿主机上运行的虚拟机 | 1,024 |
| 每台宿主机的逻辑处理器 | 2,048 |
| 宿主机内存 | 5 级分页最高 4 PB；4 级分页为 256 TB |
| 每个故障转移群集的节点数 | 64 |
| 每个群集中运行的虚拟机 | 8,000 |
| VHDX | 每个虚拟磁盘最大 64 TB |
最大值不等于容量规划：规模上限是平台的天花板，而不是密度建议。项目需要考虑 SLA、N 个节点的故障、维护窗口和增长余量。
CPU 和内存的最佳实践
- 对关键工作负载从保守配置开始；只有在有饱和证据时才增加 vCPU。
- 当若干较小的虚拟机即可满足 SLA，并能提升迁移性和故障转移能力时，避免使用过大的虚拟机。
- 当工作负载对延迟敏感时，使大型虚拟机与宿主机的 NUMA 拓扑对齐。
- 为故障转移保留运维余量：满载的集群会失去韧性。
- 对于数据库和大量使用缓存的应用，应与厂商一起验证动态内存策略；在许多情况下，静态内存更有利于可预测性和排障。
存储、VHDX、CSV 与 Storage Spaces Direct
I/O 路径跨越四层：客户机的存储栈、虚拟化层、宿主机的存储栈和物理介质。瓶颈可能出现在其中任何一层；因此诊断时应当把虚拟机内部的延迟、宿主机队列、CSV/SMB 计数器、HBA/网卡以及后端存储关联起来。
| 技术 | 典型用途 | 关注点 |
|---|---|---|
| VHDX | 标准虚拟磁盘 | 最大 64 TB；防止断电期间的损坏；支持 4K 逻辑扇区。 |
| 固定 VHDX | 高可预测性 | 预先分配全部空间；交付较慢。 |
| 动态 VHDX | 灵活性和容量 | 可能需要监控其增长和碎片化。 |
| CSV | 群集共享存储 | 位于 C:\ClusterStorage 的统一命名空间；迁移性和故障转移的基础。 |
| SMB 3.x | 基于文件服务器 / SOFS 的虚拟机存储 | 依据设计使用 SMB Multichannel、SMB Direct/RDMA 和加密。 |
| Storage Spaces Direct | 使用本地磁盘的 HCI | 需要严谨的网络、介质、韧性和容量设计。 |
| SAN FC/iSCSI | 外部存储 | 多路径、zoning、队列深度、ALUA/MPIO 以及端到端延迟。 |
检查点不是备份：在兼容时，生产环境默认使用生产检查点（Production Checkpoint），但长期保留会增加差异磁盘链、占用空间和运维风险。平台对每台虚拟机的上限是 50 个检查点；好的做法是保留少量且时间短暂。
虚拟网络、SET、RDMA、SR-IOV 与 SDN
Hyper-V 网络结合了可扩展的 vSwitch、VLAN、QoS、卸载、SET（Switch Embedded Teaming）、SR-IOV、vRSS，以及在合适的架构中使用的 RDMA/SMB Direct。在 Windows Server 2025 中，Network ATC 允许描述网络意图，并在整个集群中自动实现一致的配置。
| 功能 | 推荐技术 | 示例 |
|---|---|---|
| 管理 | 专用 VLAN；物理冗余 | SET 中的 2 x 25 GbE |
| 虚拟机流量 | vSwitch + VLAN/VRF/SDN | 按租户或服务进行 QoS |
| Live Migration | 专用网络，或带 QoS 的融合网络 | 25/100 GbE；多条流 |
| SMB/S2D 存储 | 在受支持时使用 RDMA | 依据设计使用 RoCEv2/iWARP + DCB |
| 直接访问网卡 | SR-IOV | 低延迟，运维灵活性较低 |
| 宿主机网络自动化 | Network ATC | 管理 / 计算 / 存储意图 |
Live Migration 示例：一台 64 GB 内存的虚拟机在专用的 25 Gb/s 链路上，以线速传输 64 GB 的理论下限约为 20.5 秒。在有效效率为 70% 时，数学上的耗时升至约 29 秒。实际中，内存页在迁移期间仍在变化，还有压缩/SMB、协议开销和争用——实际耗时可能更长。
高可用、Live Migration 与 Hyper-V Replica
| 功能 | 目标 | 说明 |
|---|---|---|
| 故障转移群集 | 在节点故障后重启或迁移虚拟机 | 按 N+1 或更高的容量进行设计。 |
| Live Migration | 在宿主机之间迁移正在运行的虚拟机 | 可使用 TCP/IP、压缩或 SMB；取决于架构。 |
| 存储 Live Migration | 在虚拟机保持运行的同时迁移存储 | 适用于维护和再平衡。 |
| Hyper-V Replica | 在宿主机和站点之间进行异步复制 | 复制频率为 30 秒、5 分钟或 15 分钟。 |
| Azure Site Recovery | 通过 Azure 编排的 DR | Windows Admin Center 工作流中提供集成。 |
RPO 不等于 RTO：Hyper-V Replica 设定复制频率，有助于满足 RPO，但 RTO 取决于启动、依赖、DNS、网络、运行手册、应用验证以及 DR 站点的容量。
仲裁与韧性
- 依据设计和连接情况，使用云见证（Cloud Witness）、文件共享见证或磁盘见证。
- 设计集群时要能够承受计划内维护，以及至少 SLA 中定义的故障。
- 应用群集感知更新（Cluster-Aware Updating）或同等的流程，包括排空、迁移和验证。
- 测试宿主机丢失、存储路径丢失、网卡故障和见证不可用。
管理仪表盘与运维模式
| 工具 | 何时使用 | 规模 / 特点 |
|---|---|---|
| Hyper-V 管理器 | 独立宿主机、快速排障 | 简单；专注于宿主机和虚拟机。 |
| 故障转移群集管理器 | 群集和角色的运维 | HA、CSV、迁移和事件。 |
| Windows Admin Center | 现代 Web 仪表盘 | 宿主机、群集、HCI、虚拟机、性能、Arc 和 Azure 服务。 |
| PowerShell | 自动化与大规模运维 | 可脚本化，通过模式和 DSC 实现幂等。 |
| SCVMM 2025 | 企业级 fabric 与私有云 | 宿主机、群集、模板、逻辑网络与存储、云以及放置。 |
| Azure 门户 + Arc | 混合治理与自助服务 | RBAC、Policy、Defender、Monitor、Update Manager 和 Azure API。 |
对于不需要 SCVMM 完整 fabric 管理的团队，Windows Admin Center 是一个很好的运维层：清单、虚拟机的创建和配置、Live Migration、事件，以及 CPU、内存、IOPS 和吞吐量指标。SCVMM 2025 把数据中心视为一个 fabric——计算、存储和网络——支持 Windows Server 2025 和 Azure Local，强化了 TLS 1.3，并默认使用第 2 代创建新虚拟机。对于 Azure 集成，现代的方向是启用 Arc 的 SCVMM。
Microsoft Entra ID、Azure Arc 与混合集成
Microsoft Azure Active Directory 已更名为 Microsoft Entra ID。在 Hyper-V 中，需要把管理平面的身份，与群集和工作负载所使用的身份及域服务区分开。Entra ID 为现代服务提供认证和 RBAC；AD DS 对于 Kerberos、计算机账户、GPO 以及各种基础设施场景仍然重要。
| 集成 | 提供的能力 | 并不意味着 |
|---|---|---|
| WAC + Entra ID | 仪表盘的网关认证和访问控制 | 并不是“把宿主机加入 Entra ID”来全面取代 AD DS。 |
| 启用 Azure Arc 的服务器 | 清单、Policy、Update Manager、Defender/Monitor 以及混合服务 | 其本身并不管理整个虚拟化 fabric。 |
| 启用 Arc 的 SCVMM | 在 Azure 中呈现 VMM 和虚拟机，并支持生命周期和自助服务 | 需要 SCVMM 和 Arc Resource Bridge。 |
| AD DS | 域、Kerberos、GPO 和传统的服务器身份 | 其本身并不提供 Azure 中的云原生治理。 |
推荐流程
- 把 Windows Admin Center 注册到 Azure，并在适用时为网关启用 Entra ID 认证。
- 依据企业策略，把宿主机和服务器接入 Azure Arc。
- 在 SCVMM 环境中，部署 Arc Resource Bridge，并在 Azure 中启用 VMM 资源和虚拟机。
- 按 Entra ID 组应用 RBAC，把运维、安全、备份和 fabric 管理分开。
- 依据安全和合规要求，使用 Azure Policy、Defender、Monitor 和 Update Manager。
编排、自动化与基础设施即代码
Hyper-V 可以完全自动化地运维。自动化设计应当把宿主机交付、群集配置、虚拟机模板、网络、存储、生命周期、补丁、备份、可观测性和退役分开。
| 层 | 工具 | 示例 |
|---|---|---|
| 宿主机 / 群集 | PowerShell、DSC，以及受支持场景中的 Ansible | vSwitch、群集、CSV、Live Migration。 |
| 虚拟机生命周期 | Hyper-V PowerShell、VMM cmdlet | New-VM、Set-VM、模板、放置。 |
| 混合自助服务 | 启用 Arc 的 SCVMM | Azure 门户、RBAC、ARM/Bicep/Terraform/AzAPI。 |
| 运行手册（Runbook） | System Center Orchestrator 或外部自动化 | 启动/停止、维护、事件工作流。 |
| 流水线 | Git + CI/CD | 基础设施即代码、评审、dev-hml-prod 的晋级。 |
幂等性与治理
- 把参数——CPU、内存、VLAN、存储层级、备份策略——放在目录或模板中，而不是临时脚本里。
- 用 Git 对变更进行版本管理，并对生产变更实施同行评审。
- 尽可能使用 RBAC 和 Just Enough Administration。
- 记录每次变更是谁申请、批准、执行和验证的。
- 定义完整的生命周期：创建、运维、调整规格、备份、补丁和退役。
安全与加固
| 控制措施 | 在 Hyper-V 中的应用 |
|---|---|
| Secure Boot / UEFI | 第 2 代虚拟机，以及在受支持时启用安全启动的宿主机。 |
| vTPM | 在兼容的虚拟机上提供密钥保护和 BitLocker。 |
| 受防护的虚拟机 / HGS | 面向高信任场景的受保护 fabric 与证明（attestation）。 |
| Credential Guard / Defender | 按微软基线对宿主机进行加固。 |
| 宿主机防火墙 | 仅放行必要的管理和群集端口及来源。 |
| 管理员分层 | 把 fabric、域、备份和应用账户分开。 |
| 补丁 | 结合迁移/排空和回滚来编排更新。 |
| 日志 | 对 Hyper-V、群集、PowerShell 和认证事件进行转发/SIEM。 |
虚拟化宿主机属于 Tier 0：攻陷宿主机可能暴露多台虚拟机。应把宿主机、SCVMM、WAC、相关的 AD DS、备份和 fabric 凭据视为高影响资产。Host Guardian Service 是受防护 fabric 的核心——它验证受信任的宿主机，并管理启动受防护虚拟机所需的密钥——当基础设施运维人员不应无限制访问租户虚拟机的内容时，建议使用。
Hyper-V 与 Windows Server 的许可
当 Hyper-V 作为 Windows Server 角色使用时，并不作为单独的产品授权。成本和权利取决于宿主机上的 Windows Server 版本和许可，以及运行在其上的 Windows Server 虚拟机。
| 主题 | Windows Server 2025 Standard | Windows Server 2025 Datacenter |
|---|---|---|
| 适用类型 | 物理机或轻度虚拟化 | 数据中心与高度虚拟化 |
| 模式 | 按核心 | 按核心 |
| 物理最低要求 | 每颗 CPU 8 核，每台服务器 16 核 | 每颗 CPU 8 核，每台服务器 16 核 |
| 虚拟化权利（所有核心均已授权） | 2 个 Windows Server OSE/虚拟机 | 已授权的宿主机上不限数量的 Windows Server 虚拟机 |
| CAL | 通常需要 Windows Server CAL | 通常需要 Windows Server CAL |
| 微软参考建议零售价（MSRP） | 1,176 美元 | 6,771 美元 |
如何计算 Standard
一台有 2 颗处理器、每颗 8 核的宿主机，共有 16 个物理核心。用 Standard 对这 16 个核心授权，可获得 2 个 Windows Server OSE 的权利。要在同一台宿主机上运行 4 个 OSE，需要对全部核心再授权一次；6 个 OSE 则需要三套，依此类推。按公开的参考价格，为 12 台虚拟机购买六套 Standard 合计 7,056 美元——高于 Datacenter 的 MSRP 6,771 美元。折扣、核心包（core pack）、软件保障、CSP、CAL 和合同条款可能彻底改变决策。Linux 不消耗 Windows Server OSE 的权利，但 Hyper-V 宿主机仍需获得正确的授权。
其他模式
| 模式 | 概要 |
|---|---|
| 按虚拟机授权 | 可通过订阅或有效的软件保障获得；每台虚拟机按 vCore 授权，每台虚拟机至少 8 个核心许可。适用于拥有少量 Windows Server 虚拟机的大型宿主机。 |
| 通过 Azure Arc 的按需付费 | Standard 和 Datacenter 通过 Azure 订阅计费，可以开启和关闭，两个版本费率相同，基本功能无需 CAL。它按设备/虚拟机计算——宿主机许可不会自动授予虚拟机的权利。 |
| Hyper-V Server 2019 | 仍然出现在遗留环境中，但扩展支持将于 2029 年 1 月 9 日结束。不应作为新的长期项目的基础。 |
说明：MSRP 数值仅用于规划和估算；最终应与负责合同的经销商或许可专家核实。
许可与 System Center VMM 的角色
SCVMM 是 System Center 2025 的一部分；其服务器组件不作为单独的“仅 VMM”产品出售。System Center 管理许可基于被管理的终端和服务器以及物理核心，Standard 和 Datacenter 版本以管理 OSE 的权利加以区分。
| System Center 2025 | Standard | Datacenter |
|---|---|---|
| 每台完整授权服务器的权利 | 最多管理 2 个 OSE | 管理不限数量的 OSE |
| 最低要求 | 每颗 CPU 8 核 / 每台服务器 16 核 | 每颗 CPU 8 核 / 每台服务器 16 核 |
| 包含 VMM | 是 | 是 |
| 包含 Operations Manager、DPM、Orchestrator 等 | 是 | 是 |
| 微软参考建议零售价（MSRP） | 1,455 美元 | 3,968 美元 |
VMM 何时能增加价值
- 数十乃至数百台宿主机和虚拟机，需要模板和放置。
- 带有配额、逻辑云以及网络/存储标准化的私有云。
- 在过渡期间集成运维 Hyper-V 和部分 VMware 环境。
- 需要启用 Arc 的 SCVMM、Azure 自助服务，以及通过 ARM/Bicep/Terraform/API 实现的自动化。
- 在 System Center 策略内，与 Operations Manager、DPM 和 Orchestrator 集成。
性能、容量规划与数值示例
性能工程应从 SLA 和工作负载特征出发，而不是从虚拟化管理程序的最大值出发。CPU、内存、存储和网络需要分别建模；最终密度由最先饱和的资源，以及为故障和维护所需的余量决定。
64 核 / 1 TB 宿主机示例
| 假设 | 数值 |
|---|---|
| 物理核心 | 64 |
| 已安装内存 | 1,024 GB |
| 为宿主机和开销预留的内存 | 10% |
| 工程上可用内存 | 约 922 GB |
| 标准虚拟机 | 4 vCPU / 8 GB |
| CPU 超配 2:1 | 按 CPU 上限为 32 台虚拟机；内存可容纳约 115 台 |
| CPU 超配 4:1 | 按 CPU 上限为 64 台虚拟机；内存可容纳约 115 台 |
| CPU 超配 6:1 | 按 CPU 上限为 96 台虚拟机；内存可容纳约 115 台 |
在这个例子中，按 4:1，CPU 上限为 64 台虚拟机，且内存仍有余量；按 6:1，模型在触及内存天花板之前可容纳 96 台虚拟机。这并不意味着推荐 6:1：轻量 VDI、应用服务器、数据库和低延迟工作负载的表现截然不同。
应当度量的指标
| 领域 | 指标 |
|---|---|
| CPU | 利用率、频率、% 客户机/运行时、排队、应用延迟、NUMA。 |
| 内存 | 可用 MB、压力、分页、工作集、动态内存事件。 |
| 存储 | IOPS、MB/s、读写延迟、队列长度、CSV/SMB 计数器。 |
| 网络 | Gb/s、丢包、重传、RDMA 计数器、vSwitch/VMQ/vRSS。 |
| 虚拟机 | 启动时间、响应时间、事务速率、应用专属的 KPI。 |
| 群集 | 故障转移时间、Live Migration 时间、CSV 重定向 I/O、节点健康状况。 |
正确的基准测试：存储使用 DiskSpd，网络在适当时使用 ntttcp 等工具，而最重要的是使用应用自带的基准测试。目标是度量所交付的服务，而不是追求一个合成的数字。
GPU、AI 与加速工作负载
Windows Server 2025 扩展了 Hyper-V 中的 GPU 场景。可以使用离散设备分配（DDA），把一个 PCIe 设备专用于虚拟机，也可以使用 GPU 分区（GPU-P），在兼容设备上通过 SR-IOV 把一块物理 GPU 划分为硬件隔离的分区。
| 模式 | 优势 | 限制 / 用途 |
|---|---|---|
| DDA | 专用、可预测的访问 | GPU 被分配给虚拟机；需验证迁移性、群集支持和 OEM 支持。 |
| GPU-P | 在多台虚拟机之间共享 GPU | 需要整个群集配置同构，并且 GPU 受支持。 |
| GPU-P + Live Migration | WS2025 上带加速的迁移性 | 迁移可能使用带压缩的 TCP/IP，并消耗更多 CPU 和时间。 |
在 AI 中的使用：依据驱动和厂商的支持，用于模型推理和 CUDA/DirectML 工作负载，以及使用专用或分区 GPU 的 VDI、渲染和工程应用。对于高性能分布式训练，还必须评估 GPU 之间的互连和具体的生态——Hyper-V 可能并不是唯一的架构决策。
备份、DR 与业务连续性
策略应当结合一致的虚拟机和应用备份、不可变或离线副本、恢复测试以及 DR。Hyper-V Replica 可以作为复制层的一部分，但它不能取代带有保留期、并能防范删除和勒索软件的备份。
| 层 | 目标 | 示例 |
|---|---|---|
| 本地备份 | 快速恢复 | Veeam、DPM、经 VSS/RCT 认证的解决方案。 |
| 二级副本 | 防范站点故障 | 另一个数据中心或对象存储。 |
| 不可变性 | 勒索软件 | 依据方案使用 Object Lock/WORM/物理隔离（air-gap）。 |
| 副本 | 站点之间的短 RPO | Hyper-V Replica 30 秒 / 5 分钟 / 15 分钟。 |
| DR 编排 | 协调一致的故障转移 | Azure Site Recovery 或经过测试的运行手册。 |
最小测试矩阵
- 文件恢复和完整的虚拟机恢复。
- 数据库和目录服务的应用感知恢复。
- 关键虚拟机的故障转移与回切（failback）。
- 宿主机完全丢失和存储路径丢失。
- 站点 DR：网络、DNS、身份、防火墙、证书和依赖项。
- 在隔离环境中恢复，以验证完整性和安全性。
VMware 迁移与共存
System Center VMM 2025 在特定场景下支持管理兼容的 VMware 宿主机，并在 ESXi 到 Hyper-V 的转换上带来了性能改进。迁移应当被视为一项现代化项目，而不仅仅是磁盘转换。
| 步骤 | 交付物 |
|---|---|
| 发现 | 虚拟机、操作系统、CPU/内存、存储、VLAN、依赖和许可的清单。 |
| 分类 | 重新托管（Rehost）、重新平台化（Replatform）、退役（Retire）、保留（Retain）、重构（Refactor）。 |
| Hyper-V 落地区 | 群集、网络、存储、模板、备份和可观测性。 |
| 试点转换 | 非关键虚拟机以及性能/驱动测试。 |
| 分批 | 按应用和依赖分批，带回滚。 |
| 优化 | 合理配置规格、第 2 代、Secure Boot、新层级和自动化。 |
导致迁移失败的因素
- 官方支持仅限于 VMware 的设备。
- 对快照/检查点或特定驱动的依赖。
- 与硬件、UUID 或虚拟化管理程序绑定的软件许可。
- 使用 dvSwitch/NSX 的网络，其策略无法映射到 Hyper-V 上的 VLAN/SDN。
- 仍依赖 vCenter API 的备份、监控和自动化。
- 没有足够窗口、带宽或目标存储的超大型虚拟机。
技术对比与采用标准
| 标准 | Hyper-V / WS2025 | VMware vSphere | Proxmox VE |
|---|---|---|---|
| Windows/AD 集成 | 非常强 | 强 | 良好，更偏手工 / 第三方 |
| 企业管理 | SCVMM / WAC / Arc | vCenter / Aria / 生态 | GUI + API + 生态 |
| 许可 | Windows Server 按核心；VMM/System Center 可选 | 须询价当前的 Broadcom 模式 | 开源 + 支持订阅 |
| HCI | S2D / Azure Local | vSAN | 集成的 Ceph |
| Azure 混合 | Arc / ASR / Entra / WAC | 提供集成 | 可使用客户机 Arc；不是原生 fabric |
| GPU | WS2025 DDA / GPU-P | 视技术栈而定的 vGPU / 直通 | 视技术栈而定的 PCIe 直通 / vGPU |
不存在放之四海而皆准的赢家：选择应综合权衡对工作负载的支持、团队技能、备份和 DR 生态、自动化、许可、认证硬件以及过渡成本。对于以微软为主的环境，Hyper-V 凭借集成和 Windows Server Datacenter 的权利而更具优势。
部署路线图与生产检查清单
| 阶段 | 范围 |
|---|---|
| 0 — 评估 | 清单、SLA、依赖、许可、安全和容量。 |
| 1 — 设计 | 计算、存储、网络、身份、管理、备份、DR 和可观测性。 |
| 2 — 构建 | 固件、Windows Server 2025、Hyper-V、群集、网络和存储。 |
| 3 — 管理 | WAC、SCVMM、Arc、RBAC、ITSM 和自动化。 |
| 4 — 验证 | 基准测试、故障转移、恢复、补丁、DR 和安全测试。 |
| 5 — 试点 | 受控的工作负载和性能基线。 |
| 6 — 迁移批次 | 带运行手册和回滚的分批迁移。 |
| 7 — 运维 | SLO、容量、补丁、生命周期、成本和持续改进。 |
技术验收标准
| 领域 | 最低验收标准 |
|---|---|
| HA | 已测试宿主机故障转移，且不丢失虚拟机的完整性。 |
| Live Migration | 在具有代表性的负载下，迁移在预期窗口和 SLO 之内完成。 |
| 存储 | 延迟和吞吐量满足工作负载基线。 |
| 网络 | 没有异常的丢包或重传；冗余已验证。 |
| 备份 | 已证明虚拟机和应用可以恢复。 |
| DR | 已连同依赖项测试 RPO 和 RTO。 |
| 安全 | 基线、RBAC、管理平面的 MFA 以及集中日志。 |
| 运维 | 已定义运行手册、告警、仪表盘、容量和升级机制。 |
最大的运维收益来自不再把 Hyper-V 仅仅当作“一个虚拟化管理程序”，而是把它作为一个平台来部署：模板、RBAC、自动化、可观测性、经过测试的备份和 DR、容量管理以及变更治理。
快速术语表
| 术语 | 定义 |
|---|---|
| AD DS | Active Directory 域服务；域、Kerberos、LDAP 和 GPO。 |
| Entra ID | 微软的云身份服务，前身为 Azure AD。 |
| Arc | Azure 针对 Azure 之外资源的混合与多云控制平面。 |
| CSV | 群集共享卷（Cluster Shared Volumes）。 |
| DDA | 离散设备分配（Discrete Device Assignment）——向虚拟机的 PCIe 直通。 |
| GPU-P | GPU 分区（GPU Partitioning）——在虚拟机之间划分 GPU。 |
| HGS | 用于受防护 fabric 和受防护虚拟机的 Host Guardian Service。 |
| OSE | 操作系统环境（Operating System Environment）；许可中使用的概念。 |
| S2D | Storage Spaces Direct。 |
| SCVMM / VMM | System Center Virtual Machine Manager。 |
| SET | Switch Embedded Teaming。 |
| VHDX | Hyper-V 的现代虚拟磁盘格式。 |
| VMBus | Hyper-V 分区之间经过优化的通信通道。 |
使用的来源与说明
本资料依据微软的公开文档编写，查阅于 2026 年 9 月 2 日。规模上限、参考价格、生命周期日期和功能可能发生变化——在设计真实环境之前，务必向官方来源确认。
主要参考资料
- Windows Server 中 Hyper-V 的最大规模限制：learn.microsoft.com/windows-server/virtualization/hyper-v/maximum-scale-limits
- Windows Server 2025 定价与许可：microsoft.com/windows-server/pricing
- Windows Server 许可文档：microsoft.com/licensing/docs/view/Windows-Server
- 通过 Azure Arc 的 Windows Server 按需付费：learn.microsoft.com/windows-server/get-started/windows-server-pay-as-you-go
- 使用 Windows Admin Center 管理 Hyper-V 虚拟机：learn.microsoft.com/windows-server/manage/windows-admin-center/use/manage-virtual-machines
- Windows Admin Center 的 Azure 集成：learn.microsoft.com/windows-server/manage/windows-admin-center/azure/azure-integration
- System Center VMM 2025 概览：learn.microsoft.com/system-center/vmm/overview
- VMM 2025 的新增功能：learn.microsoft.com/system-center/vmm/whats-new-in-vmm
- System Center 2025 定价与许可：microsoft.com/system-center/system-center-2025
- 启用 Azure Arc 的 System Center VMM：learn.microsoft.com/azure/azure-arc/system-center-virtual-machine-manager
- Hyper-V Replica：learn.microsoft.com/windows-server/virtualization/hyper-v/replication-virtual-machines
- Hyper-V 处理器性能：learn.microsoft.com/windows-server/administration/performance-tuning/role/hyper-v-server/processor-performance
- Hyper-V 存储 I/O 性能：learn.microsoft.com/windows-server/administration/performance-tuning/role/hyper-v-server/storage-io-performance
- Hyper-V 中的 GPU 分区：learn.microsoft.com/windows-server/virtualization/hyper-v/gpu-partitioning
- Hyper-V Server 2019 生命周期：learn.microsoft.com/lifecycle/products/hyperv-server-2019
- Windows Server 2025 的新增功能：learn.microsoft.com/windows-server/get-started/whats-new-windows-server-2025
- Host Guardian Service：learn.microsoft.com/windows-server/security/guarded-fabric-shielded-vm/guarded-fabric-manage-hgs
编者注
数值化的容量示例、对比和最佳实践建议是出于教育目的整理的。它们不构成报价、实验室基准测试或许可咨询——最终的容量规划和经济性取决于实际的硬件、SLA 以及每个项目的商务合同。
NGG Tech：云 • 数据中心 • 裸金属 • 存储 • 支持 • 安全