OpenBMC 资产管家：inventory 如何实现硬件信息的标准化管理

在 OpenBMC 系统中，inventory 是负责硬件资产信息 “收集、整理、暴露” 的核心组件 —— 它就像一位 “专业资产管理员”，从 BIOS、RAID 等服务获取分散的硬件数据，按标准化规则整理后，通过 D-Bus 接口统一暴露，为服务器资产盘点、远程运维、故障排查提供统一的数据入口。本文结合技术细节，拆解其核心功能、工作流程与实战价值，隐藏企业隐私信息，适用于 OpenBMC 运维人员与开发者。

一、核心定位：inventory 到底做什么？

inventory 的核心目标是 “解决硬件信息分散、格式不统一” 的痛点，实现三大核心功能：

简单说，没有 inventory，BMC 需从多个源头零散获取硬件数据，适配成本高；有了它，所有硬件信息 “一站式获取”，无需关注数据来源差异。

二、核心应用：资产信息的两大使用场景

inventory 整理的资产信息，是服务器全生命周期管理的基础，核心应用于两大场景：

1. 可视化资产展示（面向运维人员）

通过 OpenBMC 的 Web 管理界面，直观呈现服务器硬件配置，无需登录机房即可完成资产盘点：

• CPU 信息：型号、核心数、线程数、缓存大小、额定频率、制造商等；
• 内存信息：每个 DIMM 插槽的容量、内存类型（如 DDR5）、部件号等；
• 存储 / PCIe 信息：NVMe 硬盘、PCIe 设备的型号、在位状态、健康状态等；
• 系统信息：BIOS 版本、主板相关配置等。

2. 标准化数据接口（面向外部服务）

通过 D-Bus 接口暴露结构化数据，供其他服务或工具调用：

• 支持 busctl 等命令行工具本地查询；
• 支撑 SNMP、Redfish 等远程管理协议，实现大规模集群的资产批量查询；
• 为故障排查提供硬件溯源数据（如通过序列号定位故障硬件）。

三、D-Bus 接口：资产信息的 “统一访问入口”

inventory 整理后的所有资产信息，都会挂载到标准化的 D-Bus 路径下，结构清晰、易于访问。

1. 核心 D-Bus 路径结构

资产信息按硬件类型分类挂载，顶层路径为 xyz.openbmc_project.inventory，核心子路径如下：

/xyz/openbmc_project/inventory/system/chassis/
├── cpu/ # CPU 资产信息（如 CPU0、CPU1）
├── dimm/ # 内存资产信息（如 DevType2_DIMM0、DevType2_DIMM1）
├── pcie/ # PCIe 设备资产信息（如 00_60_00）
├── storages/ # 存储设备资产信息（如 NVMe 硬盘）
└── system/ # 系统级资产信息

2. 典型 D-Bus 属性示例（以 CPU 为例）

通过 busctl introspect 命令可查询具体硬件的资产属性，以 CPU0 为例，核心属性包括：

这些属性均支持 “实时更新”，当硬件配置变化（如更换内存）时，lnv-inventory 会自动同步更新 D-Bus 属性。

四、工作流程：从 “原始数据” 到 “标准化资产” 的全链路

inventory 的工作流程可概括为 “采集→解析→整理→暴露→监听更新” 五步，每一步都确保数据的准确性和标准化：

1. 数据采集：从多源头获取原始信息

inventory 主要从两个核心源头采集数据，确保信息全面性：

• BIOS 共享内存（vgasharedmem）：BMC 与 BIOS 通过共享内存通信，BIOS 将硬件配置（CPU、内存、主板等）写入共享内存，BMC 读取后存储到 /tmp/vga_data 临时文件，再迁移至 /mnt/mmcblk0p5/bios/ 目录供后续解析；
• RAID 服务：通过 D-Bus 接口从 RAID 服务获取存储设备（如硬盘、阵列）的配置与状态信息；
• 补充：存储卡等特殊硬件的信息，通过专属解析逻辑获取，不依赖 BIOS 共享内存。

2. 解析与整理：按配置规则映射数据

