Azure Local VM 创建与管理架构详解：从 ARM Resource Model 到本地 Hyper-V 工作负载部署

XUHUOJUN2026-07-21 10:47

副标题：从 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 Local 2506（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.AzureStackHCI namespace),不是"父子"包含关系:

复制代码 
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 类型 | 角色 |
| Microsoft.AzureStackHCI/virtualMachineInstances | 用户主要管理入口------5 种创建路径(Portal/CLI/ARM/Bicep/Terraform)都操作此资源 |
| Microsoft.AzureStackHCI/virtualMachines | VM 配置模型 Resource 类型，用于描述 Azure Local VM 的配置定义信息；实际 VM 实例生命周期管理主要通过 virtualMachineInstances 完成。 |
| Microsoft.AzureStackHCI/virtualHardDisks | 描述 VM 的磁盘(OS Disk / Data Disk) |
| Microsoft.AzureStackHCI/networkInterfaces | 描述 VM 的 NIC |
| Microsoft.AzureStackHCI/storageContainers | 描述 VM 使用的 Storage Path / Container |
| Microsoft.AzureStackHCI/galleryImages / marketplaceGalleryImages | 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 + az stack-hci-vm CLI 扩展 + 网络配置资源(可引用已有 NIC / 创建新 NIC / 使用 Logical Network + IP Pool) | 高 |
| 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 模板 + copy 循环 或 Terraform count / for_each | 声明式资源编排 |
| 与企业 CMDB / 资产系统集成 | ARM / Bicep 模板 | 模板可纳入版本控制 / 审批流 |

核心原则 ：探索用 Portal，单次用 CLI，正式环境用 ARM / Bicep / Terraform 三选一（取决于团队 IaC 标准）。不要 把 Portal 用于生产环境的大规模部署------它不具备脚本化与版本控制能力。

§3.1.2 创建路径能力矩阵

|-----------------|------------|---------|----------------------|-----------|---------------|
| 能力 | Portal | CLI | ARM | Bicep | Terraform |
| 人工操作 / 探索性 | ★★★★★ | ★★★ | ★ | ★ | ★ |
| 版本管理 / 模板复用 | ★ | ★★ | ★★★★ | ★★★★★ | ★★★★★ |
| CI/CD 集成 | ★ | ★★★★ | ★★★★ | ★★★★★ | ★★★★ |
| 多云一致 | ★ | ★ | ★ | ★ | ★★★★★ |
| 微软官方示例丰富度 | ★★★★ | ★★★★ | ★★★★ | ★★★★ | ★★★ |
| 状态管理 / 增量部署 | --- | --- | ★★★★ (ARM what-if) | ★★★★ | ★★★★★ |

矩阵使用建议:

  • ★★★★★ 推荐使用------表示该能力在该路径上具有明显优势
  • ★ 勉强可用------表示该路径可以做到但不是最佳选择
  • --- 不适用------该路径上无对应能力

这条矩阵只描述能力倾向,不是绝对打分------实际选择要结合团队既有技术栈、CI/CD 标准与运维习惯。

§3.2 通用参数

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

|-------------------------------------|-----------------------------------------|-----------------------------------------------------------------------------------------------------------------------------------------------|
| 参数 | 含义 | 备注 |
| name | VM 名称 | 遵循 Azure 资源命名规则 |
| admin-username / admin-password | 客户机凭证 | 按 Azure 资源命名规则 |
| image / image-name | 镜像引用 | Image Resource ID 或名称 |
| location | Azure Resource Manager 中资源所属 Region | 通常与 Azure Local 实例注册的 Region 保持一致(如 Azure Local instance 在 Japan East 注册,VM ARM Resource location 也使用 Japan East) |
| resource-group | 资源组 | 建议与 Azure Local 实例同组 |
| subscription | Azure Subscription ID(资源所属订阅) | 不涉及 Region ------Azure Subscription 本身没有 Region 属性;Subscription 选定后,location 字段决定资源所属 Region |

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
# 应返回 TrustedLaunch

Trusted 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 尽量或必须部署到相同故障域 / 节点范围 ------具体强度取决于策略类型（preferred / required）,而非永远 hard binding;适用低延迟通信场景（数据库主备） |
| Anti-affinity（反亲和性） | 根据 Placement Constraint 将相关 VM 调度到不同节点 / 故障域 ------preferred / required 控制调度强度;适用同一应用多实例,降低单点故障风险 |
| 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 路径适合一次性创建与图形化探索：

  1. 进入 Azure Local 资源页；
  2. 选择 Virtual machines → Create；
  3. Basics：选择订阅 / 资源组 / VM 名称 / Custom Location / VM 大小；
  4. Disks：按需添加数据盘（受 VM Size 限制）；
  5. Networking：选择 Logical Network + NIC（可在此创建）；
  6. Management：选择 Security Type（Standard / Trusted Launch）；
  7. Advanced：配置 Guest OS 更新策略、时区等；
  8. 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：参考链接

附录 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 修订记录。
相关推荐
zx1154509 小时前
Java 反射 (SpringBoot篇)
java·架构
她的男孩9 小时前
低代码只能做单表 CRUD？我们一行代码没写，搭了个完整进销存
java·后端·架构
jctech9 小时前
让「小程序」跑起真正的原生代码：ComboNative 多进程原生小程序运行时 · Alpha 首发
android·设计模式·架构
黄焖鸡能干四碗9 小时前
IT数据架构规划设计方案（PPT文件）
大数据·网络·数据库·人工智能·架构·区块链
●VON9 小时前
鸿蒙 PC Markdown 编辑器性能工程：中文输入与 10MiB 文档
华为·架构·编辑器·harmonyos·鸿蒙
禅思院10 小时前
Agent记忆管理，是一场工程上的平衡艺术
前端·架构·ai编程
o52788318410 小时前
校园一体化管理系统2.1、基于整洁四层架构 + DDD+CQRS 项目目录解读
后端·架构·c#·asp.net·visual studio
heimeiyingwang1 天前
【架构实战】异步化改造：线程池与消息队列的取舍
架构
Mr.HeBoYan1 天前
一次持续三天才出现的丢包故障——深入解析 DPDK Memory Ordering、rte_ring 与 CPU Memory Barrier （下）
linux·网络·算法·架构·dpdk
热门推荐
012026年7月AI圈大地震：GPT-5.6被政府限制、Claude入驻Slack、Anthropic自研芯片02GitHub 镜像站点03如何新建文件夹？ 电脑新建文件夹的4种方法04AI科技热点日报 | 2026年07月01日05幻兽帕鲁 - 服务器管理员权限与 GM 命令完全指南06国内可直接用、免费额度/永久免费的大模型API清单（含 SiliconFlow、火山、阿里、智谱、百度、Kimi、DeepSeek、DMXAPI 等）07【AI前线观察】2026年国产开源大模型全面横评：从 DeepSeek V4 到 Kimi K3，谁才是开发者的最优选择？08AI 编程 IDE 全景解析 2026：Agent 全面接管开发链路092026 年 AI 大模型 & AI 编程工具实战全总结102026 国产 AI 大模型横评：DeepSeek、通义千问、Kimi、文心一言、星火、豆包谁更能打？