必须在终端执行命令验证：先用egrep -c '(vmx|svm)' /proc/cpuinfo和lscpu | grep -i virtualization确认cpu硬件支持，再用lsmod | grep kvm检查内核模块加载，接着验证/dev/kvm设备节点是否存在，最后用sudo virt-what交叉判断真实就绪状态。
你需要确认麒麟操作系统当前是否已启用CPU虚拟化功能，否则KVM、VMware等虚拟化软件将无法启动或报“未检测到VT-x/AMD-V”错误。这一步必须在终端中执行命令验证，不能仅靠BIOS设置截图或CPU型号宣传判断。
第一步：检查CPU硬件是否支持虚拟化
先确认你的CPU本身具备虚拟化能力，这是后续所有操作的前提。ARM平台（如鲲鹏920）和x86平台（如Intel/AMD）检测方式不同，不能混用。
在终端中运行：egrep -c '(vmx|svm)' /proc/cpuinfo
若输出为大于0的整数（例如8），说明CPU原生支持——Intel芯片显示vmx，AMD芯片显示svm；若输出为0，不代表不支持，需结合CPU型号查厂商手册，尤其飞腾D2000、龙芯3A5000等国产芯片可能使用ARM HVC或LoongArch VZ扩展，此时应改用lscpu命令。
再运行：lscpu | grep -i virtualization
ARM平台看到Virtualization: ARM virtualization extensions才算硬件就绪；x86平台看到Virtualization: VT-x或Virtualization: AMD-V才表示扩展已识别。若显示None，大概率是BIOS里被禁用，而非CPU不支持。
第二步：验证内核是否已加载KVM模块
即使CPU支持且BIOS已开启，内核没加载对应模块，虚拟化仍不可用。这是最容易被忽略的环节，很多用户卡在这一步却反复重进BIOS。
执行：lsmod | grep kvm
ARM平台必须同时看到kvm和kvm_arm；x86平台必须看到kvm_intel（Intel CPU）或kvm_amd（AMD CPU）。只出现kvm但无后缀模块，说明内核未加载具体驱动。
若无输出，尝试手动加载：sudo modprobe kvm_intel（Intel）或sudo modprobe kvm_amd（AMD）
注意：如果执行后仍无输出，且dmesg | grep -i kvm显示“disabled by BIOS”，说明BIOS设置未生效或被SMM Security Mitigations锁死，需重新进UEFI关闭该选项。
第三步：确认/dev/kvm设备节点是否存在
这是最终落地的硬性指标——没有这个设备文件，所有虚拟机软件都会直接报错退出。
运行：ls -l /dev/kvm
正常应显示c 10, 232开头的字符设备权限信息。若提示“No such file or directory”，说明KVM子系统未激活，此时即使前两步都通过也无效。
补救方法：先确保已执行sudo modprobe kvm_intel（或kvm_amd），再检查是否因kysec安全中心拦截——打开银河麒麟安全中心→内核保护→查看“KVM模块加载”是否被策略阻止，临时关闭该策略后重试。
第四步：用virt-what交叉验证运行时状态
该工具能识别嵌套虚拟化、宿主机类型及模块加载真实状态，比单一命令更可靠。
① 安装工具：sudo apt install virt-what
② 执行检测：sudo virt-what
③ 判断结果：输出为空 → 虚拟化完全未就绪；输出为kvm → KVM已加载可用；输出为intel或amd → CPU扩展已识别但kvm模块未加载或/dev/kvm缺失。
这一步能快速区分问题是出在硬件层、内核层还是设备节点层，避免盲目重启或重装系统。
