创建由 Azure Arc 启用的 Azure Local 虚拟机

未经同意，请勿转载！

TL;DR：在 Azure Local（基于 Azure Stack HCI 构建的本地分布式基础设施）上创建由 Azure Arc 启用的虚拟机，本质是把本地 Hyper-V 工作负载纳入 Azure 的管理平面；Azure Local VM 的创建本身不依赖 Azure Arc——是否启用 Guest Management 仅决定 VM 是否同时具备 Arc-enabled server 的扩展能力（Azure Policy、Update Manager、Defender for Cloud 等），不影响 VM 能否创建、能否运行、能否被本地工具运维。本文按四个章节展开：概念边界 → 创建前准备 → 创建路径 → 之后运维。

术语约定：本文首次使用 Azure Local VM（亦称 Azure Local VMs enabled by Azure Arc）这一微软官方表述，统一简称为 Azure Local VM，不再混用"Arc VM / Arc-enabled VM"等其他变体。

全局视图

第一章确立"是什么 / 不是什么"以及 Arc 的边界；第二章按四前置资源 + 五维准备搭起执行清单；第三章用五种路径把 VM 创建出来；第四章把 Guest Management 启用、日常管理与责任边界收口。

第一章：概念边界与 Azure Arc 的作用范围

目标读者：刚接触 Azure Local 的架构师、评估团队、技术决策者。

核心问题：Azure Local VM 究竟是什么？是不是必须启用 Azure Arc 才能用？两个 Agent 怎么区分？

§1.0 总体架构图（强烈推荐先看）

本节是整篇文章最应该出现的一张图——先看这一张图，再看后续 §1.1~§1.7 详细组件说明，能让 Azure Local VM 的运行机制一次看清。

关键识别：

• 红色框（Arc Resource Bridge）：Azure Local VM 作为 ARM Resource 存在的必需基础设施

• 蓝色框（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 资源形式呈现的虚拟机。它由 Azure Local 平台承载（底层仍是 Hyper-V + Failover Cluster + Azure Stack HCI OS），由 Azure Arc 提供 Azure 一致性的管理体验。

§1.2 Azure Local VM 不是什么

这是企业评估阶段最常见的误解来源——明确以下"不是什么"是划清边界的捷径：

§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 Local 平台栈远远不止"Hyper-V + FC + HCI OS"。VM 管理工作负载依托在这一整套平台栈上，理解这一点有助于理解为何某些操作（如 ARM 层资源映射）依赖 Arc Infrastructure 与 Compute RP。上述平台栈中，只有 Compute Resource Provider、Arc Resource Bridge、Management Cluster 等组件直接参与 Azure Local VM 生命周期管理；其余组件属于 Azure Local 平台运行基础设施，为 VM 管理提供底层能力。

§1.3.1 VM 管理四大关键组件

按 官方 overview 文档 表述，Azure Local VM 管理由下列四大关键组件协同支撑：

§1.4 Azure Local VM 总体架构图（强烈推荐先看这一张）

这是理解 Azure Local VM 工作原理的总览图——从用户操作入口到 Guest OS 自下而上分八层。强烈建议先看这一张图，再看后续组件介绍。

图的阅读顺序：

§1.5 必备小节——精确理解 Azure Arc 与 Azure Local VM 的依赖关系

单独列出，是因为企业实施过程中最容易被误解。"Azure Local VM 不依赖 Azure Arc 也能跑"是一种不准确的简化——准确的关系需要把 "Azure Arc" 拆解成至少三个独立组件理解。

§1.5.1 一个常见误区

v1.x 版本本文曾表述为"Azure Arc 让 Azure Local VM 多了一些 Azure 能力，但 Azure Local VM 本身不靠 Arc 也能跑"。这一表述意图对，但存在以下两个层次的偏差：

§1.5.2 Arc 组件的三层拆分（关键）

为消除歧义，把"Azure Arc"按 Azure Local VM 场景拆分为三层独立组件，并标明各自对 VM 创建 / 运行 / Azure 可见性的依赖关系：

§1.5.3 三类问题对各层组件的依赖

§1.5.4 关键结论

