未经许可，请勿转载！
本篇 TL;DR：Azure Local VM 是运行在 Azure Local 上、通过 Azure Arc Resource Bridge 以 ARM Resource 形式呈现的虚拟机。关键区分（v1.3.4 新增）：Azure Local VM 的 Hyper-V VM 运行本身 依赖 Azure Local 平台层（Hyper-V + Failover Cluster + S2D + SDN）——Azure 连接断开时本地仍可工作；其 Azure 化管理体验（Azure Portal 创建 / ARM 资源建模 / Azure RBAC 控制）依赖 Arc Resource Bridge + Custom Location；VM 管理链路依赖 Azure Local VM management stack（包括 MOC、Resource Providers 和 mocguestagent）。Guest Management 所部署的 Azure Connected Machine Agent 是可选扩展能力，用于 Azure Arc 对 Guest OS 的扩展管理。本篇解决两个问题：Azure Local VM 究竟是什么 / 不是什么 / 三层体系边界怎么分，创建前要在 Azure 侧 / 本地侧 / 镜像侧 / 网络侧 / 工具侧准备什么。
文档基线：参考 Azure Local 2506（2025 年 6 月）/ 2510（2025 年 10 月） 文档体系（内部整理版本 v1.3.x）；细节以当期官方文档为准。
本篇全局视图
本篇 §1 确立"是什么 / 不是什么"以及 Azure Arc 基础设施 / Azure Local VM Management Stack / 部署前置基础设施 三层边界（v1.3.3 重写）——这是企业评估阶段最易误解的点；§2 按五维准备清单 + 四前置资源（Storage Path → VM Image → Logical Network → NIC）搭起执行清单，为篇 2 动手创建 VM 做准备。
§1 概念边界与 Azure Arc 的作用范围
目标读者：刚接触 Azure Local 的架构师、评估团队、技术决策者。
核心问题：Azure Local VM 究竟是什么？是不是必须启用 Azure Arc 才能用？两个 Agent 怎么区分？
§1.0 总体架构图
本节是整篇文章最应该出现的一张图——先看这一张图，再看后续 §1.1~§1.7 详细组件说明，能让 Azure Local VM 的运行机制一次看清。
关键识别（v1.3.3 重写）：
- 红色框（Arc Resource Bridge）：Azure Local VM 作为 ARM Resource 存在的必需基础设施——Arc-enabled K8s + VM 管理扩展（提供 K8s 扩展运行环境，由扩展调用 Mgmt Stack 完成 VM 生命周期）；不包含 MOC 与 Resource Providers（这些属于黄色框 Azure Local VM Management Stack）
- 蓝色框（Custom Location）：ARM 把请求路由到本地的目标
- 黄色框（Azure Local 平台栈）：VM 运行所在的底层平台
- 淡蓝框（Guest Agent 层）：VM 与 Azure / Azure Arc 通信的代理——其中 mocguestagent 必须，Connected Machine Agent 可选
架构视角：自上而下，依次是"Azure 控制平面 → Arc 基础设施 → 本地管理集群 → Azure Local 平台栈 → Hyper-V → VM → Guest Agent"。8 层关系一旦读懂，§1.1~§1.7 详细组件说明都只是这张图各层的展开。
§1.1 一句话定义
按 微软官方文档（What is Azure Local VM management） 口径：
Azure Local VM management enables IT admins to provision and manage Windows and Linux VMs hosted in an on-premises Azure Local environment.
Azure Local VM 是运行在 Azure Local 上的、通过 Azure Arc 资源桥（Arc resource bridge）以 Azure 资源形式呈现的虚拟机。
术语首次出现（v1.3.4 新增）：本文 "Azure Arc 管理基础设施"（简称 Arc Infrastructure） 指 Azure Local VM 场景下的 Azure Arc 组件，包括 Arc Resource Bridge、Custom Location 与 Connected Machine Agent（Guest 侧）。该简称不替代微软官方层级名称——微软体系内 Azure Arc 是一个大概念，下辖 Arc-enabled Servers / Arc-enabled Kubernetes / Arc Resource Bridge / Arc-enabled Data Services 等多类资源；本文聚焦 Arc Resource Bridge 与 Azure Local VM 的集成。它由 Azure Local 平台承载（底层仍是 Hyper-V + Failover Cluster + Azure Stack HCI OS），由 Azure Arc 提供 Azure 一致性的管理体验。
§1.2 Azure Local VM 不是什么
这是企业评估阶段最常见的误解来源——明确以下"不是什么"是划清边界的捷径：
|
误读 |
准确表述 |
|
Azure Local VM = 公有云 Azure VM |
不是。Azure Local VM 始终运行在客户数据中心；它获得的是 Azure 的管理一致性，不是 Azure 的物理资源。它在 Azure 侧表现为 ARM Resource，类型为 Microsoft.AzureStackHCI/virtualMachineInstances，而不是 Azure 中"运行在 Azure 数据中心的 Azure VM"那种 ARM Resource 类型。 |
|
创建 Azure Local VM 完全不依赖 Azure Arc |
不是这一简化表述。从 Azure 端创建 / 删除 / 启停 / 状态查询 Azure Local VM 依赖 Arc Resource Bridge + Custom Location + Azure Local VM Management Stack（MOC + RP + mocguestagent）——前两个属 Azure Arc 基础设施，后三个属 Azure Local VM Management Stack。详见 §1.5。 |
|
Azure Local VM = Edge Region |
不是。Edge Region 专指公有云的 Azure Edge Zone，与 Azure Local 是不同抽象层级的事物。 |
|
第一类 Azure 资源 / 一级资源 / First-class Resource |
不是。微软官方未使用 "First-class Resource" 这一术语描述 Azure Local VM。微软对 Azure Local VM 的官方表述接近"纳入 Azure 资源管理体系，与 Azure 其他资源保持一致的管理体验"——这是体验描述，不是 first-class 断言。 |
|
Hybrid Machine 类型 |
不是当前主流表述。微软当前主流表述倾向 Arc-enabled machine / Arc-enabled server，"Hybrid Machine" 在较新文档中较少使用。 |
§1.3 Azure Local VM 管理的关键组件
按 官方 overview 文档 表述，Azure Local VM 管理由多个组件协同支撑。理解整个 Azure Local 平台栈是理解 VM 管理组件的前提。
§1.3.0 Azure Local 平台栈（VM 管理的运行环境）
Azure Local 平台的组成远超"HCN + Hyper-V"。下表是完整平台栈——不仅仅是 VM 管理组件，还包括 Azure Local 实例本身的所有支撑组件：
|
层 |
组件 |
角色 |
|
操作系统层 |
Azure Stack HCI OS |
每节点的宿主操作系统 |
|
虚拟化层 |
Hyper-V |
第一类虚拟机监控器，承载 Guest VM |
|
集群层 |
Failover Cluster |
故障转移与高可用 |
|
存储层 |
Storage Spaces Direct（S2D）+ ReFS + BitLocker |
分布式存储 |
|
网络层 |
SDN（Software Defined Networking） |
包括 Network Controller、Load Balancer、Gateway 等（取决于部署模式） |
|
Azure Local 平台层 |
Azure Stack HCI OS / Hyper-V / Failover Cluster / S2D / SDN |
本地基础设施运行环境 |
|
Azure Arc 集成层 |
Arc Resource Bridge / Custom Location / Arc extensions |
Azure 控制平面连接和资源映射 |
|
Azure Local VM Management Stack |
MOC / Resource Providers / mocguestagent |
VM 生命周期管理 |
|
多服务管理层 |
MOC（Microsoft On-premises Cloud） |
Azure Local 内部的多服务管理层 |
|
资源提供程序层 |
Resource Providers（Compute RP / Storage RP / Network RP / Gallery RP / Upgrade RP 等） |
Azure Local 平台内的资源提供程序，VM 通过 Compute RP 暴露 |
|
客户机代理层 |
Cloud Agent（mocguestagent）/ Guest Agent |
Guest OS 内运行，与平台通信 |
|
运维管理层 |
Azure Local Management Services / Azure Config Agent |
平台自身的更新、合规、遥测 |
重要：Azure Local 平台栈远远不止"Hyper-V + FC + HCI OS"。Azure Local VM 的 Azure Resource 生命周期由 Azure Arc Resource Bridge 提供入口，通过 Azure Local VM management stack（MOC、Resource Providers 等）完成本地资源编排。ARM 资源映射链路为 ARM → Azure Resource Provider → Arc Resource Bridge → MOC → Compute RP → Hyper-V——不是 ARM 直接依赖 Compute RP。
§1.3.1 Azure Local VM 管理关键组件
按 ACP 第七轮反馈的"组件归属边界"重新组织。Azure Local VM 管理由 Azure Arc 基础设施 + Azure Local VM Management Stack 共同支撑：
|
组件 |
所属体系 |
角色 |
部署时机 |
适用版本 |
|
Azure Arc resource bridge |
Azure Arc 基础设施 |
预打包虚拟设备（本地 VM），承载 Arc-enabled K8s 集群 + K8s extensions + VM 管理扩展（不包含 MOC 与 Resource Providers——这些属于 Azure Local VM Management Stack） |
Azure Local 2405/250x 以后部署流程中通常自动创建；早期版本（2311 之前）需独立部署 |
详见当前 OEM Support Matrix 与官方文档 |
|
Custom Location |
Azure Arc extension |
Azure Local 实例的 Azure 端表达；ARM 创建请求通过它路由到 Arc Resource Bridge |
Azure Local 部署时自动创建；或在 Arc Resource Bridge 部署时自动关联 |
各版本 |
|
Kubernetes cluster extension |
Azure Arc 基础设施（运行在 Arc Resource Bridge 内） |
多个 K8s 扩展实现 VM 生命周期核心业务逻辑（电源操作 / 磁盘网卡挂载 / GPU 分配） |
Azure Local 部署时自动安装 |
各版本 |
|
MOC + Resource Providers |
Azure Local VM Management Stack |
本地云服务层 + Resource Provider（Compute / Storage / Network 等）；是 Azure Local 平台的一部分，不属于 Azure Arc |
Azure Local 部署时自动安装 |
各版本 |
|
mocguestagent |
Azure Local VM Management Stack 的 Guest Agent |
平台 ↔ Guest 通信；VM 配置 / 状态 / provisioning 信号（不负责 Azure 端 Resource 生命周期） |
由 Azure Local VM 创建流程注入 |
取决于 Guest OS 支持矩阵 |
|
Infrastructure logical network |
Azure Local 平台部署前置基础设施 |
Azure Local 基础设施组件（Arc Resource Bridge / MOC / RP / K8s extension）使用的内部管理网络——不承载 VM 业务流量（VM 业务流量走 Logical Network §2.7.3） |
Azure Local 部署时自动创建 |
各版本 |
关键边界：
- Azure Arc 体系：Arc Resource Bridge + Custom Location + Kubernetes cluster extension
- Azure Local VM Management Stack：MOC + Resource Providers + mocguestagent
- 部署前置基础设施：Infrastructure logical network（独立于 VM lifecycle 之外，是平台部署时的前置基础设施）
- 三者完全分离——这是微软 Learn 内部架构文档的边界划分
§1.4 Azure Local VM 总体架构图
这是理解 Azure Local VM 工作原理的总览图——从用户操作入口到 Guest OS 自下而上分八层。强烈建议先看这一张图，再看后续组件介绍。
Azure Local VM 管理的核心链路：
Azure ARM 控制平面
↓ Custom Location 路由
Arc Resource Bridge（Arc Infrastructure：Arc-enabled K8s + VM management extensions）
↓ Kubernetes Extension invokes VM Management APIs（关键调用关系）
Azure Local VM Management Stack（MOC + Resource Providers）
↓ RP 调用
Azure Local 平台层（Hyper-V + Failover Cluster + S2D + SDN + Azure Stack HCI OS）
↓ VM 启动
Azure Local VM（Guest OS）
↓ Guest 通信
mocguestagent（Mgmt Stack 的 Guest Agent）→ MOC / 平台
Connected Machine Agent（Azure Arc Guest 侧，可选）→ Azure Arc 扩展执行
链路各层职责：
|
层 |
所属体系 |
核心职责 |
|
① Azure ARM |
Azure 控制平面 |
资源建模 / RBAC / 计费 / 配额；Azure Local VM 是 ARM Resource（Microsoft.AzureStackHCI/virtualMachineInstances） |
|
② Custom Location |
Azure Arc extension |
ARM 把请求路由到本地的目标——指向 Arc Resource Bridge |
|
③ Arc Resource Bridge |
Azure Arc 基础设施 |
Arc-enabled K8s + VM management extensions；提供 Kubernetes 扩展运行环境，由这些扩展调用 Azure Local VM management stack 完成 VM 生命周期操作；不包含 MOC 与 Resource Providers（这些属于 Mgmt Stack） |
|
④ Azure Local VM Management Stack |
Azure Local 平台 |
MOC + Resource Providers（Compute / Storage / Network）；mocguestagent 属于本栈的 Guest Agent |
|
⑤ Azure Local 平台层 |
Azure Local 平台 |
Hyper-V + Failover Cluster + S2D + SDN + Azure Stack HCI OS |
|
⑥ Azure Local VM |
Guest |
Guest OS 内核；由 ⑤ 层承载 |
|
⑦ Guest Agent 层 |
Guest 内部 |
mocguestagent（Mgmt Stack Guest Agent，不直连 Arc Resource Bridge）+ Connected Machine Agent（Azure Arc Guest 侧，可选） |
§1.5 必备小节——精确理解 Azure Arc / Azure Local VM Management Stack / 部署前置基础设施 三层边界
单独列出，是因为企业实施过程中最容易被误解。"Azure Local VM 不依赖 Azure Arc 也能跑"是一种不准确的简化——准确的关系需要把 "Azure Arc" 拆解成至少三个独立组件理解。
§1.5.1 一个常见误区
v1.3.1 本文曾表述为"Azure Local VM 创建依赖 Arc Resource Bridge + Custom Location + mocguestagent 这一整套 Azure Arc 基础设施"。意图对，但存在以下三个层次的偏差（按 ACP 第七轮反馈重写）：
正确归位（v1.3.3）：Azure Local VM 作为 ARM Resource 创建依赖 Arc Resource Bridge + Custom Location + Azure Local VM Management Stack（MOC + RP + mocguestagent）——前两个属于 Azure Arc 基础设施，后三个属于 Azure Local VM Management Stack。
§1.5.2 Arc / Mgmt Stack / 前置基础设施 三层边界拆分
为消除歧义，把"Azure Arc"按 Azure Local VM 场景拆分为三层独立组件，并标明各自对 VM 创建 / 运行 / Azure 可见性的依赖关系：
|
Arc 组件 |
是否为 Azure Local VM 的必要组件 |
控制平面归属 |
角色 |
|
Azure Arc Resource Bridge（含其内置的 Arc-enabled K8s 集群 + Kubernetes cluster extension） |
✅ 是——提供 Kubernetes 扩展运行环境，由这些扩展调用 Azure Local VM management stack 完成 VM 生命周期操作基础设施 |
Azure Arc 控制平面（本地部署） |
Custom Location 把 ARM 创建请求路由到 Arc Resource Bridge，由其内置的 K8s 集群 + Kubernetes cluster extension 实现 VM 创建 / 删除 / 启停等核心生命周期 |
|
mocguestagent（Azure Local VM Management Stack 的 Guest Agent） |
✅ 是（仅限支持 Azure Local VM Guest Agent 的 Guest OS 场景）——由 Azure Local VM 创建流程注入；具体支持范围取决于 Trusted Launch / Generation / OS 支持矩阵 |
Azure Local VM Management Stack（非 Azure Arc） |
平台 ↔ Guest 通信；提供 VM 配置、状态、心跳信号给 MOC / 平台侧（不负责 Azure 端 Resource 生命周期） |
|
Azure Connected Machine Agent（Guest Management） |
❌ 否——创建完成后可选启用的扩展能力 |
Azure Arc 控制平面（Guest 侧） |
在 Guest OS 内执行 Azure Policy、Update Manager、Defender for Cloud 等 Azure 托管扩展 |
|
Custom Location |
✅ 是——ARM 路由目标 |
Azure Arc 控制平面 |
把针对 Azure Local 实例的 ARM 请求路由到 Arc Resource Bridge |
|
az stack-hci-vm CLI 扩展 |
是工具，非依赖 |
Azure 控制平面 |
创建 / 查询 VM 的客户端工具链 |
§1.5.3 三类问题对各层组件的依赖
ACP 第七轮反馈指出：v1.3.1 的 "创建 VM 依赖 Arc Resource Bridge + Custom Location + mocguestagent" 把 mocguestagent 误归到 Azure Arc 体系——mocguestagent 不负责 Azure 端 Resource 生命周期。下表按"能力 vs 依赖"维度重写。
|
能力 |
Arc Resource Bridge |
Custom Location |
MOC + RP（Mgmt Stack） |
mocguestagent |
Connected Machine Agent |
|
Hyper-V 跑 Guest OS |
❌ |
❌ |
❌ |
❌ |
❌ |
|
本地 VM 在本地正常工作 |
❌ |
❌ |
✅ 提供存储/网络/计算 |
❌ |
❌ |
|
从 Azure 门户 / ARM 创建 VM |
✅ 路由 ARM 请求 |
✅ 路由目标 |
✅ 通过 RP 落地 |
❌ |
❌ |
|
Azure Resource 生命周期 |
✅路由 |
✅ 路由目标 |
✅ 执行实际操作 |
||
|
Azure 端 VM Resource 存在 |
✅ 必备 |
✅ 必备 |
✅ 通过 RP 注册 |
||
|
Azure 端 VM 生命周期（create/delete/start/stop/status） |
✅ 路由 |
✅ 路由目标 |
✅ 通过 RP 执行 |
❌（不负责 Resource 生命周期，是 VM 创建后注入的 Guest 组件） |
❌ |
|
平台 ↔ Guest 通信（heartbeat / provisioning / instance info） |
❌ |
❌ |
✅ 通过 MOC 收集 |
✅ 必须 |
❌ |
|
Guest 内 Azure 扩展（Policy / Update Manager / Defender） |
❌ |
❌ |
❌ |
❌ |
✅ 必须 |
|
Azure RBAC 控制 VM 操作 |
✅ 必须（控制的是 ARM Resource） |
不依赖 |
不依赖 |
||
|
Azure Policy Guest Configuration |
不依赖 |
不依赖 |
✅ 必须 |
||
|
Azure Update Manager 打补丁 |
不依赖 |
不依赖 |
✅ 必须 |
||
|
Defender for Cloud 扫描 |
不依赖 |
不依赖 |
✅ 必须 |
§1.5.4 关键结论（v1.3.3 重写——按"能力 vs 依赖"维度）
按"能力 vs 依赖"维度重新拆分（v1.3.4 进一步区分 "Hyper-V VM 运行依赖" 与 "Azure 化管理体验依赖" 两个范畴）：
|
能力 |
依赖 |
|
== Hyper-V VM 运行范畴 == |
|
|
Hyper-V 跑 Guest OS（本地计算） |
Azure Local 平台（Hyper-V + Failover Cluster + S2D + SDN + Azure Stack HCI OS） |
|
本地 VM 在本地正常工作 |
不需要 Azure 连接；Azure 连接断开时本地仍可工作 |
|
VM 文件存在 |
S2D / ReFS / Cluster Shared Volume |
|
本地管理 VM |
Hyper-V Manager / WAC / Failover Cluster Manager / PowerShell |
|
== Azure 化管理体验范畴 == |
|
|
Azure Portal / ARM 创建 VM |
Arc Resource Bridge + Custom Location + Azure Local VM Management Stack（MOC + RP） |
|
Azure 端 VM Resource 存在 |
Arc Resource Bridge + Custom Location |
|
Azure 端 VM 生命周期（create/delete/start/stop/status） |
Arc Resource Bridge + Custom Location + Azure Local VM Management Stack（MOC + RP），不依赖 mocguestagent（Guest Agent 是 VM 创建后注入的 Guest 组件） |
|
Azure RBAC 控制 VM 操作 |
Arc Resource Bridge（控制的是 ARM Resource，不是 Hyper-V VM） |
|
== 平台 ↔ Guest 通信范畴 == |
|
|
平台 ↔ Guest 通信（heartbeat / provisioning / instance info） |
对于支持 Azure Local VM Guest Agent 的 Guest OS 场景，mocguestagent 是 Azure Local VM 管理链路的重要组件（不负责 Azure 端 Resource 生命周期）；具体支持范围取决于 Trusted Launch / Generation / OS 支持矩阵 |
|
== Azure Arc Guest Management 范畴 == |
|
|
Guest Management（VM Extensions / Azure Policy / Defender 等） |
Connected Machine Agent |
一句话（v1.3.3 精确版）："Azure Local VM 的计算运行依赖 Azure Local 平台；Azure 管理体验（创建 / 生命周期 / 资源映射）依赖 Arc Resource Bridge + Custom Location；平台 ↔ Guest 通信依赖 mocguestagent；Guest 内的 Arc 扩展能力依赖 Connected Machine Agent。"
关键边界（v1.3.3 显式标注）：
Guest Management 启用条件（不变）：按 官方文档 表述，启用需 Azure Local 2311.2 或更高版本。
禁用 Guest Management 不影响本地运维——客户仍可通过 WAC、Hyper-V Manager、Failover Cluster Manager 或 PowerShell 继续管理 VM；仅失去 Azure 侧扩展能力。
深入细致看：Azure Local VM 本质是运行在 Azure Local 平台上的、本地 Guest OS 工作负载，通过 Azure ARM 暴露资源视图——其 ARM Resource 生命周期由 Arc Resource Bridge + Custom Location + Azure Local Management Stack 联合管理，Guest OS 工作负载由 Hyper-V + Failover Cluster 管理，这两层可以解耦（Azure 连接受影响时本地仍能跑，平台故障时 Azure 可见但 Guest 不可达）。
§1.6 两个 Agent 的严格区分
这是另一个企业实施过程中容易混淆的点。
§1.6.1 一表区分
Connected Machine Agent 三层组件（v1.3.4 提前说明）：Azure Connected Machine Agent 不是单一进程，而是 Connected Machine Agent 主进程 + Extension Handler + Azure Arc Extension Service 三层协作：
- Connected Machine Agent（主进程）：负责与 Azure Arc 控制平面通信（心跳 / 状态上报）
- Extension Handler：负责处理从 Azure 推送的 VM Extension 命令（如 Custom Script Extension / Azure Monitor Agent 等）
- Azure Arc Extension Service：负责加载、生命周期管理 Extension；与 Azure Arc 控制平面交换 Extension 状态
三个组件共同实现"在 Guest OS 内执行 Azure 扩展能力"——任意一层缺失都会导致 Guest Management 异常。
|
维度 |
Guest Agent（mocguestagent） |
Azure Connected Machine Agent（含 Extension Handler + Arc Extension Service） |
|
别称 |
Azure Local VM Guest Agent（避免与 Azure VM Agent / Hyper-V KVP 交换守护进程混淆） |
Azure Connected Machine Agent（亦称 Arc agent，含上述三层组件） |
|
来源 |
Azure Local VM Management Stack（不属于 Azure Arc 体系） |
Azure Arc-enabled Servers（Guest 侧，属于 Azure Arc 体系） |
|
部署时机 |
由 Azure Local VM 创建流程注入——不是所有 Guest OS 都支持（取决于 Trusted Launch / Generation / OS 支持矩阵） |
mocguestagent 运行后，通过 az stack-hci-vm update –enable-agent true 触发 |
|
职责 |
Azure Local 平台 ↔ Guest 通信；提供 VM 配置、状态、provisioning 信号（不负责 Azure 端 Resource 生命周期） |
Azure Arc 控制平面 ↔ Guest 通信；Azure Arc 扩展执行框架的一部分（Connected Machine Agent + Arc agent extensions + Extension handlers 三层下发与执行——承载 Guest Configuration、Update Manager 等） |
|
部署位置 |
客户机（Guest OS）内部 |
客户机（Guest OS）内部 |
|
验证方式 |
az stack-hci-vm show → instanceView.vmAgent.statuses[].displayStatus = Connected |
Azure 门户 VM Overview → Configuration → Guest Management = Enabled (Connected) |
|
控制平面归属 |
Azure Local VM Management Stack（平台侧） |
Azure Arc 控制平面（Guest 侧） |
§1.6.2 三条铁律
- mocguestagent 与 Connected Machine Agent 不是同一组件，职责不重叠，不能互相替代；
- 顺序关系：mocguestagent 必须在 VM 内运行（Connected），才能触发 Guest Management 启用安装 Connected Machine Agent；
- Windows Server 2012 / 2012 R2 Guest 不满足 Azure Local Guest Management 所需支持条件——mocguestagent 依赖 Hyper-V sockets 通信能力，WS2012/2012R2 Guest 不在该支持矩阵内。重要：这不是简单"缺 Hyper-V sockets"（Hyper-V sockets 本身在较早 Windows Server 版本已存在），而是 Azure Local 当前 Guest Management 支持矩阵未涵盖 WS2012/2012R2。详细背景可参考 Microsoft Learn 关于 Hyper-V sockets。
§1.6.3 Guest Management 启用顺序
一句话："mocguestagent 让 Azure Local 看到 VM；Connected Machine agent 让 Azure Arc 控制 VM。"
支持范围说明（v1.3.4 新增）：mocguestagent 不是对所有 Guest OS 都必须——具体取决于 Trusted Launch / Generation / OS 支持矩阵。例如 Windows Server 2012 / 2012 R2 Guest 不满足 Azure Local Guest Management 所需支持条件（详见 §1.6.2）。
§1.7 Azure Local VM vs Hyper-V VM
|
维度 |
Hyper-V VM |
Azure Local VM |
|
创建入口 |
Hyper-V Manager |
Azure Portal / ARM / CLI |
|
资源模型 |
本地对象 |
ARM Resource |
|
控制平面 |
Failover Cluster |
Azure ARM + Arc |
|
身份认证 |
AD |
Azure RBAC |
|
生命周期 |
PowerShell / WAC |
Azure API |
|
网络 |
Virtual Switch |
Logical Network |
|
自动化 |
PowerShell |
ARM / Bicep /Terraform |
§1.8 本章小结
- Azure Local VM 是 Azure Local 平台承载的、以 Azure 资源形式呈现的虚拟机；其管理由 Azure Arc 基础设施（Arc Resource Bridge + Custom Location）+ Azure Local VM Management Stack（MOC + Resource Providers + mocguestagent）共同支撑；
- Azure Local VM 作为 ARM Resource 创建依赖 Arc Resource Bridge + Custom Location + Azure Local VM Management Stack（含 MOC + RP）；mocguestagent 是 VM 创建后注入的 Guest 组件，不参与 ARM Resource 创建；其中前两个属于 Azure Arc 基础设施，后三个属于 Azure Local VM Management Stack；Guest Management 是创建之后的可选扩展能力；
- 两个 Agent（mocguestagent 与 Connected Machine Agent）职责不重叠，按顺序部署；mocguestagent 属于 Azure Local VM Management Stack，Connected Machine Agent 属于 Azure Arc-enabled Servers——两者分属不同体系；
- 本篇至此告一段落；篇 2 开始动手创建 VM。
§2 创建前的资源准备工作
目标读者：将开始动手实施 Azure Local VM 的运维工程师、平台团队。
核心问题：在点"创建"按钮或跑 az stack-hci-vm create 之前，需要在 Azure 侧、本地侧、镜像侧、网络侧、工具侧分别准备什么？四个前置资源应按什么顺序准备？
§2.1 五维准备清单
按 官方文档（Azure Local VM management prerequisites） 口径，把准备工作拆成五个维度：
|
维度 |
核心项 |
验证方式 |
|
Azure 侧 |
有效订阅、适当 RBAC、订阅所在区域在支持清单 |
System requirements |
|
本地侧 |
已部署 / 已注册的 Azure Local 实例、Arc 连接已 Connected、Custom Location 与 Arc resource bridge 在当前 Azure Local（2405/250x 以后）部署流程中通常自动创建——以前版本需要 Deploy Cluster → Deploy Arc Resource Bridge → Create Custom Location 三步分开操作 |
Azure Local 资源页 Overview > Server |
|
镜像侧 |
至少 1 个 VM image（Marketplace / Storage Account / Local Share），en-us 语言 VHD |
az stack-hci-vm image list |
|
网络侧 |
Logical Network / NIC / 防火墙出站规则满足 Required firewall URLs |
防火墙规则审计 |
|
工具侧 |
Azure CLI + stack-hci-vm 扩展（远程路径），或直接连到 Azure Local 实例（部署时已自动安装） |
az extension list |
§2.2 Azure 侧准备
§2.2.1 订阅与区域
- 订阅类型不限——文档列出的可选类型包括 Free（学生 / Visual Studio 订阅）、Pay-as-you-go、EA、CSP；
- 订阅所在区域必须出现在 System requirements for Azure Local 的支持区域清单中；
- 所有 Azure Local VM 相关实体（Azure Local 实例、Arc resource bridge、Custom Location、VM operator、VM、Arc for Servers guest management）必须注册 / 创建在同一个 Azure 区域（可在同一区域的不同资源组中）；
- 资源组间不需要在同一资源组，但资源组不可移动—— Azure Local VM 及其关联资源不支持移动到其他资源组。
§2.2.2 RBAC 角色
- 详见 RBAC roles for Azure Local VM management；
- 内置 RBAC 角色覆盖 VM 创建、删除、扩展管理等不同操作；建议为不同团队（平台运维 / 应用 owner）分配不同角色。
§2.2.3 不应忽视的配额约束
按官方 overview 表述，Azure 订阅与服务存在配额限制——Azure Local VM 同样受 Azure 配额约束。具体配额数字以 Azure subscription and service limits 当期为准。
§2.3 本地侧准备
§2.3.1 必备的先决状态
- Azure Local 实例已部署、已注册（按 Azure Local 部署文档）；
- Azure Local 资源页 Overview > Server 中 Azure Arc 显示为 Connected；
- 同一 Overview 页面应能看到 Custom Location 与 Azure Arc resource bridge 自动创建的资源条目。
§2.3.2 Arc Resource Bridge 的版本演进
Arc Resource Bridge 的部署方式随 Azure Local 版本演进发生了变化——这一点对早期版本升级尤其重要：
|
Azure Local 版本 |
Arc Resource Bridge 部署方式 |
|
早期 Azure Stack HCI / Azure Local 版本 |
Arc Resource Bridge 独立部署 |
|
较新的 Azure Local 部署流程 |
Arc Resource Bridge 通常由部署流程自动创建和配置 |
历史背景：早期 Azure Local 与 Arc Resource Bridge 是两个独立运维对象——这种"先 Cluster 后 Bridge"的分阶段部署流程与 250x 版本之后的统一部署有显著差异。本文假定读者使用的版本在 2405 之后；如使用更早版本，请参考当期官方部署文档的具体步骤。
§2.3.3 关于 Arc Resource Bridge 的删除警告
按 官方文档 的 Important 提示：
Azure Arc resource bridge 是 Azure Local VM 管理关键组件，不应删除，除非重新镜像或下线整个 Azure Local 实例。删除 Arc resource bridge 会丢失 Azure 控制平面（但本地工作负载仍可通过 WAC / Hyper-V / PowerShell 访问）。
如果确实需要删除 Arc resource bridge，必须先删除所有 Azure Local 工作负载资源：
- Azure Local VM
- AKS Arc 集群
- VM images
- Storage paths
- Logical networks
- Network interfaces
- Virtual hard disks
- Network security groups
删除顺序：先工作负载资源 → 再 Arc resource bridge → 最后 Custom Location。
§2.4 镜像侧准备
§2.4.1 三种镜像来源
|
来源 |
适用场景 |
关键约束 |
|
Azure Marketplace 镜像 |
标准操作系统（Windows Server / Windows Client / Ubuntu LTS 等） |
联网环境；按需下载到本地 |
|
Azure Storage Account 镜像 |
企业自定义镜像、私有镜像分发 |
需要 Azure 存储账户 |
|
本地共享镜像 |
Disconnected Operations / 气隙场景 |
需存放在 Cluster Shared Volume，可被所有节点访问 |
§2.4.2 镜像语言约束
按 官方 prerequisites 文档 表述：
VM image 必须使用 en-us 语言 VHD；其他语言 VHD 在微软当前文档中未明示支持。
§2.4.3 Windows Server 2012 / 2012 R2 的特殊约束
- 通过 Azure 门户创建 VM 不支持 Windows Server 2012 / 2012 R2 镜像；
- 仅能通过 Azure CLI 创建 VM；
- Windows Server 2012 / 2012 R2 VM 启用 Guest Management 时会失败（缺 Hyper-V sockets 支持）；
- 其余 Guest OS 是否支持 Guest Management，依 Microsoft Learn 关于 Hyper-V sockets 的当期表述。
§2.5 网络侧准备
§2.5.1 基础设施逻辑网络（Infrastructure Logical Network）说明
关键提醒：Infrastructure Logical Network 不只是给 Arc Resource Bridge——还承载 MOC、Kubernetes cluster extension、Compute / Storage / Network 等 Resource Provider 等基础服务。
Azure Local 部署时自动创建的 Infrastructure logical network 是平台层管理网络，不仅仅是给 Arc Resource Bridge 单独使用。按 官方 requirements 文档 与 requirements-overview，Infrastructure logical network 实际承载以下 Azure Local 内部组件：
|
使用方 |
是否使用 Infrastructure logical network |
|
Arc Resource Bridge |
✅ |
|
Azure Local 本地管理集群（K8s cluster extension） |
✅ |
|
MOC（Microsoft On-premises Cloud）组件 |
✅ |
|
Azure Local 资源提供程序（Compute / Storage / Network RP 等） |
✅ |
|
Azure Local 平台基础服务通信 |
✅（平台内部） |
理解要点：Infrastructure logical network 是 Azure Local 平台基础设施的内部通信网络——与 VM 的 Logical Network（VM 业务网络，§2.7.3）是两个完全独立的网络。把两者混淆会导致错误地把 VM 业务流量放进 Infrastructure 网络，引发安全风险。
§2.5.2 防火墙出站
按 Required firewall URLs for Azure Local deployments 文档，确保本地实例与 Azure Arc 通信所需的所有出站 URL 开放。
§2.5.3 Disconnected Operations 的网络限制
v1.3.4 弱化：Disconnected Operations 场景的网络代理与 Azure 连接限制随版本演进——以下是当期文档列举的常见约束；具体限制以当前版本 Disconnected Operations 文档为准。
按 Disconnected operations 文档：
- 存在 Proxy 服务器使用限制（部分操作可能不支持通过 Proxy 出站）——具体支持范围以当期文档为准；
- 仅 Logical networks 可以浏览使用，门户中可能不会完整加载；
- Network interfaces 在该模式下通常仅支持 Azure CLI 创建（不支持门户）——具体支持范围随版本演进。
§2.6 工具侧准备
§2.6.1 直接连接到 Azure Local 实例
- 部署 Azure Local 时已自动安装 Azure CLI 与 stack-hci-vm 扩展；
- 无需额外操作；
- 适用一次性 / 调试场景。
§2.6.2 远程访问
需在客户端准备：
|
工具 |
版本要求 |
安装 |
|
Azure CLI |
最新版（按当期官方文档） |
Install Azure CLI |
|
stack-hci-vm 扩展 |
与目标 Azure Local 实例匹配 |
az extension add –name stack-hci-vm –version "<version>" |
|
Azure PowerShell（视场景） |
与 CLI 配合或替代 |
Install-Module Az |
|
Terraform（IaC 路径） |
满足 示例 Terraform 配置 的版本组合 |
Terraform 官方安装 |
§2.6.3 远程登录 Azure CLI
az login –use-device-code
az account set –subscription <Subscription ID>
§2.7 四个前置资源——按顺序准备
按 官方推荐路径，创建 VM 之前需要按顺序准备 4 个前置资源：
|
顺序 |
资源 |
关键作用 |
创建后不可改字段 |
|
1 |
Storage Path |
把 CSV 路径暴露为 Azure 资源 |
删除前必须先删 VM / Image / Disk |
|
2 |
VM Image |
VM 创建时拷贝镜像（更新 Image 不影响已建 VM） |
同名 Image 创建会失败 |
|
3 |
Logical Network |
取代旧版 Virtual Network（2311.2 起） |
Default gateway / IP pools / IP address space / VLAN ID / Virtual switch name |
|
4 |
Network Interface |
关联到 Logical Network，可选静态或动态 IP |
添加静态 IP NIC 必须在 VM 创建前完成 |
§2.7.1 Storage Path：ARM Resource <-> CSV 的映射
Storage Path 是 Azure Local VM management 对 CSV 存储位置的抽象——把 Azure 侧的 Storage Container Resource（Microsoft.AzureStackHCI/storagecontainers）映射到本地的 S2D 卷可用路径，不必是物理子目录。该资源在 Azure Local VM 管理模型中沿用了 storage container 命名，但语义不同于 Azure Storage Container。理解这一点对后续 VM 部署与运维至关重要。
重要区分（v1.3.4 新增）：Storage Path / Storage Container（Microsoft.AzureStackHCI/storagecontainers）是 Azure Local VM 管理模型中的存储容器抽象，不等同于 Azure Storage Account Container（Microsoft.Storage/storageAccounts/blobServices/containers）。前者是 Azure Local 平台侧的 S2D 卷路径抽象，后者是公有云 Azure Blob Storage 的容器对象；二者 API 模型、资源组归属、计费模型完全不同——把 Storage Path 理解为 Azure Blob Container 是常见误读。
映射关系：
|
概念 |
物理 / 逻辑层 |
Azure 侧体现 |
|
Cluster Shared Volume（CSV） |
S2D 提供的共享卷，每节点可见 |
物理路径 |
|
Storage Path |
一个 CSV 上的"子目录" |
Storage Container Resource（Microsoft.AzureStackHCI/storagecontainers）——是 Azure Local VM 存储路径的抽象，而非"等于"该物理路径 |
|
Azure Local VM 工作文件（OS 磁盘 + 数据磁盘） |
Storage Path 下的文件 |
通过 VM ARM Resource 反向引用 Storage Path |
- 路径示例：C:\\ClusterStorage\\UserStorage_1\\VMPath（物理 CSV 上的子目录）
- 不指定时：Azure Local 会自动选择高可用存储路径
- 删除顺序：删除 Storage Path 前，需先删除该路径上的所有 VM / Image / Data disk
§2.7.2 VM Image
- VM Image 是快照式资源——VM 创建时会拷贝 Image，更新 Image 不会影响已创建的 VM（微软对此场景的术语：Copy-on-create——Image 始终为冻结快照）
- 重名 Image 创建会失败
- 删除 Image 不会导致已部署的 VM 被删除
§2.7.3 Logical Network
版本历史背景（v1.3.4 新增）：在早期 Azure Stack HCI VM Management 时代（旧版部署），VM 业务网络使用 Virtual Network 资源类型——这是当时 Azure Stack HCI 时代的命名。自 Azure Local 2311.2 起，Virtual Network 被 Logical Network 取代——当前 Azure Local 文档默认使用 Logical Network。
早期公开资料、博客、Stack Overflow 答案中仍会出现 virtualNetwork / networkInterface 旧字段命名，本文统一以 Logical Network 为准；旧版 Virtual Network 资源不能用于 2311.2 及之后版本。
- 自 Azure Local 2311.2 起，Logical Network 取代了 Virtual Network
- 旧版本创建的 Virtual Network 不能用于 2311.2 及之后版本——必须手动删除
- 创建后以下字段不可更新（具体字段随版本演进变化，以当期 Azure Local 官方文档为准）：
- Default gateway
- IP pools
- IP address space
- VLAN ID
- Virtual switch name（特定版本支持情况可能不同）
§2.7.4 Network Interface
- 关联到 Logical Network；可选静态或动态 IP
- 创建 VM 之后不支持添加静态 IP 的 NIC——多 NIC / 静态 IP 必须在 VM 创建前完成
- 创建 VM 时至少需要一个 NIC——否则 Guest Management 无法启用
§2.8 本章小结
- 创建前的准备涉及 Azure 侧、本地侧、镜像侧、网络侧、工具侧 5 个维度；
- 四个前置资源（Storage Path → VM Image → Logical Network → NIC）必须按官方推荐顺序准备；
- 部分 Logical Network 字段创建后不可更改，应在创建前一次性规划好。
附录 A：参考链接
- Create Azure Local Virtual Machines Enabled by Azure Arc
- What is Azure Local VM management
- Azure Local VM management prerequisites
- Manage Azure Local VMs enabled by Azure Arc
- Azure Local VMs Enabled by Azure Arc FAQ
- Overview for Trusted launch for Azure Local VMs enabled by Azure Arc
- Disconnected operations with Azure Local VMs enabled by Azure Arc
- System requirements for Azure Local
- Required firewall URLs for Azure Local deployments
- Azure Arc resource bridge overview
- RBAC roles for Azure Local VM management
- 示例 ARM 模板：aka.ms/hci-vmarmtemp
- 示例 Bicep 模板：aka.ms/hci-vmbiceptemplate
- 示例 Terraform 配置：terraform-azurerm-avm-res-azurestackhci-virtualmachineinstance
附录 B：版本与原则说明
- 文档版本基线：本文对应微软官方文档 2506/2510（2026 年 6 月），对版本相关的具体数字、限制、能力范围，以当期微软官方文档为准。
- 当前版本：v1.3（2026 年 7 月，v1.1 基础上的重大修订）。
- 三层原则：本文对"必须 / 不能"措辞仅用于微软官方硬要求；对 Portal / 工具默认行为用"默认"；对企业最佳实践用"建议 / 推荐"。
- 不引用内部资料：本文不引用内部笔记、私人写作准则等内部积累材料；所有判断均以微软当期公开文档为准。
文档维护说明：本文对应微软官方文档版本 2506/2510（2026 年 6 月）；本文不替代微软官方文档，仅作为企业架构师评估与实施 Azure Local VM 时的中文参考材料。
版本历史：
- v1.1：首版发表（2026 年 6 月）
- v1.3（本次修订）：基于 ACP（Azure Community Partner）五轮反馈，对 Azure Arc 依赖关系精确化、平台架构分层、Trusted Launch / VM Placement / GPU Assignment 等补充内容做了系统性升级；详见 v1.3 修订记录。
