Azure Local离线模式VM 管理（系列篇十二）

Azure Local VM 管理（离线 / Disconnected 模式）

文档体例说明：本节采用三栏组织------

✅ 官方要求（Official Requirement）------ 微软 Learn 原文支撑的事实

🔍 技术分析（Technical Analysis）------ 官方没明说但可从架构/脚本推断的原理

💡 企业最佳实践（Best Practice）------ 工程建议、风险提示、扩展性考量

关键架构分层（贯穿全文）：

Azure Local = HCI + Hyper-V + SDN 底座

Arc Resource Provider = Azure 控制面扩展

stack-hci-vm CLI extension = 管理 API 客户端（不是 runtime）

因此"Azure Local VM"严格说应是 "Azure Local Arc-enabled VM（通过 stack-hci-vm CLI / Arc API 调用）"。

0. 三层架构（理解整篇文档的入口）

关键边界：

CLI 不等于 runtime ------stack-hci-vm extension 只是 API 客户端

VM 不等于 Azure IaaS VM------HA/resize/migration 模型都是 Hyper-V 层语义

Portal 不等于 control plane------Portal 是 ARM façade

1. Guest OS 支持矩阵

✅ 官方要求

Azure Local VM 在 disconnected / Arc-enabled 场景下支持以下 Guest OS：

Windows Server 2019 / 2022 / 2025
Windows 10 / Windows 11 Enterprise（部分场景）
Ubuntu 20.04 / 22.04 / 24.04 LTS（取决于版本）

🔍 技术分析

Azure Local VM 基于 Hyper-V + Arc VM 管理平面。Guest OS 支持取决于：

Hyper-V Integration Services（集成服务）
Arc VM Agent 兼容性矩阵

Linux 并不"被禁止"，而是：

无 Azure 官方 image pipeline
需用户自建 VHDX（Gen2 + hv drivers）

关于 RHEL / SLES：

技术上可运行

但不在官方验证矩阵

Arc guest management 支持可能受限

💡 企业最佳实践

优先选择 ：
- Windows Server 2022 / 2025
- Ubuntu LTS（22.04 / 24.04）
RHEL / SLES 仅建议用于：
- 自建镜像
- 自主补丁体系
- 非强依赖 Arc guest management 的场景

2. VM 功能与限制清单

2.1 VM 镜像管理

✅ 官方要求

VM 镜像必须来源：

Cluster Shared Volume（CSV）
本地路径导入 VHD/VHDX

❌ 不支持：

Azure Marketplace
Azure Storage 直接挂载
远程 image streaming

🔍 技术分析

Azure Local VM 没有 ARM image pull capability
所有 image 必须：
- 本地 block storage 可访问
- Hyper-V compatible VHD/VHDX

💡 企业最佳实践

建立 内部 golden image library
标准化 VHDX pipeline（CI/CD）

2.2 网络与 NIC

✅ 官方要求

NIC 通过 CLI 创建
依赖 logical network（lnet）
IP 必须来自预定义 IP pool

🔍 技术分析

Arc VM networking 依赖 Azure Local SDN abstraction layer
Portal 支持有限 ：可查看，不适合复杂配置（static IP / custom logical network 基本仍依赖 CLI）

💡 企业最佳实践

网络全部 CLI IaC 化（Bicep / PowerShell / Terraform）
Portal 仅用于观测

2.3 Trusted Launch（安全启动）

✅ 官方要求

支持 Trusted Launch（视版本而定，Preview / GA depending version）
包括：
- Secure Boot（稳定支持）
- vTPM（支持）

🔍 技术分析（重要约束）

Trusted Launch 在 Azure Local：

✔ Secure Boot：稳定支持
✔ vTPM：支持
⚠ Measured Boot ：不等价 Azure public VM
⚠ Defender for Cloud attestation ：通常不可用（disconnected + Azure 端 attestation 链路不完整）

关键约束：

Trusted Launch 在 Azure Local 上主要用于本地 Hyper-V security enforcement，不等同 Azure IaaS VM 的完整 attestation pipeline。

也就是说------开了 Secure Boot + vTPM 不等于你获得了 Azure public cloud 那套 attestation / compliance report 能力。

💡 企业最佳实践

生产环境开启 Secure Boot + vTPM
安全审计仍需结合 ：
- 外部 SIEM
- Defender for Endpoint（Guest OS 内）
- 不依赖 Defender for Cloud attestation（不可用）