• "Azure Local VM 不依赖 Azure Arc" 是不准确的简化表述——准确说法应避免把 "Azure Arc" 作为单一概念；
• Azure Local VM 的运行（Guest OS 工作负载能否运行）依赖 Azure Local 平台（Hyper-V + Failover Cluster + SDN + S2D + Azure Stack HCI OS + Arc Infrastructure 等整套平台栈，详见 §1.3.1）；
• Azure Local VM 的 Azure 资源生命周期（能否从 Azure 端创建 / 删除 / 启停 / 状态查询）依赖 Arc Resource Bridge + Custom Location + mocguestagent 这一整套 Azure Arc 基础设施；
• Azure Local VM 的 Azure 侧扩展能力（Azure Policy、Update Manager、Defender for Cloud）依赖 Azure Connected Machine Agent（Guest Management），这是可选的；
• 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 管理，Guest OS 工作负载由 Hyper-V + Failover Cluster 管理，这两层可以解耦（Azure 连接受影响时本地仍能跑，平台故障时 Azure 可见但 Guest 不可达）。

一句话："Arc Resource Bridge 负责把 Azure Local VM 映射为 Azure ARM Resource；mocguestagent 负责 Guest OS 与 Azure Local 平台之间的通信；Azure Connected Machine Agent 负责 Guest OS 与 Azure Arc 服务之间的通信。"三层各司其职。

§1.6 两个 Agent 的严格区分

这是另一个企业实施过程中容易混淆的点。

§1.6.1 一表区分

§1.6.2 三条铁律

• mocguestagent 与 Connected Machine Agent 不是同一组件，职责不重叠，不能互相替代；
• 顺序关系：mocguestagent 必须在 VM 内运行（Connected），才能触发 Guest Management 启用安装 Connected Machine Agent；
• Windows Server 2012 / 2012 R2 不支持 mocguestagent（缺 Hyper-V sockets 支持，按 Microsoft Learn 关于 Hyper-V sockets 表述），因此也不支持 Guest Management。

§1.6.3 Guest Management 启用顺序

一句话："mocguestagent 让 Azure Local 看到 VM；Connected Machine agent 让 Azure Arc 控制 VM。"

§1.7 本章小结

• Azure Local VM 是 Azure Local 平台承载的、以 Azure 资源形式呈现的虚拟机；
• Azure Local VM 创建依赖 Arc Resource Bridge + Custom Location + mocguestagent（Azure Arc 基础设施层）；Guest Management 是创建之后的可选扩展能力；
• 两个 Agent（mocguestagent 与 Connected Machine Agent）职责不重叠，按顺序部署；
• 后续章节按"准备 → 创建 → 运维"展开。

第二章：创建前的资源准备工作

目标读者：将开始动手实施 Azure Local VM 的运维工程师、平台团队。

核心问题：在点"创建"按钮或跑 az stack-hci-vm create 之前，需要在 Azure 侧、本地侧、镜像侧、网络侧、工具侧分别准备什么？四个前置资源应按什么顺序准备？

§2.1 五维准备清单

按 官方文档（Azure Local VM management prerequisites） 口径，把准备工作拆成五个维度：

§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 是两个独立运维对象——这种"先 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 三种镜像来源

§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 是 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 的网络限制

按 Disconnected operations 文档：

• 不支持 Proxy 服务器用于出站；
• 仅 Logical networks 可以浏览使用，门户中可能不会完整加载；
• Network interfaces 在该模式下仅支持 Azure CLI 创建（不支持门户）。

§2.6 工具侧准备

§2.6.1 直接连接到 Azure Local 实例

• 部署 Azure Local 时已自动安装 Azure CLI 与 stack-hci-vm 扩展；
• 无需额外操作；
• 适用一次性 / 调试场景。

§2.6.2 远程访问

需在客户端准备：

§2.6.3 远程登录 Azure CLI

az login –use-device-code
az account set –subscription <Subscription ID>

§2.7 四个前置资源——按顺序准备

按 官方推荐路径，创建 VM 之前需要按顺序准备 4 个前置资源：

§2.7.1 Storage Path：ARM Resource <-> CSV 的映射

Storage Path 是把 CSV 文件夹（物理路径）暴露为 Azure 侧 ARM Resource 的抽象层——理解这一点对后续 VM 部署与运维至关重要。

