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

副标题从 5 种创建路径到 6 个特殊选项——动手创建 Azure Local VM 的完整实操指引本篇 TL;DRAzure 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 Local25062025 年 6 月/ 25102025 年 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 ModelAzure 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 类型角色Microsoft.AzureStackHCI/virtualMachineInstances用户主要管理入口——5 种创建路径(Portal/CLI/ARM/Bicep/Terraform)都操作此资源Microsoft.AzureStackHCI/virtualMachinesVM 配置模型 Resource 类型用于描述 Azure Local VM 的配置定义信息实际 VM 实例生命周期管理主要通过 virtualMachineInstances 完成。Microsoft.AzureStackHCI/virtualHardDisks描述 VM 的磁盘(OS Disk / Data Disk)Microsoft.AzureStackHCI/networkInterfaces描述 VM 的 NICMicrosoft.AzureStackHCI/storageContainers描述 VM 使用的 Storage Path / ContainerMicrosoft.AzureStackHCI/galleryImages/marketplaceGalleryImagesMarketplace Gallery Image关键认知:Azure Local VM不是Azure VM 本地运行——它的 Resource Model 与Microsoft.Compute/virtualMachines(Azure 数据中心 VM)是两条独立的资源体系:Azure VM:Microsoft.Compute/virtualMachines—— 运行在 Azure 数据中心 Hyper-VAzure 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-vmCLI 扩展网络配置资源(可引用已有 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可脚本化、可调试、即时反馈跨环境复用 / 模块化 IaCARM / Bicep 模板声明式 Azure 原生类型安全多云一致 IaC / 已有 Terraform 工作流Terraform复用现有 Terraform 状态管理CI/CD 流水线集成Bicep az CLI或Terraform azurerm provider取决于团队 IaC 标准大规模并行多 VM 创建ARM / Bicep 模板 copy循环或Terraformcount/for_each声明式资源编排与企业 CMDB / 资产系统集成ARM / Bicep 模板模板可纳入版本控制 / 审批流核心原则探索用 Portal单次用 CLI正式环境用 ARM / Bicep / Terraform 三选一取决于团队 IaC 标准。不要把 Portal 用于生产环境的大规模部署——它不具备脚本化与版本控制能力。§3.1.2 创建路径能力矩阵能力PortalCLIARMBicepTerraform人工操作 / 探索性★★★★★★★★★★★版本管理 / 模板复用★★★★★★★★★★★★★★★★★CI/CD 集成★★★★★★★★★★★★★★★★★★多云一致★★★★★★★★★微软官方示例丰富度★★★★★★★★★★★★★★★★★★★状态管理 / 增量部署——★★★★ (ARMwhat-if)★★★★★★★★★矩阵使用建议:★★★★★ 推荐使用——表示该能力在该路径上具有明显优势★ 勉强可用——表示该路径可以做到但不是最佳选择— 不适用——该路径上无对应能力这条矩阵只描述能力倾向,不是绝对打分——实际选择要结合团队既有技术栈、CI/CD 标准与运维习惯。§3.2 通用参数不管走哪条路径Azure Local VM 创建时的参数集合大体相同。按 官方文档 表格参数含义备注nameVM 名称遵循 Azure 资源命名规则admin-username/admin-password客户机凭证按 Azure 资源命名规则image/image-name镜像引用Image Resource ID 或名称locationAzure Resource Manager 中资源所属 Region通常与 Azure Local 实例注册的 Region 保持一致(如 Azure Local instance 在 Japan East 注册,VM ARM Resource location 也使用 Japan East)resource-group资源组建议与 Azure Local 实例同组subscriptionAzure Subscription ID(资源所属订阅)不涉及 Region——Azure Subscription 本身没有Region 属性;Subscription 选定后,location字段决定资源所属 Regionsubscription / location / Azure Local VM 关系(v1.3.8 补充):subscription: 资源归属 Azure Subscriptionlocation: ARM Resource metadata 中声明的 RegionAzure 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 创建标准 VMaz 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-mb8192 processors4 \ --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 支持、AttestationMeasured 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 VMTrusted Launch 是一种安全类型——创建命令需显式指定--security-type TrustedLaunchaz 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-mb8192 processors4 \ --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 AttestationVM 克隆 / 复制不支持会导致管理错误或启动失败§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 DomainAzure 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-sizeCustom processors1 \ memory-mb1024 \ maximum-memory-mb2048 \ minimum-memory-mb1024 \ target-memory-buffer20 \ --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-sizeCustom processors4 memory-mb8192 \ --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→CreateBasics选择订阅 / 资源组 / VM 名称 / Custom Location / VM 大小Disks按需添加数据盘受 VM Size 限制Networking选择 Logical Network NIC可在此创建Management选择 Security TypeStandard / Trusted LaunchAdvanced配置 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 ConfigurationLogical 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 ConfigurationLogical 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 ArcWhat is Azure Local VM managementAzure Local VM management prerequisitesManage Azure Local VMs enabled by Azure ArcAzure Local VMs Enabled by Azure Arc FAQOverview for Trusted launch for Azure Local VMs enabled by Azure ArcDisconnected operations with Azure Local VMs enabled by Azure ArcSystem requirements for Azure LocalRequired firewall URLs for Azure Local deploymentsAzure Arc resource bridge overviewRBAC 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 Local2506(2025 年 6 月发布) /2510(2025 年 10 月发布) 文档体系,本文维护版本 v1.3.5(2026 年 7 月);本文不替代微软官方文档,仅作为企业架构师评估与实施 Azure Local VM 时的中文参考材料。版本历史v1.1首版发表2026 年 6 月v1.3本次修订基于 ACPAzure Community Partner五轮反馈对 Azure Arc 依赖关系精确化、平台架构分层、Trusted Launch / VM Placement / GPU Assignment 等补充内容做了系统性升级详见 v1.3 修订记录。