2.4 Proxy 行为

✅ 官方要求

VM 自身不提供 Azure 管理的 outbound proxy 功能
Azure Local 本地控制面 （Appliance / Arc Resource Bridge）支持且通常必须配置 Outbound Proxy（通过 FullEnvironment.json 或本地网络环境注入）

🔍 技术分析（关键区分）

|----------------------------------------|----------------|-----------------------------------------------------------------------|
| 层级 | 是否提供 proxy | 说明 |
| Azure 公有云控制面 | ❌ 不提供 | VM 跟公有云之间的 proxy 不归 Azure 管 |
| Azure Local 本地控制面（Appliance / ARB） | ✔ 支持 | 通过 FullEnvironment.json 或环境变量注入；仅在断网模式下关闭外发链路------组件本身具备代理感知能力 |
| Guest OS 网络 | ✔ 支持 | OS-level / transparent / NAT 随意 |

重要澄清：

之前表述 ❌ "Azure 控制面不提供 proxy" → 不准确

准确版本："Azure 公有云控制面（VM ↔ ARM）不提供 proxy"

Azure Local 本地控制面（Appliance ↔ Outbound）支持 proxy，仅在完全断网（True Disconnected）时才关闭外发链路

💡 企业最佳实践

VM ↔ Guest 外网 用：
- OS-level proxy
- Enterprise transparent proxy
- Firewall NAT
Appliance ↔ Outbound 配置：
- 在 FullEnvironment.json 提前声明
- 否则部署期会失败或反复重试

2.5 Portal 与 CLI 支持

✅ 官方要求

VM lifecycle 管理以 CLI / Arc API 为主
Portal 支持有限

🔍 技术分析

Portal = ARM façade（门户只是 UI 外壳）
实际控制面 = Azure Arc resource provider
VM 创建入口通过 Azure Arc enabled VM resource provider （不是传统 Azure VM portal）

💡 企业最佳实践

CLI + GitOps（强烈推荐）
Portal 仅用于观测

3. VM 创建流程（CLI 流水）

3.1 前置准备

复制代码

# 1. 安装支持的 CLI + 扩展
# ⚠️ extension 名随版本变化：
#    - stack-hci-vm（旧）
#    - azurestackhci / az stack-hci（新版组合）
# ⚠️ 版本号必须对齐 Azure Local release train（不是 Azure CLI 本身的版本）
az extension add -n stack-hci-vm

# 2. 登录（disconnected 模式已切到 local cloud）
az login

🔍 技术分析

extension 用于：Azure Local VM resource provider binding
disconnected 模式：仍依赖本地 control plane metadata

3.2 变量配置

复制代码

# ⚠️ 变量大小写必须统一------$subscriptionId 和 $SubscriptionId 混用会导致脚本静默失败
$subscriptionId = "<SubscriptionId>"
$resource_group = "disconnected-test-rg"
$customloc_name = "s-cluster-customlocation"
$location = "autonomous"

# Custom Location ID 拼接
$customLocationID = "/subscriptions/$subscriptionId/resourceGroups/$resource_group/providers/Microsoft.ExtendedLocation/customLocations/$customloc_name"

3.3 创建 Storage Path

复制代码

az stack-hci-vm storagepath create `
    --resource-group $resource_group `
    --custom-location $customLocationID `
    --location $location `
    --path "C:\\ClusterStorage\\UserStorage_1\\VMPath" `
    --name "New_StoragePath"

$storagePathID = (az stack-hci-vm storagepath show `
    --name "New_StoragePath" `
    --resource-group $resource_group `
    --query id -o tsv)

3.4 创建 VM Image（VHDX）

复制代码

# 1. 下载 / 拷贝 VHDX 到 cluster storage
curl.exe -o "C:\\ClusterStorage\\UserStorage_1\\testimage.vhdx" "<VHDX_URL>"

