Cloud Server Identification of Cloud Providers: KVM and QEMU Cross-Validation Checklist

Identify cloud provider virtualization type with reproducible methods

Updated 2026-08-27 · CloudWorth

KVMQEMUCloud Provider IdentificationVirtualization DetectionSteal TimeCloudWorthVPS oversellingVPS benchmark

Four-dimensional cross-validation: dmesg, DMI, virtio, Steal Time, reproducible identification of KVM cloud providers.

KVM Clues in dmesg

When you get a cloud server, the first step is not to run systemd-detect-virt, but to check the kernel log. dmesg is the most honest "confession," because the KVM/QEMU virtualization layer leaves hard evidence during boot. The most typical is directly seeing lines like KVM: disabled by BIOS or KVM: vcpu 0, cpu 0, but cloud providers often clean up the logs. A more reliable signal is the ACPI tables and PCI devices: run dmesg | grep -i -E 'kvm|qemu|virtio|hypervisor' — if you see Hypervisor detected: KVM, you can basically lock it in.

But the absence of these keywords in dmesg doesn't mean it's not KVM—many vendors use custom firmware. In that case, look at dmesg | grep -i smbios or check the files under /sys/class/dmi/id/. Another subtle clue is the clock source: KVM guests often show clocksource: tsc or kvm-clock, while Xen typically shows xen. Verify with cat /sys/devices/system/clocksource/clocksource0/current_clocksource — if it returns kvm-clock, the KVM identity is confirmed.

Forensic tip: The -T timestamp in dmesg can help you determine whether the virtualization layer was loaded early during boot or dynamically injected later—the latter is usually nested virtualization.

Reverse-engineering vendor from DMI product name

Looking only at dmesg can easily mislead, because Alibaba Cloud, Tencent Cloud, and AWS behave basically the same in KVM. At this point you need to use DMI/SMBIOS, the "vendor fingerprint database". cat /sys/class/dmi/id/product_name and cat /sys/class/dmi/id/sys_vendor are the two commands you should remember most.

The QEMU firmware strings from various cloud vendors differ greatly: Alibaba Cloud often returns Alibaba Cloud ECS, Tencent Cloud returns TencentCloud, Huawei Cloud returns Huawei Cloud. AWS's Nitro is not traditional KVM, but older generation machines still show Xen or KVM. Microsoft Azure commonly shows Microsoft Corporation plus Virtual Machine. If you see QEMU Standard PC (i440FX + PIIX, 1996), it means the vendor was too lazy to change the template, which itself is a recognition signal.

A more advanced method is to directly compare the System Information and Baseboard information from dmidecode -t 1 and dmidecode -t 2. One thing to note: some small IDC vendors may "modify" DMI strings to disguise themselves as big vendors, so DMI must be cross-validated with virtio devices and Steal Time. If you want to quickly verify your cloud server's identity, you can first run it through CloudWorth's free detection page: /app, which will combine multiple /sys paths to automatically determine.

Detect KVM via virtio device list

virtio is the paravirtualized I/O framework of KVM/QEMU. As long as a virtio device appears, it is basically the KVM camp (Xen and OpenVZ do not use this). The check commands are ls -l /sys/bus/virtio/devices/, or lspci | grep -i virtio. You will see directories like virtio0, virtio1, which represent block devices, network cards, balloons, etc.

For a more precise determination, look at the PCI vendor ID: lspci -nn | grep -i -E '1af4|virtio', where 0x1af4 is the official PCI vendor ID of Red Hat/virtio. If the network card shows Red Hat, Inc. Virtio network device, it is definitely KVM/QEMU. Similarly, if the block device is a Virtio block device, it means the disk also goes through the virtio path.

If you don't want to use lspci, you can cross-verify with /proc and /sys: check whether 1af4 exists in cat /proc/bus/pci/devices, or use find /sys/devices -name 'virtio'. Note: the new AWS Nitro and some cloud providers use EFA or ENA to replace pure virtio network cards, but block devices still retain virtio, so prioritize checking the disk controller. When the virtio directory contains block and net subdirectories, it is almost possible to rule out the PV modes of OpenVZ and Xen.

Identifying Inflated Specs with Steal Time

Identifying the KVM cloud provider is only the first step; the key is determining whether this cloud server has inflated specs. Steal Time (stolen time) is the CPU time preempted by the host in a KVM guest. The higher the value, the more severe the physical machine oversubscription. The simplest way to read this metric is %st in top, but a more accurate way is to look at the steal field in /proc/stat.

Since Linux kernel 2.6.26, extensive optimizations have been made to KVM clock and network I/O, which also made Steal Time measurement more reliable. If the st column in vmstat 1 remains above 5% for a long time, or the 8th number (steal time slice) in cat /proc/stat | grep '^cpu ' keeps growing, it means your vCPU is often stolen by neighbors. Here are some on-site verification commands:

# Sample every 2 seconds, observe the st column
vmstat 1 5
# Check cumulative steal time (in jiffies)
awk '/^cpu / {print "steal:", $8}' /proc/stat
# Use mpstat to see the stolen ratio per core
mpstat -P ALL 1 2

A more aggressive test is the "CPU Marathon + Steal Comparison": run stress-ng --cpu 4 for five minutes while recording %steal from mpstat. If the average steal rate exceeds 10%, you can basically conclude that oversubscription is severe. Before renewing, compare the renewal price with the price for a new purchase. To calculate the difference between your current plan and a new-user discount, check out CloudWorth's cloud server price comparison tool: /app. Remember: High Steal Time doesn't mean the provider is unreliable, but it does mean there is insufficient physical machine resource redundancy, which is an important reference for renewal and migration decisions. By cross-referencing dmesg, DMI, virtio, and Steal Time, you can precisely identify the cloud provider and the real performance level, just like forensic analysis.