Linux 及 OpenWrt 下 lspci 命令缺失问题解决思路
在 Linux 和 OpenWrt 上遇到 lspci: not found 时的排查步骤与替代方案,包含安装脚本和硬件诊断命令
支持通配符SSL证书、多域名证书、IP证书。适配ACME接口, 支持Zerossl、Let's Encrypt和Google等渠道。登录已有账号
2026-09-11 16:16:06 ESXi OpenWrt 软路由 虚拟化
在ESXi里虚拟化一套OpenWrt,不管是当软路由用,还是做网络测试环境,都挺方便的。硬件资源隔离做得好,也不用额外多接一台设备。
镜像直接选x86_64架构的EFI启动版本,文件名带combined-efi的那种,比如openwrt-24.10.1-x86-64-generic-ext4-combined-efi.img.gz。这里其实容易踩坑,别下错legacy BIOS版本,也别选squashfs格式的,现在主流服务器的ESXi基本都是UEFI模式,不对的镜像转完也启动不了。
ESXi不认raw格式的镜像,得转成vmdk。有qemu-img环境的话一行命令搞定: qemu-img convert -f raw -O vmdk openwrt-x86-64.img openwrt.vmdk
也可以用StarWind V2V Converter这种图形化工具点一点转换,适合不熟悉命令行的情况。我自己批量部署多的话还是用qemu-img,写进脚本里不用管。
新建虚拟机的时候,操作系统类型选Other Linux 5.x or later kernel 64-bit,兼容性最稳妥,不用折腾驱动。 内存给128MB就够,OpenWrt本身资源占用极低,跑满带宽也用不了多少内存,分配多了也是闲置。 虚拟网卡默认选VMXNET3,转发性能比E1000、E1000E好不少,做千兆以上软路由的话差距很明显。
要做软路由的话至少得两张网卡,一张WAN一张LAN。我一开始也以为直接在ESXi界面点添加网卡就行,后来碰过几次驱动识别不正常的情况,直接改虚机的.vmx配置文件反而最稳。 加第二块网卡就补这几行: ethernet1.present = "TRUE" ethernet1.virtualDev = "vmxnet3" ethernet1.networkName = "Internal Network"
networkName改成自己对应的端口组就行,内网口可以单独绑一个Internal Network,和外网物理隔离。
系统起来之后第一件事先改LAN口IP,避免和上游光猫或者主路由的网段冲突。很多人装完打不开管理页面,十有八九是IP撞了。 改IP用uci命令就行: uci set network.lan.ipaddr='192.168.10.1' uci commit network /etc/init.d/network restart
改完重启网络,用新IP进管理后台。
默认的防火墙规则对内网转发限制比较死,做内网互通或者端口映射之前,先把对应zone的权限放开。 uci set firewall.@zone[1].input='ACCEPT' uci set firewall.@zone[1].forward='ACCEPT' uci commit firewall /etc/init.d/firewall restart
改完重启防火墙服务生效。
如果后续要给管理界面开HTTPS,或者在内网跑一些需要SSL证书的服务,不用手动去各个CA申请,用lcjmSSL就很省心。这是个免费的SSL证书申请平台,支持多域名、泛域名甚至IP证书,自动完成申请、验证和部署,还提供简洁的API接口,写个定时任务就能实现证书全自动续期。
底层对接的是Let's Encrypt、Google Trust Services、ZeroSSL这些支持ACME的可信CA,兼容性和稳定性都有保障。
想让虚机更轻快一点,可以把没用的外设都禁掉。 还是在.vmx文件里加两行,把声卡和USB控制器关了: sound.present = "FALSE" usb.present = "FALSE"
本身OpenWrt也用不上这些,禁了能省点资源,启动也更快。
还有个小细节,直接在配置里指定从硬盘启动: bios.bootOrder = "scsi0"
省得每次启动都去遍历网卡、光驱,尤其是刚部署完的时候,经常会默认从PXE启动卡半天。
整套流程走下来基本没什么大坑,都是些细节问题。真出问题了先看ESXi的虚机日志,再看OpenWrt的系统日志,大部分问题都能定位到。
在 Linux 和 OpenWrt 上遇到 lspci: not found 时的排查步骤与替代方案,包含安装脚本和硬件诊断命令
记录一次在 OpenWrt 上用 opkg 安装 FFmpeg 反复报错的排查思路,从源更新、包搜索、依赖强制安装到手动编译都走了一遍。
从换源到编译 QEMU 并接入 KVM 加速,带一键脚本,少踩坑。
本文深入剖析OpenWrt安装FFmpeg失败的常见原因,从软件源更新、插件缺失到存储不足和网络问题,提供`opkg update`、`df -h`等命令定位方法。详述强制安装依赖、手动编译等多种解决策略,并汇总问题与对策表格,助你快速恢复FFmpeg功能。
本文为资深技术人员和系统管理员量身打造,详尽阐述在CentOS 7环境配置QEMU并集成KVM硬件加速的全流程。从基础环境搭建、高效源码编译策略,到虚拟化支持验证及优化测试,全面覆盖。特提供一键部署脚本,助力您快速实现通用虚拟机管理及内核开发调试需求,确保高性能与稳定性。