映射关系：

• 路径示例：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

• 自 Azure Local 2311.2 起，Logical Network 取代了 Virtual Network
• 旧版本创建的 Virtual Network 不能用于 2311.2 及之后版本——必须手动删除
• 创建后以下字段不可更新：
  • 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 字段创建后不可更改，应在创建前一次性规划好；
• 后续章节开始创建 VM。

第三章：创建 Azure Local VM 的实操路径

目标读者：动手创建 VM 的运维工程师、自动化脚本作者。

核心问题：应该用 Portal / CLI / ARM / Bicep / Terraform 中的哪一种？Trusted Launch、动态内存、Windows Server 2012 这些特殊选项怎么用？

§3.0 关键背景：Azure Local VM 作为 ARM Resource

在动手创建之前，需要再次强调：Azure Local VM 在 Azure 端是一个 ARM Resource，而不是 Azure 数据中心的 Azure VM。

• ARM Resource 类型：Microsoft.AzureStackHCI/virtualMachineInstances
• 资源提供程序 namespace：Microsoft.AzureStackHCI
• Microsoft 官方未使用 "First-class Resource" 描述 Azure Local VM——本文沿用微软的 "Azure 资源 / ARM Resource" 表述，不使用 first-class 等社区化叫法（避免被引用扩散）
• 资源所在 region：与 Azure Local 实例所在的 region 一致（详见 §2.2.1）
• 跨订阅 / 跨资源组约束：Azure Local VM 及其关联资源（NIC / Image / Storage Path / Data Disk）不支持跨资源组移动——ARM 层限制。

理解这点的意义：从 Azure 端操作 Azure Local VM（无论是 Portal / CLI / ARM 模板 / Bicep / Terraform）都是针对一个 ARM Resource 发请求；ARM 把请求通过 Custom Location 路由到本地 Arc Resource Bridge，再由本地 K8s cluster extension 转化为对 Hyper-V / Failover Cluster 的调用。Azure 端看到的是 ARM Resource，Guest OS 内看到的是普通虚拟机——这两个视图需要在 §4.3 速查里区分清楚。

§3.1 五种创建路径对比

按 官方文档 口径，Azure Local VM 支持 5 种创建路径：

§3.2 通用参数

不管走哪条路径，Azure Local VM 创建时的参数集合大体相同。按 官方文档 表格：

§3.3 Azure CLI 路径详解

Azure CLI 是最常用的路径——它介于 Portal 与 ARM 模板之间，可脚本化、可调试。

§3.3.1 登录与订阅选择

az login –use-device-code
az account set –subscription <Subscription ID>

§3.3.2 设置参数（PowerShell 风格示例）

$vmName = "local-vm"
$subscription = "<Subscription ID>"
$resource_group = "local-rg"
$customLocationName = "local-cl"
$customLocationID = "/subscriptions/$subscription/resourceGroups/$resource_group/providers/Microsoft.ExtendedLocation/customLocations/$customLocationName"
$location = "eastus"
$computerName = "mycomputer"
$userName = "local-user"
$password = "<Password for the VM>"
$imageName = "ws22server"
$nicName = "local-vnic"
$storagePathId = "/subscriptions/$subscription/resourceGroups/local-rg/providers/Microsoft.AzureStackHCI/storagecontainers/local-sp"

§3.3.3 创建标准 VM

az stack-hci-vm create \\
–name $vmName \\
–resource-group $resource_group \\
–admin-username $userName \\
–admin-password $password \\
–computer-name $computerName \\
–image $imageName \\
–location $location \\
–authentication-type all \\
–nics $nicName \\
–custom-location $customLocationID \\
–hardware-profile memory-mb="8192" processors="4" \\
–storage-path-id $storagePathId

成功创建标志：输出中 provisioningState = succeeded。

§3.3.4 Trusted Launch：与 Hyper-V VM 的关键区别

Trusted Launch 是 Azure Local VM 与"裸 Hyper-V VM"的显著区别之一——许多企业决定迁移到 Azure Local VM 时，Trusted Launch 是重要驱动。

Trusted Launch 能力清单（按 trusted-launch-vm-overview）：

