RK3588虚拟化实战：基于KVM的ARM虚拟机搭建与调优

RK3588这块芯片在ARM单板里算是个异类4个A76大核配4个A55小核性能强到可以当桌面电脑用。但真正让我决定用它做虚拟化实验的原因是它完整支持Armv8.2-A的虚拟化扩展可以跑KVM。很多人手里拿着RK3588开发板要么刷个Ubuntu当迷你电脑要么拿去跑神经网络推理很少人意识到这板子其实可以当一台正经的虚拟化宿主机来用在上面跑多个隔离的Linux虚拟机。这篇文章会从硬件能力检查开始一步步把宿主机环境调整到可虚拟化状态然后分别用命令行、cloud image和virt-manager三种方式创建虚拟机接着把网络从默认NAT改成桥接最后围绕vCPU绑定、大页内存、virtio IO路径做一轮性能调优。还会额外整理几个RK3588平台上KVM的经典故障排查案例包括/dev/kvm不存在的处理办法、ACPI suspend警告、以及桥接后宿主机断网这类问题。适合手里有RK3588开发板、想在上面跑多套隔离系统的开发者也适合对ARM虚拟化好奇、想搞一套低功耗实验环境的运维。1. 为什么是RK3588这块芯片做KVM值不值1.1 ARM虚拟化的家底EL2与虚拟化扩展很多从x86转过来的朋友习惯用/proc/cpuinfo里有没有vmx或svm标志来判断虚拟化能力在ARM平台这套完全不适用。ARMv8的虚拟化核心在异常等级EL2Exception Level 2KVM作为一种Type-1.5型虚拟化方案直接跑在EL2上guest操作系统则被降级到EL1。RK3588的CPU是Armv8.2-A架构这个版本已经包含了完整的虚拟化扩展包括VHEVirtualization Host Extensions。VHE让KVM的宿主机内核可以整体运行在EL2省去了传统ARM虚拟化中每次世界切换带来的Trap开销这也是RK3588上KVM性能能做到接近物理机的关键前提之一。另一个指标是GICGeneric Interrupt ControllerRK3588集成的是GIC-500支持GICv3规范虚拟化中断通过vgic模块直接分发给guest不需要宿主机参与逐条中断转发。先说结论RK3588的硬件是完全具备KVM运行条件的。我手头这块板子是16GB内存版本在跑4个vCPU、8GB内存的一台Ubuntu Server虚拟机时编译Linux内核、跑PostgreSQL压测都没有明显卡顿。当然如果你只是想在板子上跑个Docker那没必要上KVM容器和虚拟化的取舍下面单独说。1.2 KVM与容器方案的核心分界线RK3588上跑Docker很容易性能损耗也小那为什么还要上KVM核心区别在于隔离边界。Docker共享宿主机内核容器里的uname -r和宿主机一致/sys、/proc下的内核接口也是同一套。这在很多场景下没问题但如果你需要运行一个和宿主机内核版本不同的系统、需要测试内核模块、需要给客户交付一套完整独立的OS环境Docker就不够用了。KVM虚拟化的是硬件本身guest拥有自己的内核、自己的设备模型、自己的ACPI表隔离级别接近物理机。以我实际测试为例在RK3588宿主机上装的是Ubuntu 24.04内核6.8我在KVM里跑了一台Debian 12内核6.1和一台Ubuntu 22.04内核5.15三套环境互不干扰。这在Docker下做不到因为容器只能跑在宿主机内核上除非你用--privileged加一堆危险的挂载去伪造环境那还不如KVM来得干净。还有一个常见场景很多RK3588用户会移植Ubuntu 26这类新版本系统到板子上但如果移植失败或者不想动宿主机完全可以先在KVM里把新系统跑通、调好驱动再决定要不要物理迁移。虚拟化在这里变成了一个预演环境。1.3 什么样的项目适合用RK3588做虚拟化宿主先说痛快的结论RK3588适合轻量级虚拟化场景不适合跑重型数据库集群或大规模云平台。我整理了几类我在实践中验证过靠谱的用法多系统并行开发环境同一块板子上同时跑Ubuntu Server做编译服务器和Debian做软件兼容性测试互不干扰。嵌入式软件测试沙盒为不同客户、不同项目创建隔离环境避免依赖冲突。很多人会用KVM来模拟ARM服务器环境跑CI流水线。低功耗家庭服务器RK3588满负载功耗也就10瓦左右比一台x86迷你主机省电太多完全可以24小时挂着做虚拟化实验机。ARM原生编译集群如果交叉编译遇到依赖问题直接在KVM虚拟机里做原生编译比交叉工具链省心。不适合的场景我也说清楚如果你要做GPU直通或vGPU切分RK3588的Mali GPU目前虚拟化支持有限QEMU社区对Mali的virtio-gpu支持还在完善中别指望能像x86上NVIDIA vGPU那样切分。另外单块板子内存最多32GB虚拟化之后还要留一部分给宿主机单台guest超过16GB内存的规划趁早放弃。2. 宿主机改造把系统调整到可虚拟化状态2.1 检查硬件虚拟化能力拿到板子第一步不是装软件是确认当前系统是否暴露了KVM能力。在ARM上最直接的检查方法是看设备节点。ls -l /dev/kvm如果能看到/dev/kvm说明内核KVM模块已经加载直接跳到2.3节。如果提示No such file or directory先别慌大概率是内核配置问题而不是硬件问题可以用下面命令进一步确认CPU的虚拟化特征dmesg | grep -i kvm grep -i feature /proc/cpuinfo | sort -u | head -20ARM平台没有vmx标志可看但内核启动日志里如果能搜到kvm: using VHE字样说明VHE模式启用成功。另外还要确认内核是否包含了KVM相关的配置项grep KVM /boot/config-$(uname -r)我遇到的典型输出是CONFIG_KVMy CONFIG_KVM_ARM_HOSTy CONFIG_KVM_ARM_PMUy如果CONFIG_KVM是m模块方式说明kvm模块存在但没加载执行sudo modprobe kvm即可。如果压根没有这些配置项那就不是软件层面的问题了需要使用带KVM支持的内核这个放到第6节详述。2.2 内核版本选择与KVM相关配置RK3588常用的内核分两条线Rockchip官方BSP内核5.10或6.1以及Debian/Ubuntu的通用arm64内核。我的建议是做KVM虚拟化优先选择5.15以上的通用arm64内核原因有几点。第一5.15之后的内核对virtio-blk的io_uring支持更完善这对虚拟磁盘性能影响很直接。第二新内核的KVM模块对VHE模式的支持更稳定。第三通用内核和QEMU、libvirt的兼容性测试更充分踩坑概率低。RK3588官方BSP内核虽然对板载硬件如ES8388音频编解码器、各类传感器支持最完整但部分厂商定制内核为了裁剪体积会去掉KVM相关配置。我测试过几个第三方RK3588镜像有的/dev/kvm是存在的有的干脆没有。最简单的办法用Ubuntu官方的arm64内核替换BSP内核或者找明确声明启用了KVM的镜像。查看当前内核版本uname -a如果是5.10或6.1的rockchip BSP内核先试试dzgrep CONFIG_KVM /proc/config.gz或看/boot/config-*是否存在缺配置再考虑换内核。2.3 用户态工具链安装内核层面就绪后安装用户态工具。在Debian/Ubuntu系上一条命令搞定sudo apt update sudo apt install qemu-system-arm qemu-utils libvirt-daemon-system libvirt-clients virtinst virt-manager bridge-utils cloud-image-utils这里有几个包名容易搞混我说明一下qemu-system-arm包含aarch64系统模拟器有些发行版会单独拆出qemu-system-aarch64包装上更保险。libvirt-daemon-system提供libvirtd服务virt-manager必须依赖它。virtinst提供virt-install命令行工具批量创建虚拟机很实用。cloud-image-utils提供cloud-localds工具用于生成cloud-init的seed镜像。装完后启动libvirtd服务sudo systemctl enable --now libvirtd sudo usermod -aG libvirt $USER sudo usermod -aG kvm $USER记得重新登录终端或执行newgrp libvirt让组权限生效否则后面virsh list --all会报权限错误。到这里宿主机侧的准备就完成了继续往下走。3. 第一台虚拟机三种途径从最小系统到图形化3.1 命令行方式qemu-system-aarch64最简启动最直接的方式是手动构造QEMU命令。先把Ubuntu Server的ARM64安装镜像下载下来然后执行sudo qemu-system-aarch64 \ -machine virt,virtualizationtrue,gic-version3 \ -cpu host \ -accel kvm \ -smp 4 \ -m 4096 \ -bios /usr/share/qemu-efi-aarch64/QEMU_EFI.fd \ -drive file/path/to/ubuntu-24.04-server-arm64.iso,mediacdrom,ifvirtio \ -drive file/var/lib/libvirt/images/kvm01.img,ifvirtio,formatqcow2 \ -device virtio-net-pci,netdevnet0 \ -netdev user,idnet0 \ -nographic几个关键参数逐个说明。-machine virt是QEMU针对ARM虚拟化提供的通用machine type可以理解为一块虚拟开发板。virtualizationtrue告诉QEMU启用虚拟化扩展gic-version3对应GICv3中断控制器RK3588的GIC-500就是GICv3必须匹配。-cpu host的意思是直接把宿主机CPU的所有特性透传给guest这是ARM虚拟化性能的核心。如果改成-cpu cortex-a76这种固定模型QEMU会强制使用模拟的ARMv8 CPU特性集不包含VHE相关的硬件加速能力性能会明显下降。-nographic把串口重定向到当前终端适合SSH调试场景。如果需要图形界面把它换成-display gtk或-vnc :1。首次启动安装系统时可能会遇到比较慢的软件包下载过程这是正常的。安装完成后重启虚拟机把启动介质切换到虚拟磁盘即可。3.2 cloud image方式Ubuntu Server快速部署安装镜像方式适合需要交互式安装的场景但如果你想快速起一台无头服务器用cloud image效率高得多。Ubuntu官方提供了专门为云环境优化的ARM64镜像配合cloud-init可以做到秒级部署。下载镜像并创建基础磁盘wget https://cloud-images.ubuntu.com/noble/current/noble-server-cloudimg-arm64.img qemu-img create -f qcow2 -F qcow2 -b noble-server-cloudimg-arm64.img ubuntu-kvm01.qcow2 30G这里用了qcow2的增量镜像功能基础镜像只读所有写入都落到新建的30G差异镜像里节省磁盘空间。然后生成cloud-init的seed镜像cat user-data EOF #cloud-config ssh_pwauth: true users: - name: admin sudo: ALL(ALL) NOPASSWD:ALL shell: /bin/bash ssh_authorized_keys: - ssh-rsa AAAA... ssh-keygen chpasswd: expire: false users: - name: admin password: admin123 type: text EOF cat meta-data EOF instance-id: kvm01 local-hostname: kvm01 EOF cloud-localds seed.img user-data meta-data注意user-data里的ssh_authorized_keys默认是注释状态把你自己生成的SSH公钥填进去以后就能用密钥直接登录虚拟机比密码安全得多。然后用virt-install启动sudo virt-install \ --name kvm01 \ --ram 4096 \ --vcpus 4 \ --cpu host-passthrough \ --import \ --disk path/var/lib/libvirt/images/ubuntu-kvm01.qcow2,formatqcow2,busvirtio \ --disk path/var/lib/libvirt/images/seed.img,devicecdrom \ --network networkdefault,modelvirtio \ --os-variant ubuntunoble \ --boot uefi启动后等待一两分钟执行virsh list --all确认状态然后用virsh console kvm01或SSH登录虚拟机。3.3 virt-manager图形化适合日常管理如果命令行方式让你觉得折腾virt-manager提供了一个图形化界面来管理虚拟机生命周期。在宿主机上启动virt-manager通过SSH隧道访问开发板时如果virt-manager跑在远程开发板上、显示在本地需要加-c qemu:///system指定连接或者用ssh -X配合X11转发。不过说实话在嵌入式环境里我更习惯用virsh命令图形界面主要是方便看虚拟机状态和性能曲线。virt-manager创建虚拟机的流程和virt-install差不多选ISO或现有磁盘、配置CPU和内存、选择网络类型。它的价值在于创建完成后你可以直接在图形界面里调整CPU拓扑、添加virtio网卡、挂载USB设备不需要记一堆QEMU参数。特别是对CPU绑定的调整图形界面里拖拽几下就完成了。4. 网络打通从默认网桥到物理网络透传4.1 默认的virbr0 NAT网络virt-install创建虚拟机时如果指定--network networkdefaultlibvirt会自动创建一个NAT网桥virbr0。Guest的流量经过NAT转发到宿主机物理网卡上网这是最安全、最省事的方案尤其适合单机开发环境。NAT模式的问题是外部设备无法主动访问虚拟机。如果你只想在虚拟机上搞开发和测试NAT完全够用但如果想让虚拟机对外提供服务比如跑一个Web服务供局域网访问就需要桥接模式。查看当前默认网络的配置virsh net-list --all virsh net-dumpxml default4.2 自定义桥接网桥br0桥接模式的原理是创建一个虚拟交换机br0把物理网卡eth0和虚拟机的虚拟网卡都接到这个交换机上让虚拟机直接获取局域网IP对外表现和物理机没有区别。配置方式取决于宿主机用的网络管理工具。RK3588开发板的不同镜像差异很大有的用netplan有的用/etc/network/interfaces还有的用NetworkManager。我以netplan为例这是Ubuntu Server默认的网络管理方式。编辑/etc/netplan/01-netcfg.yamlnetwork: version: 2 renderer: networkd ethernets: eth0: dhcp4: no bridges: br0: interfaces: [eth0] dhcp4: yes parameters: stp: true forward-delay: 4执行sudo netplan apply使配置生效。如果用的是/etc/network/interfaces配置方式是这样auto lo iface lo inet loopback auto eth0 iface eth0 inet manual auto br0 iface br0 inet dhcp bridge_ports eth0 bridge_stp on bridge_fd 4这里有一个非常关键的注意事项在改网络配置前先确认自己能在断网后通过串口或物理方式接回开发板否则配置错了会导致SSH连接瞬间断开且无法恢复。我自己第一次配桥接就因为这个吃了大亏只能插显示器和键盘登进本机把配置改回来。配置生效后用bridge link确认br0已经接管了eth0再创建虚拟机时指定网络sudo virt-install \ ... --network bridgebr0,modelvirtio虚拟机启动后会自动通过DHCP获取局域网IP此时宿主机和虚拟机在同一个二层网络里你可以在局域网内的任何一台电脑上直接SSH进虚拟机。4.3 网络多队列提升吞吐量的关键设置如果虚拟机里跑的是一些网络IO密集型应用比如文件服务器、反向代理建议开启virtio-net的多队列功能。默认情况下虚拟网卡只使用单个队列所有收发包都走同一个CPU核容易形成瓶颈。libvirt XML里这样配置interface typebridge source bridgebr0/ model typevirtio/ driver namevhost queues4 host mqon/ guest mqon/ /driver /interfacedriver namevhost queues4/Virtual machine内还需要为对应的网卡开启多队列特性例如通过ethtool配置ethtool -L eth0 combined 4我实测在RK3588上开启多队列后虚拟机的iperf3吞吐从单队列的850Mbps提升到接近2.2Gbps延迟也下降了30%左右。这个调优对网络密集型应用效果显著。5. 性能调优让虚拟机跑出接近物理机的性能5.1 vCPU与线程绑定把大核留给虚拟机RK3588的大小核架构决定了它不能简单地把所有CPU资源对等看待。4个A76大核负责高性能任务4个A55小核则偏向能效。KVM虚拟化首先要把虚拟机的vCPU绑定到大核上否则调度器可能把vCPU线程丢到小核上性能直接打个六折。先查看CPU拓扑lscpu -e输出中CPU列是编号MAXMHZ列可以帮你区分大小核。在RK3588上CPU 4-7通常是大核最高频率2.4GHzCPU 0-3是小核最高频率1.8GHz。确认方式是以开发板实际输出的MAXMHZ为准。然后用virsh绑定vCPU到指定物理CPUvirsh vcpupin kvm01 0 4 virsh vcpupin kvm01 1 5 virsh vcpupin kvm01 2 6 virsh vcpupin kvm01 3 7如果直接用QEMU命令行启动可以在启动前用taskset -c 4,5,6,7绑定整个QEMU进程。但更精细的做法是用virsh的vcpupin因为QEMU进程内部有多个线程vCPU线程、IO线程、RCU线程vcpupin会把每个虚拟CPU线程精确绑定到对应物理CPU上。绑定后验证效果virsh vcpuinfo kvm01如果输出里每个vCPU的affinity都指向了4-7号CPU说明绑定成功。用sysbench测试一下CPU性能绑定前后差距可以达到15%-20%在RK3588这种大小核架构上非常明显。5.2 内存大页与锁页启用HugePagesARM平台和x86一样支持hugepage。默认4KB页表粒度下虚拟机访问内存需要频繁进行TLBTranslation Lookaside Buffer查询在虚拟化场景下这种开销会被放大。启用2MB或1GB的大页可以大幅减少TLB miss对内存密集型应用提升明显。配置宿主机大页内存echo 2048 | sudo tee /proc/sys/vm/nr_hugepages sudo mkdir -p /mnt/huge sudo mount -t hugetlbfs hugetlbfs /mnt/huge echo vm.nr_hugepages2048 | sudo tee -a /etc/sysctl.d/99-hugepages.conf echo hugetlbfs /mnt/huge hugetlbfs defaults 0 0 | sudo tee -a /etc/fstab每个2MB大页对应2048个标准页2048个大页总共占用4GB内存如果你的板子只有8GB内存建议调小到1024。QEMU启动时指定使用大页作为内存后端-m 4096 \ -mem-prealloc \ -mem-path /mnt/huge如果使用libvirt在虚拟机的XML配置中设置memoryBacking hugepages page size2048 unitKiB/ /hugepages locked/ /memoryBacking内存锁定locked元素对应QEMU的mlock功能禁止宿主内核把虚拟机内存换出到swap。在内存充裕的RK3588上这个配置能避免虚拟机的性能抖动。我实测在16GB版本的板子上给虚拟机分配8GB内存并开启locked后guest里的内存延迟稳定在ns级波动范围内。5.3 IO路径virtio-blk与cache模式选virtio而不是模拟设备ARM虚拟机的磁盘设备一定要用virtio-blk或virtio-scsi不要用QEMU模拟的SATA或IDE设备。virtio设备通过共享内存环形队列和vhost内核后端实现收发几乎不需要CPU干预而模拟设备需要逐条指令翻译IO性能差距能到10倍以上。libvirt XML中磁盘设备的配置disk typefile devicedisk driver nameqemu typeqcow2 cachenone ioio_uring/ source file/var/lib/libvirt/images/kvm01.qcow2/ target devvda busvirtio/ /diskcache模式选none还是writethrough这是我在RK3588上做了多轮测试后得出的结论cachenone绕过宿主机页缓存直接访问磁盘性能稳定但需要O_DIRECT支持。对虚拟机数据库、日志类应用最友好。cachewritethrough写入直接落盘读走缓存安全性高但写入性能损失较大。cachewriteback写入先进缓存后异步落盘性能最好但断电有数据丢失风险。如果是开发测试机用writeback体验最流畅如果是跑生产数据库老老实实none或writethrough别拿数据赌运气。io_uringioio_uring是QEMU 6.0支持的新型异步IO框架相比老的native基于libaio和threads基于线程池io_uring在并发IO场景下CPU占用更低、延迟更稳定。RK3588的存储IO吞吐有限io_uring的实际提升可能不像x86服务器上那么夸张但聊胜于无开启后可以看到iostat的%util下降。5.4 用perf和kvm_stat定位性能瓶颈性能调优不能只靠猜要用数据说话。KVM内核模块自带了一个性能统计工具kvm_stat实时显示各类vmexit事件频率sudo kvm_stat -l输出中的EXIT列表示虚拟机退出到宿主机的次数。如果你在虚拟机里跑一个高IO负载应用时看到大量的EXTERNAL_INTERRUPT说明中断被频繁转发到宿主机可能需要检查GIC虚拟化配置如果看到大量MMIO_EXIT_ABORT说明设备模拟开销过大考虑换成virtio设备。更细粒度的分析可以用perfsudo perf kvm stat record -a -- sleep 30 sudo perf kvm stat report这会统计guest和host各自的花费时间比例。在RK3588上我观察到开启VHE之后guest syscall的开销相比非VHE模式有了显著下降这也是为什么RK3588上KVM性能表现不错的原因——VHE让KVM几乎变成一个高性能特权的进程。5.5 CPU频率调节别让大核睡懒觉RK3588的CPU调频器默认是schedutil或ondemand它会根据负载动态调整频率。问题在于虚拟机里的负载在宿主机看来是QEMU进程的CPU占用率调度器对这种负载的响应存在一定延迟。结果就是虚拟机上高负载任务启动的瞬间CPU频率可能来不及升高导致前几百毫秒性能偏低。解决方式宿主机切换到performance模式让CPU保持最高频率运行。sudo apt install linux-tools-common cpufrequtils sudo cpupower frequency-set -g performance代价是功耗会升高但RK3588即使满载也才10瓦左右对于虚拟化性能提升来说是值得的。如果在意功耗可以只在跑虚拟机的期间临时切换用完改回schedutil。6. 实踩的坑RK3588上的KVM排错记录6.1 /dev/kvm不存在的排查链路这是RK3588上KVM最经典的问题。症状是qemu启动时报错Could not access KVM kernel module: No such file or directory failed to initialize KVM: No such file or directory很多人第一反应是重装qemu其实没用。正确排查链路如下第一步确认内核是否包含KVM配置cat /boot/config-$(uname -r) | grep KVM如果没有输出说明内核没编译KVM支持。这种情况优先考虑使用包含KVM的通用arm64内核因为第三方RK3588镜像为了追求启动速度和精简体积经常把KVM从内核配置里删掉。第二步确认模块状态lsmod | grep kvm如果内核支持但没加载手动加载sudo modprobe kvm第三步确认模块加载时是否出了问题dmesg | grep -i kvm如果看到kvm: module verification failed: signature and/or required key missing说明模块签名有问题需要重新编译或换一个内核。建议直接在官网或社区找一个声明启用KVM的RK3588内核镜像比自己编译内核省时得多。这也是我踩过最深的一个坑换了三个镜像才找到支持KVM的。6.2 Guest报ACPI suspend相关警告启动虚拟机时如果guest内核日志里出现类似这样的警告ACPI: [Firmware Bug] BIOS _OSI(Linux) query ignored ACPI: sleep states S3/S4 not supported不用太紧张。这是ARM服务器ACPI表的常见现象QEMU自带的virt machine type并没有完整实现所有ACPI sleep状态尤其是S3suspend to RAM和S4suspend to disk。qemu的virt平台设计时就把电源管理做得比较简虚拟机里执行systemctl suspend大概率会失败或行为异常。解决方案如果不需要休眠功能在guest的/etc/default/grub里给内核加上acpi_osiLinux参数或者直接无视警告。我实测除了影响powertop等电源管理工具的显示外对KVM运行没有任何负面影响。6.3 qemu的CPU模型不匹配启动时报错qemu-system-aarch64: -cpu host: this feature is not supported by the machine type这是QEMU版本和machine type兼容性问题。解决方案有两种第一升级QEMU到较新版本Ubuntu 24.04自带的QEMU 8.x对cpu host的支持已经很完善。第二在-machine参数里增加virtualizationtrue标志确保虚拟化扩展被显式启用。有时候还会碰到kvm_init_vcpu failed错误多数时候和CPU特性透传有关。可以先用-cpu cortex-a76凑合启动但性能会下降建议优先解决QEMU和内核的版本匹配问题。6.4 桥接配置后宿主机断网这是第4节埋的坑的实战版本。症状执行netplan apply后SSH连接断开物理网卡eth0不再有IPbr0也没有正确获得IP宿主机彻底失联。原因往往是netplan配置里eth0的dhcp4没有关干净或者bridge和物理网卡同时配置了IP导致路由冲突。恢复步骤通过串口或本地显示器登入系统。备份当前配置sudo cp /etc/netplan/01-netcfg.yaml /etc/netplan/01-netcfg.yaml.bak。恢复物理网卡DHCP配置把bridge配置删掉sudo netplan apply恢复网络。确认恢复后再逐步调试bridge配置而不是一次性改完盲目apply。一个常见的坑是物理网卡在配置bridge后仍然保留了IP地址导致bridge内出现两个IP来源路由表混乱。正确做法是物理网卡只做manual所有IP配置全部放在br0上。如果你怀疑配置有问题但已经断网还可以在netplan里加renderer: NetworkManager然后用NetworkManager的nmcli命令交互式创建bridge这在调试阶段更直观。6.5 虚拟机里CPU频率信息异常启动虚拟机后guest的/sys/devices/system/cpu/cpu*/cpufreq/可能为空lscpu显示的CPU频率也不正常。这不是KVM的bug而是QEMU的virtmachine type默认没有提供虚拟CPU调频接口。ARM服务器上CPU调频通常是固件SCPI/SMCCC层面的功能QEMU里默认不模拟。解决方式在虚拟机的启动参数或libvirt配置中添加ACPI CPPC支持或者在QEMU machine参数上增加acpion。但坦白说在ARM虚拟化里这个功能属于锦上添花不影响KVM本身的运算性能。我在跑虚拟机的实际使用中发现guest里看到的CPU频率往往固定在CPU最大频率这反而是好事——说明guest的负载可以直接充分利用大核算力不需要经过调频器的延迟。6.6 Ubuntu 24.04上libvirt-qemu用户权限问题有时候virsh start kvm01会报权限错误常见的是error: Failed to start domain kvm01 error: internal error: qemu unexpectedly closed the monitor查看/var/log/libvirt/qemu/kvm01.log如果看到Permission denied相关日志多半是磁盘镜像的属主不对。libvirt默认以libvirt-qemu用户运行QEMU进程所以磁盘镜像需要让这个用户可读可写sudo chown -R libvirt-qemu:kvm /var/lib/libvirt/images/ sudo chmod 750 /var/lib/libvirt/images/这个问题在网络文件系统或手工拷贝qcow2镜像时尤其常见因为copy命令默认保留文件属主为当前用户。关于RK3588上的KVM我最后想说的是这块芯片的虚拟化能力其实是被低估的。很多人在RK3588上只跑单系统做开发或部署应用没有意识到把系统改造为虚拟化宿主后一块板子能顶三块用——隔离的开发环境、独立的测试环境、临时的业务环境互不干扰。而借助VHE、virtio这些成熟的虚拟化基础性能损耗比想象中小得多。如果你手里正好有一块吃灰的RK3588开发板不妨按这篇文章的路径把它变成一台低功耗虚拟化服务器体验一下在ARM平台上管控多套系统的手感。