# 2. 创建 image 元数据
az stack-hci-vm image create `
    --resource-group $resource_group `
    --custom-location $customLocationID `
    --location $location `
    --storage-path-id $storagePathID `
    --image-path "C:\\ClusterStorage\\UserStorage_1\\testimage.vhdx" `
    --name "test-gallery-image" `
    --os-type "Windows"

🔍 技术分析

image create 只创建元数据 + VHDX 引用
不上传到 Azure storage------是本地元数据

⚠️ Ubuntu 镜像关键提示

Ubuntu 在 Azure Local VM 上不能直接用 cloud image------必须：

Hyper-V Gen2 compatible VHDX

已安装 hv_vmbus drivers（部分版本）

经 sysprep / cloud-init 准备（参考 Prepare Ubuntu image for Azure Local VM via Azure CLI）

3.5 创建 Logical Network

复制代码

# ⚠️ PowerShell 会把 `()` 当子表达式解析，必须用单引号嵌套双引号包裹 switch name
az stack-hci-vm network lnet create `
    --resource-group $resource_group `
    --custom-location $customLocationID `
    --location $location `
    --name "arcvm-lnet-static" `
    --vm-switch-name '"ConvergedSwitch(managementcomputestorage)"' `
    --ip-allocation-method "Static" `
    --address-prefixes "192.168.200.0/24" `
    --ip-pool-start "192.168.200.180" `
    --ip-pool-end "192.168.200.190" `
    --gateway "192.168.200.1" `
    --dns-servers "192.168.200.222"

⚠️ Switch name 不是固定字符串

vm-switch-name 必须从部署时生成的 FullEnvironment.json 获取 ------不存在标准固定命名。

变化来源：

不同 appliance → Network Intent 命名约定可能不同

不同 OEM → 参考架构不同

不同 SDN profile → storage / management / compute 分离 vs 融合

必须从 HostNetwork.Intents.Name / DeploymentData.InfrastructureNetwork 段读取实际 switch 名称。

3.6 创建 NIC

复制代码

# ⚠️ HCI extension 里该参数是复数形式 `--subnet-ids`（即使只有一个子网也用复数）
# IP 必须在 lnet 的 ip-pool 区间内
az stack-hci-vm network nic create `
    --resource-group $resource_group `
    --custom-location $customLocationID `
    --location $location `
    --name "arcvm-vnic" `
    --subnet-ids "arcvm-lnet-static" `
    --ip-address "192.168.200.185"

3.7 创建 VM

复制代码