这是 inventory 的核心环节，通过两份关键配置文件实现标准化映射：

• inventory.json：BIOS 生成的原始硬件数据文件，包含 CPU、内存、系统等信息的原始键值对；
• key.json：映射规则配置文件，定义 “原始数据键” 与 “D-Bus 属性” 的对应关系，核心规则包括：
• 包含关系用 “-” 表示（如 ProcessorId-EffectiveFamily 对应 CPU 有效家族）；
• 数组元素用 “/0-”“/1-” 表示（如 ProcessorMemory/0-CapacityMiB 对应 L1 缓存容量）；
• 数组类型需标注 SubType（如字符串数组、数值数组）。

映射逻辑：inventory 遍历 inventory.json 中的原始数据，按 key.json 的规则提取对应值，转化为 D-Bus 接口的标准化属性（如将 TotalCores 原始值映射为 CoreCount 属性）。

3. 暴露与监听：持续同步硬件状态

• 初始化暴露：启动时，inventory 初始化 D-Bus 接口，将整理后的资产信息挂载到对应路径，供外部调用；
• 状态监听与更新：
• 监听 BIOS 目录文件变化：若 bios/ 目录出现新增 / 修改文件（如 BIOS 配置变更），自动重新读取解析，更新 D-Bus 属性；
• 监听 BIOS Post 状态：通过 GPIO 引脚（如 VW_FM_BIOS_POST_CMPLT_N）判断 BIOS 初始化状态，Post 完成后（引脚值为 1），将硬件 Functional 属性设为 true，标记硬件可用；
• 监听资产变更信号（InvChange）：若硬件配置变化（如插拔内存），触发重新解析，同步更新 D-Bus 信息。

五、key.json 配置：标准化映射的核心规则

key.json 是 inventory 实现 “原始数据→标准化属性” 的关键，定义了三大核心映射规则，通过示例直观理解：

1. 基础键值映射（直接对应）

适用于原始数据与 D-Bus 属性一一对应的场景：

"CoreCount": {
"Type": "uint64",
"Value": "TotalCores"
}

• 含义：将 inventory.json 中 TotalCores 的原始值，映射为 D-Bus 接口的 CoreCount 属性，类型为 64 位整数（对应 CPU 核心数）。

2. 层级关系映射（用 “-” 连接）

适用于原始数据存在层级嵌套的场景：

"UniqueIdentifier": {
"Type": "string",
"Value": "ProcessorId-UniqueIdentificationNumber"
}

• 含义：提取 inventory.json 中 ProcessorId 层级下的 UniqueIdentificationNumber 值，映射为 D-Bus 的 UniqueIdentifier 属性（对应 CPU 唯一标识）。

3. 数组元素映射（用 “/n-” 表示）

适用于原始数据为数组的场景（如 CPU 多级缓存）：

"L1CacheCapacityMiB": {
"Type": "uint64",
"Value": "ProcessorMemory/0-CapacityMiB"
},
"L2CacheCapacityMiB": {
"Type": "uint64",
"Value": "ProcessorMemory/1-CapacityMiB"
}

• 含义：ProcessorMemory 是原始数据中的数组，/0- 对应第 1 个元素（L1 缓存），/1- 对应第 2 个元素（L2 缓存），分别映射为对应的缓存容量属性。

六、核心价值：为什么离不开 lnv-inventory？

inventory 为 OpenBMC 系统提供了 “统一、标准、可靠” 的资产信息管理能力，核心价值体现在三方面：

总结：inventory 的本质是 “资产信息的标准化翻译官”

inventory 不生产硬件数据，而是做 “数据的翻译官”—— 将不同源头、格式各异的原始数据，翻译成标准化、结构化的资产信息，再通过统一接口暴露。它让 OpenBMC 对硬件资产的管理从 “零散适配” 走向 “统一管控”，是服务器远程运维、规模化管理的基础支撑。

对于运维人员，它是 “无需机房的资产盘点工具”；对于开发者，它是 “无需关注数据来源的标准化接口”，二者共同受益于其带来的高效与便捷。