重要：Secure Boot + vTPM 必须同时启用才能称为 Trusted Launch——单独启用任何一个不算 Trusted Launch。

§3.3.4.1 创建 Trusted Launch VM

Trusted Launch 是一种安全类型——创建命令需显式指定 –security-type "TrustedLaunch"：

az stack-hci-vm create \\
–name $vmName \\
–resource-group $resource_group \\
–admin-username $userName \\
–admin-password $password \\
–computer-name $computerName \\
–image $imageName \\
–location $location \\
–authentication-type all \\
–nics $nicName \\
–custom-location $customLocationID \\
–hardware-profile memory-mb="8192" processors="4" \\
–storage-path-id $storagePathId \\
–enable-secure-boot true \\
–enable-vtpm true \\
–security-type "TrustedLaunch"

创建后验证（Trusted Launch）：

# 1. 找到 VM 所在节点
Get-ClusterGroup $vmName

# 2. 在该节点上执行
(Get-VM $vmName).GuestStateIsolationType
# 应返回 TrustedLaunch

Trusted Launch 关键运营约束（按 trusted-launch-vm-overview）：

§3.3.5 VM Placement（亲和性 / 反亲和性 / 故障域）

VM Placement 是 Azure Local VM 的高可用调优机制——许多企业在生产环境中关心"哪些 VM 应该共置 / 哪些 VM 应该分散"。按 官方 VM placement overview 文档，Azure Local VM 支持以下放置策略：

生产建议（推荐）：关键应用的多实例（如 Web Farm、SQL AlwaysOn AG）建议配置 Anti-affinity 跨节点 + 跨 Fault Domain——避免单硬件故障导致整组不可用。

详细参数与配置示例见 官方 VM placement 配置文档。

§3.3.6 创建动态内存 VM

动态内存允许 VM 在指定范围内动态调整内存：

az stack-hci-vm create \\
–name "my_dynmemory" \\
-g "my_registration" \\
–admin-username "admin" \\
–admin-password "<password>" \\
–custom-location "<customLocationID>" \\
–location "eastus" \\
–image "<imageResourceID>" \\
–hardware-profile vm-size="Custom" processors=1 \\
memory-mb=1024 \\
maximum-memory-mb=2048 \\
minimum-memory-mb=1024 \\
target-memory-buffer=20 \\
–enable-agent true \\
–nics "dynnic"

约束：minimum-memory-mb ≤ memory-mb ≤ maximum-memory-mb。

§3.3.7 GPU Assignment（DDA / GPU Partition）

Azure Local VM 支持 GPU 工作负载，按当前硬件 / 操作系统支持分为两大模式：

详细机制差异（按 NVIDIA vGPU Manager 调度）：

• DDA：PCIe 直通，单 VM 独占整卡——性能损耗最低但单 VM 占用整卡。
• GPU-P：基于 vGPU Manager 的时间分片 + 显存隔离调度（不是硬件级 MIG）——一张卡切 N 份 partition，每个 partition 独立 vGPU driver。
• MIG（Multi-Instance GPU）：仅在 NVIDIA A100 / H100 等数据中心 GPU 上可用，Azure Local 当前未集成 MIG 生命周期管理——通过 DDA 直通给 VM 后由 Guest OS 内手动配置 MIG。

配置命令（GPU-P 模式示例）：

# 1. 在 Host 上安装 NVIDIA vGPU Manager + driver
# 2. 通过 Windows Admin Center 创建 GPU-P partition
# 3. 通过 Azure CLI 在 VM 创建时指定 partition
az stack-hci-vm create \\
–name "my-gpuvm" \\
-g "my-rg" \\
–custom-location "<customLocationID>" \\
–location "eastus" \\
–image "<imageResourceID>" \\
–hardware-profile vm-size="Custom" processors=4 memory-mb=8192 \\
–gpus "<gpu-partition-id>"

具体支持的卡型与 partition 数取决于硬件——按当期 OEM Support Matrix 与 NVIDIA vGPU 兼容性列表为准；Azure Local 当前不集成 MIG 生命周期管理（如需 MIG 需在 Guest OS 内手动配置）。

§3.3.8 Windows Server 2012 / 2012 R2 特殊路径

