虚拟机 CPU 指令集问题排查：glibc 报错 CPU does not support x86-64-v2

虚拟机里跑 MySQL 8，容器直接起不来，日志里一句 Fatal glibc error: CPU does not support x86-64-v2 就完事了。折腾了一圈，发现是虚拟机 CPU 配置的坑。

问题现象

MySQL 8.x 容器启动直接挂掉，日志就一行：

Fatal glibc error: CPU does not support x86-64-v2

glibc 在程序启动最早期就检测 CPU，发现不对直接拒绝运行，后面的服务全都起不来。

x86-64-v2 是什么

x86-64 这些年一直在加新指令集，为了方便管理，就分了几个级别：

从 2022 年开始，RHEL 9、Ubuntu 22.04 这些新发行版，还有 MySQL 8.x、新版 glibc，都把 x86-64-v2 当成最低要求了。换句话说，2009 年之前的老古董 CPU 已经跑不动新系统了。

问题在哪

查了一圈，问题出在虚拟机的 CPU 配置上。

虚拟化平台默认给虚拟机分配一个"通用型"虚拟 CPU，目的是方便迁移——不管宿主机是什么 CPU，虚拟机都能跑。代价就是：虚拟 CPU 会故意隐藏宿主机的新指令集，只暴露一个最保守的指令集组合。

在虚拟机里看一下 CPU 信息：

cat /proc/cpuinfo | grep -E "model name|flags" | head -4

如果显示的是 QEMU Virtual CPU 之类的通用型号，而不是宿主机真实的 CPU 型号，那就是用的兼容模式。

检查一下关键指令集有没有：

# 检查关键指令集
grep -o -E 'sse4_1|sse4_2|ssse3|popcnt' /proc/cpuinfo | sort -u

如果输出不全，那就是虚拟 CPU 的指令集不够 x86-64-v2。

为什么以前没事

以前的软件对 CPU 要求低，兼容模式完全够用。但新软件默认假设你的服务器是近十年内的机器，兼容模式就不行了。

解决方案

改虚拟机配置，启用 Host CPU Passthrough，让虚拟机直接用宿主机的真实 CPU。

不同平台的改法：

Proxmox VE

CPU 类型改成 host：

# 编辑配置文件
vim /etc/pve/qemu-server/<vmid>.conf

# 修改 cpu 行
cpu: host

Web 界面的话：虚拟机 → 硬件 → 处理器 → 类型 → 选 host

VMware vSphere/ESXi

虚拟机设置 → CPU，把硬件虚拟化和 EVC 模式相关的选项打开。

或者直接改 vmx 文件：

cpuid.coresPerSocket = "1"
featMask.vm.cpuid.SSE3 = "Val:1"
featMask.vm.cpuid.SSSE3 = "Val:1"
featMask.vm.cpuid.SSE41 = "Val:1"
featMask.vm.cpuid.SSE42 = "Val:1"

libvirt/KVM

改虚拟机 XML 配置：

<cpu mode='host-passthrough' check='none'/>

或者用 virsh：

virsh edit <vm-name>
# 将 <cpu> 部分改为上述配置

验证

改完重启虚拟机，看看 CPU 信息：

# 查看 CPU 型号
cat /proc/cpuinfo | grep "model name" | head -1

# 验证指令集
grep -o -E 'sse4_1|sse4_2|ssse3|popcnt|avx|avx2' /proc/cpuinfo | sort -u

配置对了的话，应该能看到宿主机的真实 CPU 型号（比如 Intel(R) Xeon(R) Platinum 8358 CPU @ 2.60GHz），指令集也全了。

重启数据库和容器服务，glibc 报错没了，一切正常。

关于迁移

用 Host CPU Passthrough 有个副作用：虚拟机迁移时，目标宿主机的 CPU 必须和源宿主机兼容（同代或更新）。不过对于大多数生产环境来说，同一集群内的宿主机 CPU 型号通常是一致的，问题不大。

小结

新系统 + 新数据库 + 虚拟化 = 必须开 Host CPU

不是性能优化，是基本运行要求。

参考资料

• x86-64 Microarchitecture Levels - Wikipedia
• QEMU CPU Models
• Proxmox VE CPU Type Documentation