The question, in an arch-general thread about qemu-kvm: is this virtual machine running with KVM acceleration? The era supplied plenty of misleading places to look—separate qemu and qemu-kvm packages, symlinked binary names, libvirt configuration in between. Those named the intended setup; I wanted to know what the running process was doing.
The exchange points to two checks, aimed at different claims.
Step one: what was requested. Inspect the emulator’s actual command line—the argv of the running process—for -enable-kvm or its equivalent. The interesting question was whether libvirt invoked QEMU with acceleration requested, not which package installed the binary or what the executable happened to be named. A filesystem full of kvm-ish names proves nothing about what the invocation asked for.
Step two: the runtime check I was considering. Check whether the running process holds the KVM system device open:
$ lsof /dev/kvmI had not run that check yet in the thread. /dev/kvm is the entry point to the kernel API, so an open handle would be stronger evidence than a package name or command-line promise. The KVM API is organized around a system descriptor which creates VM descriptors, which in turn create vCPU and device descriptors; a VM’s lifetime belongs to its VM descriptor. A current investigation should inspect the process’s full descriptor table for those KVM objects or use the hypervisor’s own runtime telemetry. lsof /dev/kvm remains a useful clue, not proof by itself.
The same approach appears in checking a binary’s library paths: inspect the requested configuration, then the resources the running process holds.