• 通过 Azure Portal 不支持；
• 仅能通过 Azure CLI 创建；
• 创建之后不支持启用 Guest Management（缺 Hyper-V sockets 支持）；
• 额外 CLI 参数详见 官方文档对应小节。

§3.4 Azure Portal 路径

Portal 路径适合一次性创建与图形化探索：

Portal 路径与 Trusted Launch 的小陷阱：

按 FAQ 表述——Trusted Launch 在门户中仅显示其支持的镜像列表；不支持 Trusted Launch 的镜像（包括自定义镜像）在下拉列表中显示为空白。

§3.5 ARM 模板路径

示例 ARM 模板 可从 GitHub 快速启动模板库下载。

前置资源要求：RBAC + Image + Custom Location + Logical Network（ARM 路径强制）。

适用场景：跨环境复用、标准化部署、多资源一并部署。

§3.6 Bicep 模板路径

示例 Bicep 模板 在 ARM 模板基础上提供类型安全与模块化能力。

前置资源要求：与 ARM 模板一致。

适用场景：长期 IaC 演进、模块化复用、代码可读性优先。

§3.7 Terraform 路径

示例 Terraform 配置 在 azapi / azurerm providers 之上封装 Azure Local VM 资源。

前置资源要求：RBAC + Image + Custom Location + Logical Network + Terraform + Git。

适用场景：多云一致 IaC、与现有 Terraform 工作流集成、状态管理需求。

§3.8 创建时的通用注意事项

按 官方文档 顶部 Note 提示：

• 空 DVD 驱动器：创建过程中会生成两个 DVD 驱动器；ISO 文件在创建成功后被移除，但空驱动器可能仍可见——Windows VM 通过 Device Manager 卸载；Linux VM 按具体发行版处理。
• 跨资源组引用：当被引用的资源（Disk / NIC / Image / Storage Path）在不同资源组时，必须传递完整 Resource ID。
• 存储路径不指定时：Azure Local 自动将工作负载（VM / Image / 非 OS 数据盘）放在高可用存储路径。
• Guest Management 默认启用：通过 Portal / CLI 创建的 VM 默认启用 Guest Management；如创建过程失败，可按第四章流程恢复。

§3.9 本章小结

• Azure Local VM 支持 5 种创建路径——按自动化能力与场景选择；
• Trusted Launch 必须 Secure Boot + vTPM 一起启用，并需要手动备份 VM Guest State Protection Key；
• 动态内存必须在 minimum ≤ memory ≤ maximum 范围内；
• Windows Server 2012 / 2012 R2 镜像仅 CLI 路径可用；
• 创建后 Guest Management 默认启用；如失败，按第四章流程恢复。

第四章：创建之后的 Guest Management 与运营管理

目标读者：负责 VM 全生命周期运营的运维工程师、可靠性团队。

核心问题：Guest Management 失败了怎么恢复？不同异常状态如何应对？哪些能力依赖 Arc、哪些不依赖？运营中遇到 FAQ 怎么办？

§4.1 Guest Management 启用与验证流程

第四章以异常恢复为重点——按 manage-arc-virtual-machines 文档口径整理。

§4.1.1 默认状态

通过 Azure Portal 或 Azure CLI 创建的 VM 默认启用 Guest Management；如创建过程中失败，按下列流程在创建之后重新启用。

§4.1.2 验证 Guest Agent 状态

az stack-hci-vm show \\
–name "<VM name>" \\
–resource-group "<Resource group name>"

输出片段中 instanceView.vmAgent.statuses[].displayStatus：

§4.1.3 异常状态恢复

状态为 Connecting（ISO 已挂载但未安装）：

• Windows VM：

$d = Get-Volume -FileSystemLabel mocguestagentprov
$p = Join-Path ($d.DriveLetter + ':\\') 'install.ps1'
powershell $p

• Linux VM：

sudo — sh -c 'mkdir /mociso && mount -L mocguestagentprov /mociso && bash /mociso/install.sh && umount /mociso && rm -df /mociso && eject LABEL=mocguestagentprov'

状态为 null（ISO 缺失）：

az stack-hci-vm update \\
–name "<VM Name>" \\
–resource-group "<Resource group name>" \\
–enable-vm-config-agent true

