虚拟机中如何正确配置lm sensors进行硬件监控？，lm sensors虚拟机安装疑问

虚拟机里直接安装 lm sensors，默认情况下是读不到物理硬件真实温度的。 要让 lm sensors 在虚拟机中正常输出数据，核心思路不是像物理机那样跑一遍 sensors-detect 去扫描芯片，而是先弄清楚虚拟化平台暴露了哪些可用通道，再通过 virtio 虚拟传感器或 PCI 设备直通，把宿主机上的温度数据映射进虚拟机里处理。

为什么虚拟机里 lm sensors 经常“毫无反应”

很多朋友在 KVM、VMware 或 Proxmox VE 里装完 lm-sensors，执行 sensors 命令，输出要么是空列表，要么直接提示 No sensors found，这其实是虚拟化机制带来的必然结果，不是软件装错了，而是硬件通道一开始就不存在。

虚拟化层会隐藏物理主板的 SMBus 控制器和 ACPI 温度节点，虚拟机内部看到的是一套纯虚拟化硬件，lm-sensors 的工作方式是扫描 I2C 总线上的传感器芯片地址，访问 /sys/class/hwmon 下的设备节点，这两者在虚拟机里默认都是空的，换句话说，KVM、ESXi 环境下的 lm sensors 安装问题，绝大多数都出在设备映射这一层，而不是驱动兼容性。

行业共识认为,lm-sensors 面向的是裸金属服务器和物理工作站的监控场景，虚拟化平台属于半路出家的使用者，需要额外的桥接手段才能让它“看见”温度。

裸金属和虚拟机的监控差异

明白了这层差异,再去看各种各样的虚拟机 lm sensors 配置指南，就不会被网上互相矛盾的教程带偏了。

虚拟机 lm sensors 配置的正确实操路径

先说结论：有两条路可走，一条走虚拟传感器模拟，另一条走物理设备直通，两条路适用的虚拟化平台不同，操作难度也有明显差别。

通过 virtio 虚拟传感器让虚拟机感知温度

这个方案主要面向 KVM/QEMU 平台的用户，Proxmox VE 底层也是 QEMU，同样适用，自 QEMU 6.0 版本开始，虚拟化社区引入了 virtio-sensors 设备，允许宿主机把真实的 hwmon 数据通过 virtio 总线暴露给虚拟机。

具体操作路径如下：

• 在宿主机上停止虚拟机,编辑虚拟机的配置文件，增加一行 -device virtio-sensors-pci
• 启动虚拟机,进入系统后先加载驱动模块：modprobe virtio_sensors
• 安装 lm-sensors 工具集：apt install lm-sensors 或 dnf install lm_sensors
• 执行 sensors 命令，这时应该能看到传递进来的温度节点

这种方式下,虚拟机内 lm sensors 读取到的数值，本质上是宿主机物理传感器的镜像。宿主机 CPU 温度实时更新，虚拟机内看到的也是同步变化，数据链路是通的，但虚拟机本身没有独立采样能力。

对于云服务器场景,简米云、酷番云这类厂商的虚拟机默认不提供 virtio-sensors 通道，多数情况下直接使用厂商自带的监控控制台反而更方便，非要在云虚机里折腾 lm sensors 属于绕远路。

把物理传感器通道直通给虚拟机

这个方案适合 VMware ESXi 和部分自建虚拟化平台，核心操作是把物理主板的 SMBus 控制器通过 PCI 直通方式分配给特定虚拟机。

具体步骤如下：

• 在 ESXi 宿主机上通过 SSH 登录，执行 lspci | grep -i smbus 找到 SMBus 控制器地址
• 在虚拟机配置文件中添加 pciPassthru 参数，将 SMBus 设备映射给目标虚拟机
• 重启虚拟机,执行 lspci 确认设备已经可见
• 在虚拟机内绑定驱动,echo "0000:00:1f.4" > /sys/bus/pci/drivers/i2c-i801/bind
• 接着跑一遍 sensors-detect，按提示选择默认项即可识别出主板传感器芯片

行业内关于“vmware虚拟机 lm sensors 配置时找不到传感器芯片怎么办”的讨论，大多数最终都指向这个直通方案，不过需要注意，直通的物理设备只能被一台虚拟机独享，SMBus 总线上的操作如果出错，存在影响宿主机硬件稳定性的风险，非必要不建议在生产环境操作。

Proxmox VE 用户如果不想手动敲 QEMU 参数，也可以直接在 Web 管理界面的虚拟机硬件选项卡里添加 PCI 设备，选择主板的 SMBus 控制器，效果一样。

不同虚拟化平台的配置入口差异

