Servidores de nuvem: identificação do provedor de nuvem com verificação cruzada KVM e QEMU

Identifique o tipo de virtualização do provedor de nuvem com método reprodutível

Atualizado 2026-08-27 · CloudWorth

KVMQEMUidentificação de provedor de nuvemdetecção de virtualizaçãoSteal TimeCloudWorthOverselling VPSBenchmark VPS

Verificação cruzada em quatro dimensões: dmesg, DMI, virtio, Steal Time, para identificar reprodutivelmente provedores de nuvem KVM.

Sinais de KVM no dmesg

Ao obter um servidor em nuvem, o primeiro passo não é rodar systemd-detect-virt, mas sim olhar os logs do kernel. O dmesg é a "confissão" mais honesta, porque a camada de virtualização KVM/QEMU deixa evidências concretas durante a inicialização. O mais típico é aparecer diretamente algo como KVM: disabled by BIOS ou KVM: vcpu 0, cpu 0, mas os provedores de nuvem geralmente limpam os logs. Um sinal mais confiável são as tabelas ACPI e dispositivos PCI: execute dmesg | grep -i -E 'kvm|qemu|virtio|hypervisor' e, se você vir Hypervisor detected: KVM, pode praticamente confirmar.

Mas a ausência dessas palavras-chave no dmesg não significa que não seja KVM — muitos fabricantes usam firmware personalizado. Nesse caso, é preciso verificar dmesg | grep -i smbios ou os arquivos em /sys/class/dmi/id/. Outra pista sutil é a fonte de clock: clientes KVM frequentemente exibem clocksource: tsc ou kvm-clock, enquanto Xen geralmente usa xen. Use cat /sys/devices/system/clocksource/clocksource0/current_clocksource para verificar; se retornar kvm-clock, a identidade KVM está confirmada.

Dica de investigação: o timestamp -T do dmesg ajuda a confirmar se a camada de virtualização foi carregada no início da inicialização ou se foi injetada dinamicamente depois — o último caso geralmente indica virtualização aninhada.

Inferindo o fabricante pelo nome do produto DMI

Apenas olhar o dmesg pode levar a erros, pois o comportamento do KVM da Alibaba Cloud, Tencent Cloud e AWS é basicamente o mesmo. Nesse caso, é preciso usar o DMI/SMBIOS, o "banco de impressões digitais dos fabricantes". cat /sys/class/dmi/id/product_name e cat /sys/class/dmi/id/sys_vendor são os dois comandos mais importantes de lembrar.

As strings de firmware QEMU dos vários provedores de nuvem variam muito: a Alibaba Cloud geralmente retorna Alibaba Cloud ECS, a Tencent Cloud retorna TencentCloud, a Huawei Cloud retorna Huawei Cloud, e o Nitro da AWS, embora não seja KVM tradicional, ainda exibe Xen ou KVM em gerações mais antigas. Já o Microsoft Azure costuma apresentar Microsoft Corporation junto com Virtual Machine. Se você vir QEMU Standard PC (i440FX + PIIX, 1996), isso indica que o provedor não se deu ao trabalho de alterar o template, o que por si só é um sinal de identificação.

Um método mais avançado é comparar diretamente as informações de System Information e Baseboard de dmidecode -t 1 e dmidecode -t 2. Vale lembrar: alguns provedores menores de IDC podem "modificar" as strings DMI para se passar por grandes empresas, então o DMI deve ser validado de forma cruzada com os dispositivos virtio e o Steal Time. Se você quiser verificar rapidamente a identidade do seu servidor em nuvem, pode usar a página de detecção gratuita do CloudWorth: /app, que combina múltiplos caminhos /sys para fazer a determinação automaticamente.

Lista de dispositivos virtio para detectar KVM

virtio é o framework de I/O paravirtualizado do KVM/QEMU. Se houver dispositivos virtio, é praticamente certeza de que é KVM (Xen e OpenVZ não usam isso). O comando de verificação é ls -l /sys/bus/virtio/devices/, ou lspci | grep -i virtio. Você verá diretórios como virtio0, virtio1, representando dispositivos de bloco, placas de rede, balloon, etc.

Para uma detecção mais precisa, observe o ID do fabricante PCI: lspci -nn | grep -i -E '1af4|virtio', onde 0x1af4 é o vendor ID oficial da Red Hat/virtio. Se a placa de rede mostrar Red Hat, Inc. Virtio network device, com certeza é KVM/QEMU. Da mesma forma, se o dispositivo de bloco for Virtio block device, isso indica que o disco também usa o caminho virtio.

Se não quiser usar o lspci, você pode fazer uma verificação cruzada com /proc e /sys: veja se cat /proc/bus/pci/devices contém 1af4, ou use find /sys/devices -name 'virtio'. Nota: o novo AWS Nitro e alguns provedores de nuvem usam EFA ou ENA no lugar de placas de rede puramente virtio, mas os dispositivos de bloco ainda mantêm o virtio, então priorize o controlador de disco. Quando o diretório virtio contém subdiretórios block e net, é quase possível excluir o modo PV do OpenVZ e do Xen.

Identificação de especificações falsas com Steal Time

Identificar o provedor de nuvem KVM é apenas o primeiro passo; o essencial é julgar se este servidor em nuvem tem "especificações falsas". Steal Time (tempo roubado) é o tempo de CPU usurpado pelo host na máquina convidada KVM. Quanto maior o valor, mais severo é o superprovisionamento da máquina física. A forma mais simples de ler essa métrica é o %st no top, mas a mais precisa é observar o campo steal em /proc/stat.

Desde o kernel Linux 2.6.26, muitas otimizações foram feitas no relógio KVM e na E/S de rede, tornando a medição do Steal Time mais confiável. Se a coluna st do vmstat 1 for maior que 5% por um longo período, ou se o 8º número do comando cat /proc/stat | grep '^cpu ' (fatia de tempo steal) continuar aumentando, significa que suas vCPUs estão frequentemente sendo tomadas pelos vizinhos. A seguir estão alguns comandos de validação ao vivo:

# Amostrar a cada 2 segundos, observar a coluna st
vmstat 1 5
# Ver o tempo steal acumulado (em jiffies)
awk '/^cpu / {print "steal:", $8}' /proc/stat
# Usar mpstat para ver a porcentagem roubada por núcleo
mpstat -P ALL 1 2

Um método de teste mais agressivo é a "maratona de CPU + comparação de Steal": execute stress-ng --cpu 4 por cinco minutos, enquanto registra o %steal do mpstat. Se a taxa média de roubo exceder 10%, pode-se basicamente concluir que o superprovisionamento é severo; antes de renovar, compare com o preço de uma nova compra. Se quiser calcular a diferença entre seu plano atual e o desconto para novos usuários, veja a ferramenta de comparação de preços da CloudWorth para servidores em nuvem: /app. Lembre-se: Steal Time alto não significa que o provedor não é confiável, mas indica "recursos redundantes insuficientes na máquina física", o que é uma referência importante para decisões de renovação e migração. Ao cruzar e comparar dmesg, DMI, virtio e Steal Time, você poderá confirmar com precisão, como uma perícia, o provedor de nuvem e o nível real de desempenho.