挂载 ISO 后等待状态变为 Connecting，再按上述流程执行安装。

§4.1.4 启用 Guest Management

确认 Guest Agent 状态为 Connected 后执行：

az stack-hci-vm update \\
–name "mylocal-vm" \\
–enable-agent true \\
–resource-group "mylocal-rg"

等待若干分钟后验证。

§4.1.5 门户验证

Azure Local → Virtual machines → 选择 VM → Overview → Properties → Configuration → Guest management 应显示 Enabled (Connected)。

§4.1.6 不支持 Guest Management 的情形

按官方文档：

• Windows Server 2012 / 2012 R2（缺 Hyper-V sockets 支持）；
• 不支持 Hyper-V sockets 的任何 Guest OS。

§4.2 全生命周期管理能力

按 manage-arc-virtual-machines 文档，口径覆盖 VM 全生命周期操作：

§4.3 三层依赖速查：平台层 / Azure 资源层 / Arc 扩展层

与 §1.5 呼应，本节是 §1.5 的运营视角速查版。按"管理动作 → 属于哪一层依赖"组织——而不是简单地二分"依赖 vs 不依赖"。三层定义为：

• 平台层：Azure Local 平台的本地能力（Hyper-V / FC / WAC / PowerShell）

• Azure 资源层：通过 Arc Resource Bridge + Custom Location + mocguestagent 实现的 Azure 端可见性 / 治理

• Arc 扩展层：通过 Azure Connected Machine Agent 实现的 Guest OS 内 Azure 扩展执行

关键阅读提示：

§4.4 已知限制与 FAQ 速查

本节汇总 FAQ 与 overview 中的官方表述，按"客户最关心"维度组织。

§4.4.1 资源与生命周期限制

• 仅 IPv4：Azure Local VM 不支持 IPv6 地址；
• Logical Network 字段不可改：Default gateway / IP pools / IP address space / VLAN ID / Virtual switch name 均不可改；
• 资源组不可移动：Azure Local VM 及其关联资源（NIC / Disk 等）不支持跨资源组移动；
• VM 内部或本地工具改动不反映到 Azure：通过 VM 内部或本地工具修改的 IP、数据盘配置等不会同步到 Azure 资源视图；
• VM 克隆 / 复制不支持：当前不支持 VM cloning 或 VM copying；
• 逻辑网络 DNS / Gateway IP 不能作为 VM IP：Logical Network 上配置的 DNS 服务器 IP 与 Gateway IP 不能用于 VM。

§4.4.2 操作系统与镜像限制

• Windows Server 2012 / 2012 R2：仅 CLI 创建路径可用，不支持 Guest Management；
• VM Image 必须 en-us 语言；
• Trusted Launch 仅支持部分 Marketplace 镜像：自定义镜像在 Trusted Launch 下不启用 Guest Attestation；
• Disconnected Operations 仅支持本地共享镜像：Marketplace / Azure Storage Account 镜像在 Disconnected 模式下不可用。

§4.4.3 网络与 SDN 限制

• SDN 不支持 Azure Portal 创建的 VM：SDN 在 Azure Local 上的能力详见 SDN 技术参考；
• Trusted Launch 实时迁移流量默认不加密：强烈建议部署 IPsec 等网络层加密。

§4.4.4 Azure Arc 资源桥（Arc Resource Bridge）相关

• 不应删除：除非重新镜像或下线整个 Azure Local 实例；
• 删除顺序：先删工作负载资源 → 再 Arc resource bridge → 最后 Custom Location；
• 删除 Arc resource bridge 会丢失 Azure 控制平面（但不影响本地工作负载，仍可通过 WAC / Hyper-V / PowerShell 访问）；
• 删除 Image 不会删除已部署的 VM；
• 更新 Image 不会影响已创建的 VM——VM 创建时拷贝 Image。

§4.4.5 计费相关

• Azure Local VM 管理（Portal / CLI）不收费；
• 部分 VM 扩展可能收费——按当期微软计费说明；
• Azure Update Manager 更新 Azure Local VM 不收费；
• 独立启用 Arc 的服务器（非 Azure Local VM 体系创建）按 Azure Arc-enabled servers 标准收费。

§4.4.6 "官方没说的"事项