# ⚠️ 以下两个错误必须避免：
#  1. Azure Local 不支持 `vm-size="Custom"`，该参数在 HCI extension 中不存在
#  2. `processors` / `memory-mb` 不是 `--hardware-profile` 里的键值对，而是顶级参数
#  3. 引用本地自建 image 元数据时参数名是 `--image-name`（不是 `--image`）
az stack-hci-vm create `
    --resource-group $resource_group `
    --custom-location $customLocationID `
    --location $location `
    --nics "arcvm-vnic" `
    --storage-path-id $storagePathID `
    --computer-name "test-machine" `
    --admin-username "admin" `
    --admin-password "<StrongPassword!>" `
    --image-name "test-gallery-image" `
    --name "test-vm" `
    --processors 4 `
    --memory-mb 8192 `
    --enable-agent true

🔍 技术分析：什么是 `--enable-agent true`

这不是推测 --------enable-agent 是 Arc VM Agent onboarding flag（明确开关）：

自动部署 Azure Arc VM agent

启用以下 Guest 能力：

Guest management

Policy

Extension management

⚠️ 密码安全

文档示例中的 "example" 是弱密码 ------生产务必换强密码（密码复杂度满足 AD / 域策略要求）。

3.8 Trusted Launch（Preview）

复制代码

az stack-hci-vm create `
    --resource-group $resource_group `
    --custom-location $customLocationID `
    --location $location `
    --nics "arcvm-vnic" `
    --storage-path-id $storagePathID `
    --computer-name "test-machine" `
    --admin-username "admin" `
    --admin-password "<StrongPassword!>" `
    --image-name "test-gallery-image" `
    --name "test-vm-tl" `
    --processors 4 `
    --memory-mb 8192 `
    --security-type "TrustedLaunch" `
    --enable-secure-boot true `
    --enable-vtpm true `
    --enable-agent true

4. 架构级补充（官方未显式说明）

4.1 Arc VM Agent（`--enable-agent`）

🔍 技术分析

自动部署 Azure Arc VM agent，用于：

Guest management
Policy
Extensions

4.2 Monitoring（监控）

🔍 技术分析

|------------------------------|--------------------------------------------------------------------------------------------|
| 监控源 | Disconnected 模式可用性 |
| Azure Monitor Agent（AMA） | ✔ 可部署 ，但 disconnected 模式下无 Azure ingestion endpoint ------无法完成数据上传链路，仅保留本地运行能力 |
| Log Analytics | ❌ Disconnected 不可用 |
| 本地 SIEM / Syslog | ✔ 推荐 |
| Prometheus / Grafana | ✔ 推荐 |
| SCOM 管理包 | ✔ 可用（但需 SCOM 基础设施） |

生产建议 ：统一 SIEM 接入，不依赖 Azure Monitor（disconnected 模式下无法上传）。

不要混用表述 ：AMA "可装但不可用"------准确的工程描述是"可部署但无数据上传链路"。

4.3 Image Lifecycle（镜像生命周期）

🔍 技术分析

Azure Local VM ≠ Azure VM
没有 ARM image gallery pipeline
只能：
- 手工 VHDX
- 企业 golden image
- CI/CD pipeline 构建

4.4 VM 生命周期能力（语义边界）

🔍 技术分析

|--------------------|----------|--------------------------------------------------------------------------------|
| 操作 | 支持情况 | 关键限制 |
| resize | ✔ 支持 | 依赖 VM stop/start------不支持热调整 vCPU/内存 |
| live migration | ✔ 支持 | 仅 cluster 内（不是跨 cluster / 跨 region） |
| HA | ✔ 支持 | 依赖 Failover Cluster ------不具备 Azure Region SLA 语义，也不是 Availability Set |
| 快照 | ✔ 支持 | Hyper-V checkpoint |
| extension | ✔ 支持 | 通过 Arc VM agent（--enable-agent true） |

关键差异（必须理解）：

Azure Local VM 的 HA 属于 Hyper-V Failover Cluster 模型，不具备 Azure Region SLA 语义。

也就是说------Azure Local VM 故障转移 ≠ Azure IaaS VM 的 SLA 99.99%。不要把 Azure Local VM 的 HA 跟 Azure IaaS VM SLA 混为一谈。

4.5 删除存储路径的级联约束（顺序敏感）

删除顺序至关重要 ------错误顺序会留下 Arc 控制面的孤立镜像元数据 ，导致 Storage Path 永久无法解绑。

💡 正确删除顺序

删除 VM（先停后删）
删除磁盘（data disk / OS disk）
优先删除 image 元数据 （这一步最常被忽略）
最后删除 Storage Path

⚠️ 反面教训

绝对不要绕过 Arc 控制面，直接通过底层 Hyper-V cmdlet 删除物理 VHDX 文件：

Arc 控制面持有的 image 元数据不会自动消失

该元数据仍然引用已经不存在的 VHDX 文件路径

结果：Storage Path 永远无法解绑------只能用强制清理脚本

🔧 反向修补（如果已经走错）

不能通过 Portal / CLI 直接解绑
需要：
- 手动清理 Appliance 上的吊桶引用
- 或重新部署 Appliance（最坏情况）

5. 企业级最佳实践总结

🏗 架构建议

VM 镜像统一 golden image 管理
CLI IaC 化（GitOps）
VM metadata 全部纳入 CMDB

🔐 安全建议

必须启用 ：
- Secure Boot
- vTPM
密码策略必须企业级（禁止示例弱密码）
关键 VM 集成 Defender for Endpoint

🌐 网络建议

所有 IP pool 预规划
DNS / gateway 固定化（写进 lnet 配置）
网络全 CLI 化，不依赖 Portal 复杂配置

📊 运维建议

统一 SIEM（非依赖 Azure Monitor）
Arc agent 统一版本管理
VM metadata 变更走 PR + GitOps 流程

🔄 升级与兼容

升级前：查看 Azure Local release notes
升级顺序：CLI → extension → OperationsModule → Appliance------逐项验证
VM resize / HA / 迁移能力应与连网模式对齐（基本无差异）

6. Disconnected vs Connected 关键差异表

企业最关心的维度------同一份 VM 配置在两种模式下的实际差异。

|------------------------|----------------------------------|-------------------------------------------|---------------------------|
| 维度 | Connected 模式 | Disconnected 模式 | 影响 |
| VM lifecycle 管理入口 | Portal + CLI + API | CLI + API 为主，Portal 有限 | 自动化优先 |
| VM image 来源 | Azure Marketplace + 自建 | 仅自建 VHDX（CSV） | 需内部 golden image pipeline |
| Arc VM Agent | 自动 + 持续上报 | 自动部署，无 Azure 端上报 | 失去云端 Guest 监控 |
| Azure Monitor | ✔ 上报到 Log Analytics | ❌ 无 ingestion endpoint | 必须本地 SIEM |
| Defender for Cloud | ✔ Attestation + 策略 | ⚠ 组件可装，attestation 不可用 | 安全合规需本地替代 |
| Trusted Launch | ✔ 完整 attestation | ⚠ Secure Boot + vTPM，measured boot 有限 | 不等价 Azure IaaS |
| Marketplace 同步 | ✔ 自动 | ❌ 无 | 离线镜像库必须自建 |
| Patch / Update | ✔ Windows Update / apt via Azure | ⚠ 必须本地 WSUS / 离线 apt mirror | 需自建补丁源 |
| HA 模型 | Azure Region SLA | Hyper-V Failover Cluster | 不等价 SLA |
| Live Migration | 跨 region / 跨订阅 | 仅 cluster 内 | 不能跨 cluster 迁移 |
| Backup | Azure Backup | 第三方 / 本地 Veeam 等 | 无 Azure 原生备份 |
| Disaster Recovery | Azure Site Recovery | 第三方 / 业务连续性方案 | 需自建 DR |
| Cost 模型 | 按 vCPU / GB-hour | 预付费 / 容量承诺 | 计费模型不同 |

核心结论：

API 兼容 ------同一份 az stack-hci-vm 脚本在两种模式下基本都能跑

能力不等价------很多"在 connected 模式可用"的功能在 disconnected 模式下只是"组件在但数据不通"

企业替代方案------必须自建补丁 / 监控 / 备份 / DR

7. CLI vs Portal vs API Capability Matrix

企业选型必看------决定自动化与运维策略。

|------------------------|-----------------------------------|-----------------|--------------|
| 能力 | CLI（ stack-hci-vm ） | Portal（Arc） | REST API |
| VM 创建 | ✔ 完整 | ⚠ 基础 | ✔ 完整 |
| VM resize | ✔ 完整 | ✔ 基础 | ✔ 完整 |
| VM 删除 | ✔ 完整 | ✔ | ✔ 完整 |
| VM 启动 / 停止 | ✔ 完整 | ✔ | ✔ 完整 |
| VHDX image 创建 | ✔ 完整 | ❌ | ✔ 完整 |
| VHDX image 删除 | ✔ 完整 | ❌ | ✔ 完整 |
| Storage path 管理 | ✔ 完整 | ❌ | ✔ 完整 |
| Logical network 创建 | ✔ 完整 | ⚠ 查看为主 | ✔ 完整 |
| NIC 创建（static IP） | ✔ 完整 | ❌ | ✔ 完整 |
| Trusted Launch 配置 | ✔ 完整 | ⚠ 部分 | ✔ 完整 |
| Arc VM Agent 启用 | ✔ 完整 | ✔ | ✔ 完整 |
| Extension 部署 | ✔ 完整 | ⚠ 部分 | ✔ 完整 |
| Monitoring 查看 | ⚠ 需 AMA + 本地 | ✔ 基础 | ✔ 完整 |
| Live migration | ❌（cluster 层） | ❌ | ❌ |
| HA 配置 | ❌（cluster 层） | ❌ | ❌ |
| 快照 / Checkpoint | ⚠ 通过 Hyper-V cmdlet | ❌ | ⚠ |

图例：

✔ = 完整支持

⚠ = 部分支持 / 受限

❌ = 不支持

企业建议：

日常 lifecycle：CLI + IaC（GitOps）

Portal 仅用于：临时观测、故障定位

REST API 用于：CI/CD、自动化平台对接

Cluster 层操作 （HA / live migration）：用 Failover Cluster Manager / Hyper-V cmdlet------不走 Arc API

8. 工程级原则（Rule of Thumb）

这些原则是从微软架构推断的工程铁律------脱离这些会出现"明明文档说能，为啥跑不通"的问题。

8.1 CLI extension 必须对齐 release train

CLI extension version must align with Azure Local release train (not Azure CLI version).

Azure CLI 自身版本（如 2.81.0）跟 Azure Local 兼容性是间接关系

stack-hci-vm / azurestackhci extension 版本才是直接绑定的

不要装"最新版 Azure CLI + 最新版 extension"------可能跨 release train

应该：看 Azure Local release notes → 找该 release 对应的 extension 版本

🔍 落地抓手：操作前必跑清查命令

复制代码

# 操作前必须跑：列出所有可用 extension 版本，显式核对
az extension list-available -o table

# 具体要核对：
#   - azurestackhci 或 stack-hci-vm 的版本号
#   - 是否在 OEM 硬件厂商提供的白名单内（Dell / Lenovo / HPE 通常有 version matrix）
#   - 是否与 Appliance build 、Operations Module 版本一致

三方一致性原则（操作前必须检查）：

|---------------------------|--------------------------------------------|
| 组件 | 核对来源 |
| Azure Local release | OEM release notes / Azure Local catalog |
| CLI extension version | az extension list-available -o table |
| Appliance build | Get-Module -Name Az.Local -ListAvailable |

任意一项不匹配：先把版本对齐，再继续操作。

8.2 能力 ≠ 完整

Azure Local VM 的 很多功能是 Hyper-V 层语义，不是 Azure IaaS 语义：

HA = Failover Cluster，不是 SLA 99.99%

resize = stop/start，不是热调整

live migration = cluster 内，不是跨 cluster

Trusted Launch = 本地 enforcement，不是 Azure attestation

8.3 "组件在 ≠ 数据通"

Disconnected 模式下：

AMA 可装 ≠ 数据能上传

Defender 可装 ≠ attestation 可用

Arc Agent 可装 ≠ Guest 能上报 Azure

凡是"需要 Azure 端 ingestion / attestation / 同步"的功能，组件装好只是第一步 ，Azure 端不可达就失去完整能力。

8.4 镜像管理是本地工程

没有 Marketplace = 必须内部 golden image pipeline

没有自动 patch = 必须本地 WSUS / 离线 apt mirror

没有 ARM image pull = 所有 VHDX 必须落 CSV

这三件事没有官方托管方案------必须企业自建

Azure Local离线模式VM 管理（系列篇十二）

0. 三层架构（理解整篇文档的入口）

1. Guest OS 支持矩阵

✅ 官方要求

🔍 技术分析

💡 企业最佳实践

2. VM 功能与限制清单

2.1 VM 镜像管理

✅ 官方要求

🔍 技术分析

💡 企业最佳实践

2.2 网络与 NIC

✅ 官方要求

🔍 技术分析

💡 企业最佳实践

2.3 Trusted Launch（安全启动）

✅ 官方要求

🔍 技术分析（重要约束）

💡 企业最佳实践

2.4 Proxy 行为

✅ 官方要求

🔍 技术分析（关键区分）

💡 企业最佳实践

2.5 Portal 与 CLI 支持

✅ 官方要求

🔍 技术分析

💡 企业最佳实践

3. VM 创建流程（CLI 流水）

3.1 前置准备

🔍 技术分析

3.2 变量配置

3.3 创建 Storage Path

3.4 创建 VM Image（VHDX）

🔍 技术分析

⚠️ Ubuntu 镜像关键提示

3.5 创建 Logical Network

⚠️ Switch name 不是固定字符串

3.6 创建 NIC

3.7 创建 VM

🔍 技术分析：什么是 --enable-agent true

⚠️ 密码安全

3.8 Trusted Launch（Preview）

4. 架构级补充（官方未显式说明）

4.1 Arc VM Agent（--enable-agent）

🔍 技术分析

4.2 Monitoring（监控）

🔍 技术分析

4.3 Image Lifecycle（镜像生命周期）

🔍 技术分析

4.4 VM 生命周期能力（语义边界）

🔍 技术分析

4.5 删除存储路径的级联约束（顺序敏感）

💡 正确删除顺序

⚠️ 反面教训

🔧 反向修补（如果已经走错）

5. 企业级最佳实践总结

🏗 架构建议

🔐 安全建议

🌐 网络建议

📊 运维建议

🔄 升级与兼容

6. Disconnected vs Connected 关键差异表

7. CLI vs Portal vs API Capability Matrix

8. 工程级原则（Rule of Thumb）

8.1 CLI extension 必须对齐 release train

🔍 落地抓手：操作前必跑清查命令

8.2 能力 ≠ 完整

8.3 "组件在 ≠ 数据通"

8.4 镜像管理是本地工程

🔍 技术分析：什么是 `--enable-agent true`

4.1 Arc VM Agent（`--enable-agent`）