Identification du fournisseur cloud : liste de vérification croisée KVM et QEMU

Utilisez une méthode reproductible pour identifier le type de virtualisation du fournisseur cloud

Mis à jour 2026-08-27 · CloudWorth

KVMQEMUIdentification du fournisseur cloudDétection de virtualisationSteal TimeCloudWorthSurvente VPSBenchmark VPS

Vérification croisée à quatre dimensions : dmesg, DMI, virtio, Steal Time, pour une identification reproductible du fournisseur cloud KVM.

Signes de KVM dans dmesg

Quand on reçoit un serveur cloud, la première étape n'est pas de lancer systemd-detect-virt, mais de regarder les logs du noyau. dmesg est le « livre d'aveux » le plus honnête, car la couche de virtualisation KVM/QEMU laisse des preuves solides au démarrage. Le plus typique est l'apparition directe de mentions comme KVM: disabled by BIOS ou KVM: vcpu 0, cpu 0, mais les fournisseurs cloud ont souvent tendance à nettoyer les logs. Un signal plus fiable est la table ACPI et les périphériques PCI : exécutez dmesg | grep -i -E 'kvm|qemu|virtio|hypervisor', et si vous voyez Hypervisor detected: KVM, c'est pratiquement confirmé.

Mais l'absence de ces mots-clés dans dmesg ne signifie pas que ce n'est pas KVM — de nombreux fournisseurs utilisent un firmware personnalisé. Dans ce cas, il faut examiner dmesg | grep -i smbios ou les fichiers sous /sys/class/dmi/id/. Un autre indice subtil est la source d'horloge : les invités KVM affichent souvent clocksource: tsc ou kvm-clock, alors que Xen utilise généralement xen. Vérifiez avec cat /sys/devices/system/clocksource/clocksource0/current_clocksource ; si cela renvoie kvm-clock, l'identité KVM est confirmée.

Conseil de forensique : l'horodatage -T de dmesg peut vous aider à déterminer si la couche de virtualisation a été chargée au début du démarrage ou injectée dynamiquement plus tard — cette dernière étant généralement de la virtualisation imbriquée.

Déduire le fournisseur via le nom de produit DMI

Se fier uniquement à dmesg peut prêter à confusion, car les comportements KVM d'Alibaba Cloud, Tencent Cloud et AWS sont essentiellement identiques. Il faut alors faire appel à DMI/SMBIOS, cette « base d'empreintes de fournisseurs ». Les commandes cat /sys/class/dmi/id/product_name et cat /sys/class/dmi/id/sys_vendor sont les deux commandes à retenir en priorité.

Les chaînes de firmware QEMU varient considérablement d'un fournisseur cloud à l'autre : Alibaba Cloud renvoie souvent Alibaba Cloud ECS, Tencent Cloud TencentCloud, Huawei Cloud Huawei Cloud, et bien que le Nitro d'AWS ne soit pas du KVM traditionnel, les anciennes générations affichent encore Xen ou KVM. Microsoft Azure présente couramment Microsoft Corporation suivi de Virtual Machine. Si vous voyez QEMU Standard PC (i440FX + PIIX, 1996), cela indique que le fournisseur n'a pas pris la peine de modifier le modèle, ce qui constitue en soi un signal d'identification.

Une méthode plus avancée consiste à comparer directement les informations System Information et Baseboard de dmidecode -t 1 et dmidecode -t 2. Il convient de noter que certains petits fournisseurs IDC « maquillent » les chaînes DMI pour se faire passer pour de grands fournisseurs ; le DMI doit donc être recoupé avec les périphériques virtio et le Steal Time. Pour vérifier rapidement l'identité de votre serveur cloud, vous pouvez d'abord utiliser la page de détection gratuite de CloudWorth : /app, qui combine automatiquement plusieurs chemins /sys pour déterminer votre environnement.

Détection de KVM via la liste des périphériques virtio

virtio est le framework d'E/S de paravirtualisation de KVM/QEMU. Dès qu'un périphérique virtio est présent, vous êtes essentiellement dans le camp de KVM (Xen et OpenVZ n'utilisent pas ce mécanisme). Pour vérifier, utilisez ls -l /sys/bus/virtio/devices/ ou lspci | grep -i virtio. Vous verrez des répertoires comme virtio0, virtio1, représentant des blocs, des cartes réseau, des ballons, etc.

Pour une détection plus précise, examinez l'ID du fabricant PCI : lspci -nn | grep -i -E '1af4|virtio' ; 0x1af4 est l'ID du fabricant PCI officiel de Red Hat/virtio. Si la carte réseau affiche Red Hat, Inc. Virtio network device, c'est absolument KVM/QEMU. De même, si le périphérique de bloc est un Virtio block device, cela signifie que le disque suit également le chemin virtio.

Si vous ne voulez pas utiliser lspci, vous pouvez recouper avec /proc et /sys : vérifiez la présence de 1af4 dans cat /proc/bus/pci/devices, ou find /sys/devices -name 'virtio'. Notez que les nouvelles générations d'AWS Nitro et certains fournisseurs de cloud remplacent les cartes réseau purement virtio par des EFA ou ENA, mais les périphériques de bloc restent en virtio, donc privilégiez le contrôleur de disque. Lorsque les sous-répertoires block et net apparaissent dans le répertoire virtio, vous pouvez presque exclure les modes PV d'OpenVZ et de Xen.

Steal Time pour détecter la surévaluation

Reconnaître le fournisseur KVM n'est que la première étape ; déterminer si ce serveur cloud a des spécifications « gonflées » est la clé. Steal Time (temps volé) est le temps CPU accaparé par l'hôte dans une machine invitée KVM. Plus la valeur est élevée, plus la surallocation de la machine physique est grave. Le moyen le plus simple de lire cette métrique est %st dans top, mais plus précisément, il faut regarder le champ steal dans /proc/stat.

Depuis le noyau Linux 2.6.26, de nombreuses optimisations ont été apportées à l'horloge KVM et aux I/O réseau, rendant la mesure de Steal Time plus fiable. Si la colonne st de vmstat 1 est durablement supérieure à 5 %, ou si le 8e chiffre (le créneau de temps steal) de cat /proc/stat | grep '^cpu ' augmente continuellement, cela signifie que vos vCPU sont souvent volés par les voisins. Voici une série de commandes de vérification sur le terrain :

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

Une méthode de test plus agressive est la « course CPU + comparaison Steal » : lancez stress-ng --cpu 4 pendant cinq minutes, tout en enregistrant %steal de mpstat. Si le taux de vol moyen dépasse 10 %, on peut essentiellement conclure que la surallocation est grave, et il faut comparer le prix d'achat avant de renouveler. Pour calculer la différence entre votre forfait actuel et la remise pour nouveaux utilisateurs, consultez l'outil de comparaison de serveurs cloud de CloudWorth : /app. N'oubliez pas : un Steal Time élevé ne signifie pas que le fournisseur n'est pas fiable, mais cela implique une « redondance insuffisante des ressources de la machine physique », ce qui est une référence importante pour les décisions de renouvellement et de migration. En croisant dmesg, DMI, virtio et Steal Time, vous pouvez identifier avec précision, comme dans une enquête, le fournisseur cloud et le niveau de performance réel.