按本文写作纪律——官方没写的，不要写——以下事项本文不妄言：

• 不同 azloc 版本之间的具体功能差异（以当期微软官方文档为准）；
• Arc resource bridge 的 HA 节点数（具体以当期 OEM Support Matrix 与官方文档为准）；
• 任何具体的 VM 数量上限（按当期文档表述随版本演进变化）；
• 任何具体的网络性能 / IOPS 数字（按当期 OEM Support Matrix 与官方文档为准）；
• 任何"412%" / "13%" 等未官方权威的量化数字。

§4.5 责任边界——三方角色

这是企业实施过程中容易模糊的最后一节。按照"三层原则（官方硬要求 / 工具默认 / 企业最佳实践）+ 微软推荐 ≠ 微软强制"的口径整理。

§4.4.6 Azure RBAC 控制对象的精确范围（常被误解）

上一节"双栏速查"里的 "Azure RBAC 控制 VM" 容易让读者误以为 RBAC 可以控制 Guest OS 内的应用权限。这一节单独点明 RBAC 的精确控制对象。

典型误解：

• ❌ "我给 VM 分配了 Owner 角色，我可以登录 Guest OS"——错。Owner 角色控制的是 Azure 侧资源操作（删除 VM、修改 VM 配置等），不提供 Guest OS 登录能力。
• ✅ 想登录 Guest OS：需 Guest OS 内的本地账号 / AD Domain 账号——与 Azure RBAC 完全无关。

Azure RBAC 控制的是 ARM Resource，不是 Guest OS——这是 §1.5 / §4.3 双栏速查里 "Azure RBAC 控制 VM" 一栏的精确说法。

§4.4.7Guest Management 与 Connected Machine Agent 的精确区分（常被等同）

§1.6 已经从 "Agent 维度" 区分。本节从 "Guest Management 概念维度" 再强调一次——这是 §1.6 的补充视角。

很多企业实施过程中把 Guest Management 与 Azure Connected Machine Agent 等同。这是一种简化——并不完全准确：

关系图：

这意味着：

• ✅ "禁用 Guest Management" ＝ Connected Machine Agent 不安装 + 不下发任何 Guest VM Extensions
• ⚠️ 但 "Agent 进程已安装" ≠ "Guest Management Enabled"——例如 WS2012 / WS2012 R2 上 Connected Machine Agent 可手动安装（理论上），但 Guest Management 这个 Azure 侧配置项的状态仍受 Azure Local 平台侧管控
• ⚠️ "Guest Management 已启用" ≠ "Azure 端看到 Guest OS 完整状态"——还依赖 Agent 实际心跳 / 已上报遥测

一句话："Guest Management 是一个 Azure 侧配置项 / 一个能力集合；Connected Machine Agent 是其中一个 Agent 进程——把两者等同会丢失 Azure VM Extensions 与 Arc Integration 这两块内容。"

§4.5.1 三方角色分工

§4.5.2 实施建议（推荐，非强制）

§4.6 术语速查

§4.7 本章小结

• Guest Management 默认启用；异常状态可按 Connecting / null 两种情形恢复；
• 实时迁移只能通过本地工具（FCM / WAC）；Azure Local VM 的 VM storage live migration 不支持；
• 不依赖 Arc 的能力与依赖 Arc 的能力泾渭分明——运营时可按 §4.3 速查对照；
• "微软推荐 ≠ 微软强制"，实施建议用"推荐 / 建议"措辞，而非"必须 / 不能"；
• 责任边界按三角色（微软 / OEM / 客户）分配。
• 本篇文章与博客内一篇文章内容上有一些重复，是修订的另外一个版本。

附录 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：版本与原则说明

• 文档版本基线：本文对应微软官方文档 azloc-2606（2026 年 6 月），对版本相关的具体数字、限制、能力范围，以当期微软官方文档为准。
• 三层原则：本文对"必须 / 不能"措辞仅用于微软官方硬要求；对 Portal / 工具默认行为用"默认"；对企业最佳实践用"建议 / 推荐"。

文档维护说明：本文对应微软官方文档版本 azloc-2606（2026 年 6 月）；本文不替代微软官方文档，仅作为企业架构师评估与实施 Azure Local VM 时的中文参考材料。