Home / Guide anti-trappola / Elenco di verifica incrociata KVM e QEMU per identificare il fornitore cloud su server

Elenco di verifica incrociata KVM e QEMU per identificare il fornitore cloud su server

Identificare il tipo di virtualizzazione del fornitore cloud con metodi riproducibili

Aggiornato 2026-08-27 · CloudWorth

KVMQEMUidentificazione fornitore cloudrilevamento virtualizzazioneSteal TimeCloudWorthOverselling VPSBenchmark VPS

Elenco di verifica incrociata KVM e QEMU per identificare il fornitore cloud su server

Verifica incrociata a quattro dimensioni: dmesg, DMI, virtio, Steal Time, per identificare in modo riproducibile il fornitore cloud KVM.

Segni di KVM in dmesg

Quando si riceve un server cloud, il primo passo non è eseguire systemd-detect-virt, ma guardare i log del kernel. dmesg è la "confessione" più onesta, perché il livello di virtualizzazione KVM/QEMU lascia prove concrete all'avvio. Il caso più tipico è la comparsa diretta di scritte come KVM: disabled by BIOS o KVM: vcpu 0, cpu 0, ma i fornitori cloud spesso ripuliscono i log. Un segnale più affidabile sono le tabelle ACPI e i dispositivi PCI: eseguendo dmesg | grep -i -E 'kvm|qemu|virtio|hypervisor', se si vede Hypervisor detected: KVM, si può essere quasi certi.

Ma l'assenza di queste parole chiave in dmesg non significa che non sia KVM: molti fornitori usano firmware personalizzati. In tal caso, bisogna guardare dmesg | grep -i smbios o i file sotto /sys/class/dmi/id/. Un altro indizio nascosto è la sorgente del clock: i guest KVM mostrano spesso clocksource: tsc o kvm-clock, mentre Xen di solito ha xen. Verificare con cat /sys/devices/system/clocksource/clocksource0/current_clocksource: se restituisce kvm-clock, l'identità KVM è confermata.

Suggerimento forense: il timestamp -T di dmesg aiuta a confermare se il livello di virtualizzazione è stato caricato all'inizio del boot o se è stato iniettato dinamicamente in seguito — quest'ultimo caso è spesso virtualizzazione annidata.

Dedurre il vendor dal nome prodotto DMI

Guardare solo dmesg può trarre in inganno, perché i comportamenti KVM di Alibaba Cloud, Tencent Cloud e AWS sono sostanzialmente identici. In questo caso bisogna ricorrere a DMI/SMBIOS, il "database di impronte dei vendor". cat /sys/class/dmi/id/product_name e cat /sys/class/dmi/id/sys_vendor sono i due comandi che dovresti ricordare di più.

Le stringhe del firmware QEMU dei vari cloud provider differiscono molto: Alibaba Cloud restituisce spesso Alibaba Cloud ECS, Tencent Cloud è TencentCloud, Huawei Cloud è Huawei Cloud, e anche se Nitro di AWS non è KVM tradizionale, le generazioni precedenti mostrano ancora Xen o KVM. Per Microsoft Azure è comune vedere Microsoft Corporation più Virtual Machine. Se vedi QEMU Standard PC (i440FX + PIIX, 1996), significa che il vendor non ha modificato il template: questo di per sé è un segnale identificativo.

Un metodo più avanzato consiste nel confrontare direttamente le informazioni di System Information e Baseboard da dmidecode -t 1 e dmidecode -t 2. Va notato: alcuni piccoli IDC modificano le stringhe DMI per fingere di essere grandi provider, quindi il DMI deve essere incrociato con i dispositivi virtio e Steal Time. Se vuoi verificare rapidamente l'identità del tuo server cloud, puoi usare la pagina di rilevamento gratuito di CloudWorth: /app, che combina più percorsi /sys per determinarlo automaticamente.

Elenco dispositivi virtio per rilevare KVM

virtio è il framework di I/O paravirtualizzato di KVM/QEMU: se compare un dispositivo virtio, siamo sostanzialmente in ambito KVM (Xen e OpenVZ non usano questo meccanismo). Il comando di verifica è ls -l /sys/bus/virtio/devices/, oppure lspci | grep -i virtio. Vedrai directory come virtio0, virtio1, che rappresentano dispositivi a blocchi, schede di rete, palloncini (balloon) ecc.