• KVM/QEMU 自建环境：修改 libvirt 域 XML 文件，添加 virtio-sensors 设备
• Proxmox VE：支持 virtio-sensors，也可以通过图形界面添加 PCI 直通
• VMware ESXi：只支持 PciPassthru 模式，需要宿主机提前开启直通配置
• Hyper-V：对传感器透传支持相对有限，更推荐直接在宿主机层面采集温度

选哪个平台方案,取决于你的监控需求和可接受的折腾成本，如果只是想知道虚拟化集群里哪台物理机温度偏高，直接在宿主机上装 lm-sensors 反而更省事。

配置完成后，如何确认温度读数真的在反映物理硬件

虚拟机内的 lm-sensors 输出数据后，很多人会问一个问题：这些数字到底代表什么？答案是：看数据来源。

从 hwmon 设备映射关系反查数据来源

先执行 ls /sys/class/hwmon/，查看设备列表，再用 cat /sys/class/hwmon/hwmon/name 确认每个设备对应的驱动程序名称。

如果输出中出现了 coretemp，说明温度数据来自 CPU 核心的数字热敏二极管；如果出现 i801_smbus 或类似名称，说明走的是主板 SMBus 通道。这两种来源的数据可信度较高，属于真实物理传感器的读数。

判断读数是直通值还是模拟值的三个信号

• 虚拟机空载状态下,温度保持在一个完全恒定的数值不变，大概率是模拟值
• 执行 stress-ng 或其他压测工具后，温度出现明显上升趋势，说明直通链路有效
• 对比宿主机上 sensors 命令的输出，与虚拟机内读数相比，误差在正负 3 度以内属于正常

需要说明的是,virtio-sensors 方案下虚拟机感受到的温度变化会有轻微延迟，这是因为虚拟化层传输数据存在极短的轮询间隔，一般来说不影响日常监控判断。

遇到 lm sensors 没输出或找不到芯片，按这条排查路径走

如果你的配置过程不顺利,虚拟机内 lm sensors 依旧没有输出，问题大概率出在以下几个常见节点上。

报错 No sensors found 时的排查顺序

按照以下顺序逐项检查：

1. 执行 lsmod | grep hwmon，确认内核是否加载了 hwmon 框架
2. 检查 /etc/modules-load.d/ 下是否存在传感器模块的加载配置，补充 i2c-dev 和 coretemp 两行
3. 执行 sensors-detect，手动输入 NO 跳过危险性较高的扫描选项，避免程序卡死在自动探测环节
4. 确认当前用户是否有权限访问 /sys/class/hwmon/，必要时添加 udev 规则放行

温度数值恒定为 0 或长时间静止不动

这种场景在虚拟化环境里出现频率较高,要意识到，如果配置走的是 virtio 模拟通道，但宿主机本身没有挂接任何温度传感器，虚拟机读取到的就是空数据。解决方向是回到宿主机确认物理传感器的存在性，而不是在虚拟机里继续修改参数。

少数场景下放弃虚拟机直接监控，改用宿主机方案

当你的虚拟化平台是 Hyper-V 或者云厂商的专用虚拟化架构时，没有 SMBus 控制器可用于直通，virtio-sensors 设备也不支持，这种情况下最合理的方案是：在宿主机上配置 lm-sensors 或者带外管理系统来采集温度，虚拟机层面只负责应用运行，不承担硬件监控职责。

常见疑问快速解答

vmware 虚拟机里 lm sensors 读取不到传感器芯片正常吗？

正常,未做直通前，虚拟机的 SMBus 控制器是虚拟化层模拟出来的空壳，不承载真实设备访问，lm sensors 找不到芯片是预期内的结果，解决办法是走 PCI 直通，把物理 SMBus 控制器分配给特定虚拟机后，传感器即可正常显示。

虚拟机内的 CPU 温度能代表物理服务器真实温度吗？

取决于数据链路,通过 virtio-sensors 或 PCI 直通读取的数据，代表的是物理 CPU 的真实温度；单纯依赖虚拟化层显示的 CPU 温度，则多数情况下是根据虚拟 CPU 负载模拟出来的参考值，不反映物理核心的热状态。

直通传感器到虚拟机后，还能在宿主机上同时读取温度吗？

不能,PCI 直通设备被虚拟机独占后，宿主机将无法直接访问这个 SMBus 控制器，sensors 命令在宿主机上会丢失对应通道，运维上建议由虚拟机侧完成数据采集后，再通过网络协议上报给监控系统汇总。

虚拟化环境下的温度监控从来不是装一个软件那么简单,物理传感器被虚拟化层隔离后，单纯依赖虚拟机内部的 lm-sensors 并不现实，正确做法是提前决定监控入口：要么走 virtio 虚拟传感器交给业务侧自己看，要么直接由宿主机统一采集、向下透传，避免两边数据打架。