Azure Local VM 创建与管理架构详解:从 ARM Resource Model 到本地 Hyper-V 工作负载部署
副标题:从 5 种创建路径到 6 个特殊选项——动手创建 Azure Local VM 的完整实操指引
本篇 TL;DR:Azure Local VM 在 Azure 侧是ARM Resource(类型
Microsoft.AzureStackHCI/virtualMachineInstances,以及virtualMachines/virtualHardDisks/networkInterfaces/storagecontainers/galleryImages等关联 Resource),通过 5 种创建路径(Portal / CLI / ARM / Bicep / Terraform)把请求通过 Custom Location 路由到本地 Arc Resource Bridge,再通过 Azure Local VM Management Stack 实现 VM 创建。本篇覆盖通用参数、5 种路径的适用场景、Trusted Launch / VM Placement / GPU Assignment / 动态内存 / Windows Server 2012 等特殊选项的处理方式。
文档基线:参考 Azure Local2506(2025 年 6 月)/ 2510(2025 年 10 月)文档体系(内部整理版本 v1.3.x);细节以当期官方文档为准。
本篇全局视图
本篇承接篇 1 准备好的四前置资源,从 Azure CLI 路径讲起,覆盖 5 种创建路径的适用场景与差异;Trusted Launch / VM Placement / GPU Assignment / 动态内存 / Windows Server 2012 五个特殊选项单独展开。
§3 创建 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(后者由
Microsoft.Compute/virtualMachines表示,运行在 Azure 数据中心的 Hyper-V 上)。
§3.0.1 Resource Model
Azure Local VM 的 Resource Model 是一族并列资源(Microsoft.AzureStackHCInamespace),不是"父子"包含关系:
Microsoft.AzureStackHCI Resource Types (并列 Resource 类型,不表示 ARM 父子层级关系) │ ├── virtualMachineInstances │ Azure Local VM Instance 管理入口 │ ├── virtualMachines │ VM 配置相关 Resource │ ├── virtualHardDisks │ Disk Resource (OS Disk / Data Disk) │ ├── networkInterfaces │ NIC Resource │ ├── storageContainers │ Storage Path / Storage Container Resource │ ├── galleryImages │ Marketplace Gallery Image Resource │ └── marketplaceGalleryImages VM Image Resource关键提醒:上述 Resource 类型属于同一 namespace 下的并列资源,不表示 ARM 父子层级关系——
virtualMachines不是virtualMachineInstances的子资源,virtualHardDisks也不是 VM 的"磁盘子资源"。
Resource 类型 | 角色 |
| 用户主要管理入口——5 种创建路径(Portal/CLI/ARM/Bicep/Terraform)都操作此资源 |
| VM 配置模型 Resource 类型,用于描述 Azure Local VM 的配置定义信息;实际 VM 实例生命周期管理主要通过 virtualMachineInstances 完成。 |
| 描述 VM 的磁盘(OS Disk / Data Disk) |
| 描述 VM 的 NIC |
| 描述 VM 使用的 Storage Path / Container |
| Marketplace Gallery Image |
关键认知:Azure Local VM不是"Azure VM + 本地运行"——它的 Resource Model 与
Microsoft.Compute/virtualMachines(Azure 数据中心 VM)是两条独立的资源体系:
- Azure VM:
Microsoft.Compute/virtualMachines—— 运行在 Azure 数据中心 Hyper-V
- Azure Local VM:
Microsoft.AzureStackHCI/virtualMachineInstances—— 运行在客户数据中心的 Azure Local 集群两条资源体系不能混用——Azure Portal / CLI 不能用
az vm create创建 Azure Local VM,反之亦然。Azure Local VM Resource Model 与 Azure VM Resource Model 不同,不应直接类比
Microsoft.Compute/virtualMachines(包括父子结构 / 控制平面 / InstanceView 等)。
§3.0.2 术语精确化
- Microsoft 官方未使用 "First-class Resource" 描述 Azure Local VM——微软对 Azure Local VM 的官方表述接近"Azure 资源 / ARM Resource";社区有时会用"first-class resource"等说法,但 Microsoft Learn / Azure 官方文档不这样描述,本文沿用微软 "Azure 资源 / ARM Resource" 表述,不使用 first-class 等社区化叫法(避免被引用扩散为微软术语)
- 资源所在 region:与 Azure Local 实例所在的 region 一致(详见 §2.2.1)
- 跨订阅 / 跨资源组约束:Azure Local VM 及其关联资源(NIC / Image / Storage Path / Data Disk)不支持跨资源组移动——ARM 层限制
理解这点的意义:
- 第一次出现用全称:Azure Local VM management layer是本文用于描述 Azure Local VM 管理组件集合的简称,完整组件包括 Arc Resource Bridge、MOC、VM Operator、Resource Providers、
mocguestagent等。
- 后续统一简称:Azure Local VM management或Azure Local VM management layer。
- 不使用 "Azure Local VM Management Stack" 作为产品名称——避免被读者理解为微软官方产品名称。
- 微软公开文档常用说法:Azure Local VM management/Azure Local VM management service/Azure Local VM management components;本文沿用微软措辞。
- 从 Azure 端操作 Azure Local VM(无论是 Portal / CLI / ARM 模板 / Bicep / Terraform)都是针对一个ARM Resource发请求;ARM 把请求通过 Custom Location 路由到本地 Arc Resource Bridge,由 Arc Resource Bridge 上的 VM management 扩展调用 Azure Local VM management layer(MOC + VM Operator + Resource Providers)执行 VM 生命周期,最终落到本地 Hyper-V / Failover Cluster。完整链路见 §3.7.1。
§3.1 五种创建路径对比
按 官方文档 口径,Azure Local VM 支持 5 种创建路径:
路径 | 适用场景 | 前置资源强制项 | 自动化能力 |
Azure Portal | 一次性创建、图形化、探索性 | RBAC + Image + Custom Location | 单次操作 |
Azure CLI | 脚本化、CI/CD、调试 | RBAC + Image + Custom Location + | 高 |
ARM 模板 | 跨环境复用、标准化部署 | RBAC + Image + Custom Location +网络配置资源(Logical Network / NIC / IP Pool 任一,不强制单一形式) + ARM 模板 | 高(声明式) |
Bicep 模板 | 类型安全 IaC、模块化 | RBAC + Image + Custom Location +网络配置资源(Logical Network / NIC / IP Pool 任一) + Bicep 模板 | 高(声明式 + 类型安全) |
Terraform | 多云一致 IaC、与现有 Terraform 工作流集成 | RBAC + Image + Custom Location +网络配置资源+ Terraform + Git | 高(声明式 + 状态管理) |
本文中的“创建 Azure Local VM”指通过 Azure Resource Manager 创建和配置 Azure Local VM Resource,并由 Azure Local 平台组件在本地基础设施中完成实际虚拟机实例部署,而不是在 Azure 公有云区域创建 Azure VM。
§3.1.1 如何选择 5 种创建路径
有读者反馈:"5 种路径并列陈列,新手不容易判断该用哪一种"。下表给出企业典型场景 → 推荐路径的决策指引:
企业场景 | 推荐路径 | 理由 |
探索性 / PoC / 单次创建 | Azure Portal | 图形化,无脚本成本 |
运维脚本 / 一次性迁移 | Azure CLI | 可脚本化、可调试、即时反馈 |
跨环境复用 / 模块化 IaC | ARM / Bicep 模板 | 声明式 + Azure 原生类型安全 |
多云一致 IaC / 已有 Terraform 工作流 | Terraform | 复用现有 Terraform 状态管理 |
CI/CD 流水线集成 | Bicep + az CLI或Terraform + azurerm provider | 取决于团队 IaC 标准 |
大规模并行多 VM 创建 | ARM / Bicep 模板 + | 声明式资源编排 |
与企业 CMDB / 资产系统集成 | ARM / Bicep 模板 | 模板可纳入版本控制 / 审批流 |
核心原则:探索用 Portal,单次用 CLI,正式环境用 ARM / Bicep / Terraform 三选一(取决于团队 IaC 标准)。不要把 Portal 用于生产环境的大规模部署——它不具备脚本化与版本控制能力。
§3.1.2 创建路径能力矩阵
能力 | Portal | CLI | ARM | Bicep | Terraform |
人工操作 / 探索性 | ★★★★★ | ★★★ | ★ | ★ | ★ |
版本管理 / 模板复用 | ★ | ★★ | ★★★★ | ★★★★★ | ★★★★★ |
CI/CD 集成 | ★ | ★★★★ | ★★★★ | ★★★★★ | ★★★★ |
多云一致 | ★ | ★ | ★ | ★ | ★★★★★ |
微软官方示例丰富度 | ★★★★ | ★★★★ | ★★★★ | ★★★★ | ★★★ |
状态管理 / 增量部署 | — | — | ★★★★ (ARM | ★★★★ | ★★★★★ |
矩阵使用建议:
- ★★★★★ 推荐使用——表示该能力在该路径上具有明显优势
- ★ 勉强可用——表示该路径可以做到但不是最佳选择
- — 不适用——该路径上无对应能力
这条矩阵只描述能力倾向,不是绝对打分——实际选择要结合团队既有技术栈、CI/CD 标准与运维习惯。
§3.2 通用参数
不管走哪条路径,Azure Local VM 创建时的参数集合大体相同。按 官方文档 表格:
参数 | 含义 | 备注 |
| VM 名称 | 遵循 Azure 资源命名规则 |
| 客户机凭证 | 按 Azure 资源命名规则 |
| 镜像引用 | Image Resource ID 或名称 |
| Azure Resource Manager 中资源所属 Region | 通常与 Azure Local 实例注册的 Region 保持一致(如 Azure Local instance 在 Japan East 注册,VM ARM Resource location 也使用 Japan East) |
| 资源组 | 建议与 Azure Local 实例同组 |
| Azure Subscription ID(资源所属订阅) | 不涉及 Region——Azure Subscription 本身没有Region 属性;Subscription 选定后, |
subscription / location / Azure Local VM 关系(v1.3.8 补充):
- subscription: 资源归属 Azure Subscription
- location: ARM Resource metadata 中声明的 Region
- Azure Local VM:
location必须匹配 Azure Local instance 注册 Region
§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(安全启动) | 启用 UEFI 安全启动链 | 防止 Guest OS 启动阶段被 rootkit 注入 |
vTPM(虚拟 TPM) | 在 Hypervisor 层提供虚拟 TPM 2.0 芯片 | 提供硬件级密钥存储、BitLocker 支持、Attestation |
Measured Boot(度量启动) | 启动链上每个组件的 hash 上报 | 可在云端验证启动完整性 |
BitLocker 支持 | 通过 vTPM 实现 | Guest OS 内的 BitLocker 自动启用 |
安全能力组成(v1.3.7 精确化):Azure Local VM Trusted Launch 是 Azure Local VM 的一个安全类型(securityType: "TrustedLaunch"),在创建时通过
--security-type "TrustedLaunch"参数显式启用——它的实现依赖安全类型,而不是用户手工组合 Secure Boot 与 vTPM 两个开关。Trusted Launch 安全类型包含 Secure Boot 与 vTPM 等多项安全能力。具体安全能力集合、组合方式与版本支持以当期 Azure Local 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 # 应返回 TrustedLaunchTrusted Launch 关键运营约束(按 trusted-launch-vm-overview):
约束 | 说明 |
Trusted Launch VM Guest State Protection Key(本文简称Guest State Key) | Trusted Launch VM 的恢复依赖 Guest State Protection 相关密钥材料,需要按照当前 Azure Local 文档要求进行保存和管理。 |
实时迁移加密 | 实时迁移网络默认不加密,强烈建议使用 IPsec 等网络层加密 |
备份策略 | 备份所有 VM 文件 + VM Guest State Protection Key |
跨实例恢复 | Trusted Launch VM 恢复到不同 Azure Local 实例后,不再归 Azure Arc 控制平面管理,只能通过本地工具管理 |
Guest Attestation | 自定义镜像因未验证,不会启用 Guest Attestation |
VM 克隆 / 复制 | 不支持(会导致管理错误或启动失败) |
§3.3.5 VM Placement(亲和性 / 反亲和性 / 故障域)
VM Placement是 Azure Local VM 的调度约束机制,可用于优化高可用设计——许多企业在生产环境中关心"哪些 VM 应该共置 / 哪些 VM 应该分散"。按 官方 VM placement overview 文档,Azure Local VM 支持以下放置策略:
放置策略 | 用途 |
Affinity(亲和性) | 通过 placement constraint使相关 VM 尽量或必须部署到相同故障域 / 节点范围——具体强度取决于策略类型( |
Anti-affinity(反亲和性) | 根据Placement Constraint将相关 VM调度到不同节点 / 故障域—— |
Placement(自定义放置) | 把多个 VM显式指定到不同节点 / 特定硬件域;具体支持范围以当期 Azure Local VM Placement 文档为准 |
控制平面 | 说明 |
配置粒度 | 取决于 Azure Local 版本和 Placement Constraint 支持模型,例如节点、Fault Domain 等 |
故障域(Fault Domain) | Azure Local 通过 Rack Awareness 抽象的硬件拓扑域(rack / chassis / 节点)——VM Placement 可按 Fault Domain 配置 |
生产建议:关键应用的多实例(如 Web Farm、SQL AlwaysOn AG)的默认部署策略通常会配置Anti-affinity 跨节点 + 跨 Fault Domain——降低单硬件故障导致整组不可用的概率。具体配置粒度(节点 / Fault Domain / 集群层)、命名约束、与 OEM 集群拓扑的兼容性约束以当期 Azure Local 官方 VM Placement 文档为准。
详细参数与配置示例见 官方 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。
能力依赖(v1.3.7 补充):动态内存能力依赖 Guest OS 支持以及 Hyper-V Dynamic Memory 支持矩阵——并非所有 Guest OS 版本均启用 Dynamic Memory;具体支持范围以当期 Azure Local + Hyper-V 文档为准。
§3.3.7 GPU Assignment
§3.3.7.1 GPU 工作模式概览
Azure Local VM 上的 GPU 工作负载按虚拟化机制分为若干模式。具体可用模式、卡型、partition 数、显存配置以当期 GPU 厂商 / Azure Local 版本 / OEM Support Matrix 为准:
模式 | 底层机制 | 适用场景 | 硬件 / 软件依赖 |
DDA(Discrete Device Assignment) | Hyper-V PCIe Device Passthrough(把整个 PCIe 设备分配给单 VM)不依赖 SR-IOV | 高性能计算、深度学习训练、推理 | 支持 PCIe 直通的 GPU + Hyper-V DDA 能力 |
GPU Partition(GPU-P) | Hyper-V GPU Partitioning(Windows Server GPU-P) | VDI、虚拟桌面、多 VM 推理 | 支持 GPU Partitioning 的 GPU + 厂商驱动;GPU-P 与 NVIDIA vGPU 是不同技术栈——GPU-P 是 Windows Hyper-V 平台层能力;NVIDIA vGPU 是 NVIDIA 商业虚拟化方案(需授权 driver + license server) |
MIG(Multi-Instance GPU) | NVIDIA 硬件级 MIG(GPU 硬件层切分) | 数据中心级硬件隔离 | 仅 NVIDIA A100 / H100 等支持的 GPU;Azure Local VM management不提供统一 MIG 生命周期编排 |
§3.3.7.2 模式机制差异(v1.3.6 重写)
- DDA:Hyper-V 通过 PCIe Device Passthrough(VM 直接访问 PCIe 设备)把整块 GPU 分配给单 VM。
- 不依赖 SR-IOV——SR-IOV 是 PCIe 设备的单根 I/O 虚拟化技术,Hyper-V DDA 是 PCIe 设备整体直通,机制不同。
- 单 VM 独占整块 GPU 资源——按 Hyper-V DDA 的硬件直通特性,相对 GPU-P / MIG 模式通常表现为更低的虚拟化层开销(具体开销因 GPU 型号 / 负载类型 / driver 版本而异,以当期实测为准),但单 VM 占用整块 GPU。
- GPU-P:Windows Server / Azure Local 的 Hyper-V GPU Partitioning——由 Hypervisor 调度引擎把 GPU 资源划分为多个 partition,每个 VM 可获得一个 partition。
- GPU-P 不等于 NVIDIA vGPU——NVIDIA vGPU 是 NVIDIA 的商业 GPU 虚拟化方案,需授权 driver 与 license server;Azure Local 的 Hyper-V GPU Partitioning 是平台层机制,可在不同 GPU 厂商上工作。
- 调度粒度(时间分片 / 显存隔离 / 引擎调度等)由 Hyper-V 调度引擎与厂商驱动共同决定,不是纯软件层的 vGPU。
- MIG:NVIDIA 数据中心 GPU 的硬件级 MIG——通过 GPU 硬件自身切分为多个 GPU 实例。
- 是否可用取决于 GPU 型号、驱动模式以及 OEM 支持矩阵;Azure Local VM management 本身不提供统一的 MIG 生命周期编排——如需 MIG,需通过 DDA 把 GPU 直通给 VM 后,在 Guest OS 内手动配置 MIG 实例。
§3.3.7.3 配置示例(GPU-P 模式,v1.3.6 重写)
# 1. 在 Azure Local Host 上启用 GPU-P(按 Windows Admin Center / PowerShell 流程) # 2. 通过 Azure CLI 在 VM 创建时指定 partition az stack-hci-vm create \ --name "my-gpuvm" \ -g "my-rg" \ --custom-location "<customLocationID>" \ --location "<AzureLocalRegion>" \ --image "<imageResourceID>" \ --hardware-profile vm-size="Custom" processors=4 memory-mb=8192 \ --gpus "<gpu-partition-id>"具体支持的卡型、partition 数、显存配置、MIG 可用性、driver 与 license 模式——以当期 GPU 厂商 Support Matrix / OEM Azure Local Support Matrix / Azure Local 当期版本文档为准。本节给出的是机制性描述,不替代具体型号的兼容性列表。
§3.3.8 Windows Server 2012 / 2012 R2 特殊路径
- 通过 Azure Portal不支持;
- 仅能通过 Azure CLI 创建;
- 创建之后不支持启用 Guest Management——WS2012/2012R2 Guest不满足 Azure Local Guest Management 所需支持条件(Azure Local Guest Management 依赖 Azure Local Guest Agent 与 Guest OS 支持矩阵;Windows Server 2012/2012 R2 不在当前支持列表中,因此不能启用 Guest Management。);
- 额外 CLI 参数详见 官方文档对应小节。
§3.4 Azure Portal 路径
Portal 路径适合一次性创建与图形化探索:
- 进入Azure Local资源页;
- 选择Virtual machines→Create;
- Basics:选择订阅 / 资源组 / VM 名称 / Custom Location / VM 大小;
- Disks:按需添加数据盘(受 VM Size 限制);
- Networking:选择 Logical Network + NIC(可在此创建);
- Management:选择 Security Type(Standard / Trusted Launch);
- Advanced:配置 Guest OS 更新策略、时区等;
- Review + Create验证并创建。
Portal 路径与 Trusted Launch 的小陷阱:
按 FAQ 表述——Trusted Launch 在门户中仅显示其支持的镜像列表;不支持 Trusted Launch 的镜像(包括自定义镜像)在下拉列表中显示为空白。
§3.5 ARM 模板路径
示例 ARM 模板 可从 GitHub 快速启动模板库下载。
前置资源要求(v1.3.6):RBAC + Image + Custom Location +Network Configuration(Logical Network / NIC / IP Pool 任一;不强制单一形式)(ARM 路径强制)。
适用场景:跨环境复用、标准化部署、多资源一并部署。
§3.6 Bicep 模板路径
示例 Bicep 模板 在 ARM 模板基础上提供类型安全与模块化能力。
前置资源要求:与 ARM 模板一致。
适用场景:长期 IaC 演进、模块化复用、代码可读性优先。
§3.7 Terraform 路径
示例 Terraform 配置 在 azapi / azurerm providers 之上封装 Azure Local VM 资源。
前置资源要求(v1.3.6):RBAC + Image + Custom Location +Network Configuration(Logical Network / NIC / IP Pool 任一)+ Terraform + Git。
适用场景:多云一致 IaC、与现有 Terraform 工作流集成、状态管理需求。
§3.8 创建时的通用注意事项
按 官方文档 顶部 Note 提示:
- 临时 DVD / ISO 设备(v1.3.6 弱化数量描述):某些 Azure Local VM 创建流程可能临时生成DVD / ISO 设备用于加载安装介质;ISO 内容在创建成功后被移除,但部分Guest OS 可能仍可见空 DVD 设备——Windows VM 通过 Device Manager 卸载;Linux VM 按具体发行版处理。具体设备数量与存在与否依当期 Azure Local VM 创建流程与 Guest OS 类型而定。
- 跨资源组引用:当被引用的资源(Disk / NIC / Image / Storage Path)在不同资源组时,必须传递完整 Resource ID。
- 存储路径不指定时:Azure Local 自动将工作负载(VM / Image / 非 OS 数据盘)放在高可用存储路径。
- Guest Management 默认启用(v1.3.6 加 OS 限制):对支持的 Guest OS(排除 WS2012/2012R2 等不支持 Guest Management 的 Guest OS,见 §3.3.8),通过 Portal / CLI 创建 Azure Local VM 时默认启用Guest Management;不支持的 Guest OS不启用Guest Management,且不能创建后启用。如 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 OS默认启用 Guest Management(详见 §3.3.8 / §3.8);不支持的 Guest OS 不启用,且不能后续开启。
附录 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:版本与原则说明
- 三层原则:本文对"必须 / 不能"措辞仅用于微软官方硬要求;对 Portal / 工具默认行为用"默认";对企业最佳实践用"建议 / 推荐"。
- 不引用内部资料:本文不引用内部笔记、私人写作准则等内部积累材料;所有判断均以微软当期公开文档为准。
文档维护说明:本文对应 Azure Local
2506(2025 年 6 月发布) /2510(2025 年 10 月发布) 文档体系,本文维护版本 v1.3.5(2026 年 7 月);本文不替代微软官方文档,仅作为企业架构师评估与实施 Azure Local VM 时的中文参考材料。版本历史:
- v1.1:首版发表(2026 年 6 月)
- v1.3(本次修订):基于 ACP(Azure Community Partner)五轮反馈,对 Azure Arc 依赖关系精确化、平台架构分层、Trusted Launch / VM Placement / GPU Assignment 等补充内容做了系统性升级;详见 v1.3 修订记录。