Per una rilevazione più precisa bisogna guardare l'ID del vendor PCI: lspci -nn | grep -i -E '1af4|virtio', dove 0x1af4 è l'ID ufficiale del vendor PCI di Red Hat/virtio. Se la scheda di rete mostra Red Hat, Inc. Virtio network device, siamo assolutamente su KVM/QEMU. Allo stesso modo, se il dispositivo a blocchi è Virtio block device, significa che anche il disco segue il percorso virtio.

Se non vuoi usare lspci, puoi incrociare /proc e /sys: controlla se in cat /proc/bus/pci/devices compare 1af4, oppure usa find /sys/devices -name 'virtio'. Nota: le nuove Amazon Nitro e alcuni cloud provider possono usare EFA o ENA al posto della pura scheda di rete virtio, ma il dispositivo a blocchi resta virtio, quindi dai priorità al controller del disco. Quando nella directory virtio compaiono le sottodirectory block e net, si può quasi escludere la modalità PV di OpenVZ e Xen.

Steal Time: individuare l'overbooking

Identificare il fornitore cloud KVM è solo il primo passo; il punto cruciale è determinare se questo server cloud ha specifiche gonfiate. Steal Time (tempo rubato) è il tempo CPU sottratto all'ospite KVM dall'hypervisor. Più alto è il valore, più grave è l'overbooking della macchina fisica. Il modo più semplice per leggere questa metrica è la colonna %st in top, ma il metodo più preciso è osservare il campo steal in /proc/stat.

A partire dal kernel Linux 2.6.26, sono state apportate numerose ottimizzazioni all'orologio KVM e all'I/O di rete, rendendo la misurazione di Steal Time più affidabile. Se la colonna st di vmstat 1 è costantemente superiore al 5%, oppure l'ottavo numero (il tick di steal) di cat /proc/stat | grep '^cpu ' continua a crescere, significa che la tua vCPU viene spesso sottratta dai vicini. Ecco una serie di comandi per la verifica sul campo:

# 每2秒采样一次,观察 st 列
vmstat 1 5
# 查累计 steal 时间(单位:jiffies)
awk '/^cpu / {print "steal:", $8}' /proc/stat
# 用 mpstat 看单核被偷比例
mpstat -P ALL 1 2

Un metodo più drastico è il "confronto tra maratona della CPU e Steal": esegui stress-ng --cpu 4 per cinque minuti, registrando contemporaneamente %steal da mpstat. Se il tasso medio di furto supera il 10%, si può sostanzialmente concludere che l'overbooking è grave; prima del rinnovo, confronta i prezzi per un nuovo acquisto. Per calcolare la differenza tra il tuo piano attuale e lo sconto per nuovi utenti, puoi consultare lo strumento di confronto prezzi per server cloud di CloudWorth: /app. Ricorda: un Steal Time elevato non significa che il provider non sia affidabile, ma indica una "ridondanza insufficiente delle risorse della macchina fisica", un fattore importante per le decisioni di rinnovo e migrazione. Incrociando dmesg, DMI, virtio e Steal Time, puoi identificare con precisione forense il fornitore cloud e il livello di prestazioni reale.

FAQ

Come identificare il fornitore cloud KVM tramite dmesg?

Esegui dmesg | grep -i kvm e controlla se ci sono log relativi a KVM; se compaiono, conferma la virtualizzazione KVM.

Come risalire al fornitore cloud dal nome del prodotto DMI?

Esegui dmidecode -s system-product-name; l'output come Alibaba Cloud ECS, KVM, ecc., consente di determinare il fornitore.

Come verificare KVM con l'elenco dei dispositivi virtio?

Controlla lspci o ls /dev/vd*; la presenza di dischi e schede di rete virtio di solito indica una piattaforma KVM.

Verifica incrociata a quattro dimensioni: dmesg, DMI, virtio, Steal Time, per identificare in modo riproducibile il fornitore cloud KVM.

Avvia il rilevamento gratuito →