クラウドサーバーでのクラウドベンダー特定：KVMとQEMUのクロス検証チェックリスト

再現可能な方法でクラウドベンダーの仮想化タイプを特定

更新 2026-08-27 · CloudWorth

KVMQEMUクラウドベンダー特定仮想化検出Steal TimeCloudWorthVPSオーバーセールVPS検証

4次元クロス検証：dmesg、DMI、virtio、Steal Timeにより、KVMクラウドベンダーを再現可能に特定します。

dmesg に見られる KVM の兆候

クラウドサーバーを手にしたら、最初のステップは systemd-detect-virt を実行することではなく、まずカーネルログを確認することです。dmesg は最も正直な「自白書」です。KVM/QEMU の仮想化レイヤーは起動時に確固たる証拠を残すからです。最も典型的なのは、KVM: disabled by BIOS や KVM: vcpu 0, cpu 0 といった文字が直接現れることですが、クラウドベンダーはログをきれいに拭き取ってしまうことがよくあります。より信頼できるシグナルは ACPI テーブルと PCI デバイス です。dmesg | grep -i -E 'kvm|qemu|virtio|hypervisor' を実行し、Hypervisor detected: KVM が表示されれば、ほぼ特定できます。

しかし、dmesg にこれらのキーワードが無くても KVM ではないとは限りません。多くのベンダーはカスタムファームウェアを使用しています。その場合は、dmesg | grep -i smbios を確認するか、/sys/class/dmi/id/ 以下のファイルを併用します。もう一つの隠れた手がかりは クロックソース です。KVM ゲストではしばしば clocksource: tsc または kvm-clock と表示され、Xen では通常 xen です。cat /sys/devices/system/clocksource/clocksource0/current_clocksource で検証し、kvm-clock が返れば、KVM であることが確定します。

フォレンジックのアドバイス：dmesg の -T タイムスタンプを使うと、仮想化レイヤーが起動初期に読み込まれたのか、後から動的に注入されたのかを確認できます。後者は多くの場合、入れ子仮想化です。

DMI製品名からベンダーを逆引きする

dmesgを見ただけでは誤判定しやすい。なぜなら阿里雲、騰訊雲、AWSのKVM動作は基本的に同じだからだ。ここで DMI/SMBIOS という「ベンダー指紋ライブラリ」を使う。cat /sys/class/dmi/id/product_name と cat /sys/class/dmi/id/sys_vendor は最も覚えるべき2つのコマンドだ。

各クラウドベンダーのQEMUファームウェア文字列は大きく異なる：阿里雲はよく Alibaba Cloud ECS を返し、騰訊雲は TencentCloud、華為雲は Huawei Cloud、AWSのNitroは伝統的なKVMではないが、旧世代の機種では依然として Xen や KVM と表示されることがある。マイクロソフトAzureでは Microsoft Corporation に続けて Virtual Machine が見られることが多い。QEMU Standard PC (i440FX + PIIX, 1996) が表示された場合、ベンダーがテンプレートを変更する手間を省いたことを意味しており、これ自体が識別シグナルとなる。

高度な方法としては、dmidecode -t 1 と dmidecode -t 2 のSystem InformationとBaseboard情報を直接比較する。注意してほしいのは、一部のIDC小規模事業者はDMI文字列を「魔改造」して大企業を装うことがあるため、DMIはvirtioデバイスやSteal Timeと相互検証しなければならない。自分のクラウドサーバーの身元を素早く検証したいなら、まずCloudWorthの無料検出ページを実行しよう：/app で、複数の /sys パスを組み合わせて自動判定してくれる。

virtioデバイスリストでKVMを判定

virtio は KVM/QEMU の半仮想化 I/O フレームワークであり、virtio デバイスが存在すれば、基本的には KVM 陣営です（Xen と OpenVZ はこの方式を使いません）。確認コマンドは ls -l /sys/bus/virtio/devices/、または lspci | grep -i virtio です。virtio0、virtio1 のようなディレクトリが見え、ブロックデバイス、NIC、バルーンなどを表します。

より正確に判定するには、PCI ベンダー ID を確認します: lspci -nn | grep -i -E '1af4|virtio'。ここで 0x1af4 は Red Hat/virtio の公式 PCI ベンダー ID です。NIC が Red Hat, Inc. Virtio network device と表示されていれば、間違いなく KVM/QEMU です。同様に、ブロックデバイスが Virtio block device であれば、ディスクも virtio 経由であることを示します。

lspci を使いたくない場合は、/proc と /sys で相互検証できます: /proc/bus/pci/devices に 1af4 が含まれているか、find /sys/devices -name 'virtio' を実行します。注意: 新しい AWS Nitro や一部のクラウドベンダーは、純粋な virtio NIC の代わりに EFA や ENA を使用しますが、ブロックデバイスは virtio のままなので、ディスクコントローラを優先的に確認してください。virtio ディレクトリ内に block と net サブディレクトリが存在する場合、OpenVZ と Xen の PV モードはほぼ除外できます。

Steal Timeによる虚偽表示の識別

KVMクラウドベンダーを特定するのは最初の一歩に過ぎず、このクラウドサーバーに「虚偽表示」があるかどうかを判断することが重要です。Steal Time（stolen time）は、KVMゲスト内でホストに奪われたCPU時間であり、値が高いほど物理マシンのオーバーコミットが深刻であることを示します。指標を読む最も簡単な方法は top の %st ですが、より正確には /proc/stat の steal フィールドを確認します。

Linuxカーネル2.6.26以降、KVMのクロックとネットワークI/Oに多くの最適化が行われ、Steal Timeの計測もより信頼できるようになりました。vmstat 1 の st 列が長期間5%を超える場合、または cat /proc/stat | grep '^cpu ' の8番目の数字（stealタイムスライス）が増加し続ける場合、vCPUが頻繁に隣接インスタンスに奪われていることを意味します。以下は現場で検証するためのコマンド群です：

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

より強力なテスト方法は「CPUマラソン + Steal比較」です。stress-ng --cpu 4 を5分間実行し、同時に mpstat の %steal を記録します。平均盗まれ率が10%を超える場合、基本的にオーバーコミットが深刻であると判断でき、更新前に新規購入価格と比較する必要があります。現在のプランと新規ユーザー割引の差を計算したい場合は、CloudWorthのクラウドサーバー比較ツールを参照してください：/app。覚えておいてください：Steal Timeが高いことはサービスプロバイダーが信頼できないことを意味するのではなく、「物理マシンのリソース冗長性が不足している」ことを意味し、更新や移行の判断における重要な参考材料です。dmesg、DMI、virtio、Steal Timeの4つを相互に照合することで、フォレンジックのようにクラウドベンダーと実際のパフォーマンスレベルを正確に確認できます。