怎么在监控里对待宿主机上的虚拟机，我前后转变过一次思路。最早做观澜的时候，我写过一套“合成设备”逻辑：只要探针发现宿主机上跑着 Hyper-V、Proxmox 或者 QEMU 虚拟机，就自动把每个 VM 当成一台虚拟设备塞进主设备列表里。结果没几天，主设备目录里全是一堆关机、快照或者临时测试的小虚拟机，把真正重要的物理机全淹没了。于是在 9 月 23 日（v3.0.85），我痛快地把这套合成 VM 模型全砍了——真正要重点监控的虚拟机，直接在里面装个轻量 Agent 就行。
但砍掉合成 VM 后，另一个盲区在 10 月中旬突然给了我一个下马威。
差点撑爆宿主机的 local-lvm 95% 惊魂
10 月中旬有天排查构建卡顿，我偶然在 PVE 宿主机上敲了一下 pvesm status，直接惊出一身冷汗：845 GB 的 local-lvm 精简配置池（thin pool）已经被分配到了 805 GB，占用率高达 95.19%，全池只剩大约 40 GB！
最要命的是，在各个虚拟机的 guest 系统里面看，每台机器的虚拟根盘明明都还有上百 G 的剩余空间；而在宿主机常规的 OS 挂载点监控里，LVM thin pool 又不像普通 ext4 分区那样挂在目录树上。一旦精简池被写穿，宿主机上跑着的所有开发机 VM 都会瞬间卡死 IO。
双源去重合并与 storagePools 存储池面板
为了不再被这种“隐形炸弹”偷袭，我在 2026 年 10 月 11 日（v3.0.153，Commit 4216c7e）专门为宿主机新增了 storagePools（虚拟机存储分区） 监控维度。
采集端采用了**“Proxmox 只读 API Token + 操作系统底层探测”双源去重合并**的方案：一方面直接读取 PVE API 汇报的存储池状态，另一方面在 OS 层扫描 LVM 精简池、ZFS 存储池以及 NFS/CIFS 共享挂载。合并时会自动过滤掉像 vm-105-disk-0 这样的单个虚拟机子卷，只保留真正的存储池主体。在设备详情的“存储”标签页里，现在点开就能直观看到每个存储池的分配率仪表盘和历史增长曲线，再也不用担心精简池悄悄见底了。