VPS com virtualização aninhada: roda Proxmox?

A resposta curta

A virtualização aninhada consiste em executar um hypervisor dentro de uma máquina virtual: o seu VPS já é um guest e pretende alojar os seus próprios guests. Isto só funciona quando o hypervisor do fornecedor expõe deliberadamente as extensões de virtualização da CPU à sua instância. Verifique /proc/cpuinfo quanto à flag vmx (Intel) ou svm (AMD). Se nenhuma aparecer, nada do que configurar dentro do VPS resolverá o problema.

Primeiro, uma clarificação importante: o Docker não precisa de nada disto. Os containers partilham o kernel do VPS e nunca acedem a /dev/kvm. Se o objetivo real for "executar vários serviços em containers no meu servidor", já tem tudo o que precisa. A virtualização aninhada é relevante quando pretende um segundo kernel, um laboratório Proxmox, um guest Windows, microVMs Firecracker, um emulador Android, um ambiente de testes Kubernetes com VMs reais ou runners de CI que iniciam imagens de VMs.

O que é realmente aninhado

Três camadas:

• L0, o hypervisor do provedor, no hardware físico. Você não tem acesso a ele.
• L1, o seu VPS. Para o L0, ele é apenas um guest.
• L2, a VM que você pretende executar dentro do seu VPS.

A virtualização de hardware usa VT-x (a flag vmx) e EPT na Intel, ou AMD-V / SVM (svm) e RVI/NPT na AMD. Um hypervisor usa essas instruções para entrar no modo guest e permitir que a CPU percorra duas tabelas de páginas ao mesmo tempo.

Nenhuma das duas tecnologias foi projetada para reentrância, portanto o aninhamento é emulado: quando o L1 executa uma instrução VMX, ela gera uma interceptação para o L0, que mantém as estruturas shadow da L2 em nome do L1. O KVM faz isso bem, mas é o L0 que realiza trabalho adicional a cada saída, motivo pelo qual o provedor precisa habilitar essa funcionalidade.

As duas condições devem ser atendidas para uma L2 acelerada:

1. O módulo KVM do L0 deve ser carregado com nested=1.
2. O L0 deve fornecer ao seu VPS um modelo de CPU que inclua a flag: <cpu mode='host-passthrough'/> no libvirt, cpu: host no Proxmox e -cpu host no QEMU puro. Um modelo genérico emulado (qemu64, kvm64) oculta vmx, mesmo quando o aninhamento está habilitado globalmente.

Verifique o seu VPS em um minuto

# 1. Are you in a VM, and under what?
systemd-detect-virt          # kvm, vmware, xen, microsoft, or "none" on metal

# 2. Does the CPU expose the extensions to you?
grep -o -E 'vmx|svm' /proc/cpuinfo | sort -u
lscpu | grep -i -E 'virtual|hypervisor'

# 3. The definitive check
sudo apt update && sudo apt install -y cpu-checker
kvm-ok

# 4. The device node the whole stack depends on
ls -l /dev/kvm

Uma instância utilizável mostra vmx ou svm, kvm-ok indica KVM acceleration can be used, e /dev/kvm existe com o modo root:kvm 660. Se o sinalizador estiver presente, mas o nó de dispositivo não existir, carregue o módulo manualmente e consulte o log do kernel:

sudo modprobe kvm_intel     # or kvm_amd
sudo dmesg | tail -n 20

Um ficheiro é citado constantemente e costuma ser interpretado de forma errada:

cat /sys/module/kvm_intel/parameters/nested   # Y or N

Dentro do seu VPS, essa é a configuração do seu módulo KVM. Ela determina se um convidado L2 poderia aninhar um terceiro nível. Não indica se L0 ativou o aninhamento para si; /proc/cpuinfo e kvm-ok respondem a isso. O parâmetro nested é a opção que configura numa máquina que controla diretamente:

echo 'options kvm_intel nested=1' | sudo tee /etc/modprobe.d/kvm-nested.conf
sudo modprobe -r kvm_intel && sudo modprobe kvm_intel

A remoção do módulo é recusada enquanto houver uma VM em execução. Primeiro, desligue os convidados.

Por que a maioria dos hosts VPS o deixa desativado

• Migração em tempo real. Conceder vmx significa expor um modelo de CPU que inclui esse sinalizador. Uma máquina virtual que dependa dessas funcionalidades da CPU não pode ser migrada com segurança para uma máquina cuja CPU não as tenha. Um host que esvazia nós migrando clientes perde essa capacidade assim que ativa o nesting.
• Superfície de ataque. Os caminhos VMX/SVM aninhados estão entre os códigos mais complexos da camada de virtualização do kernel, com um histórico de CVEs à altura.
• L0 pode não ser KVM. Se systemd-detect-virt mostrar vmware, xen ou microsoft, as regras de nesting são definidas por essa pilha, não pelo KVM.

A sua instância não mostra o sinalizador? Contacte o suporte (alguns provedores ativam-no por VM), escolha um plano que documente o nesting ou migre para uma máquina dedicada. O restante pressupõe acesso root a uma máquina que mostre o sinalizador.

Executar um guest L2 com libvirt

sudo apt install -y qemu-system-x86 libvirt-daemon-system virtinst ovmf
sudo systemctl enable --now libvirtd
sudo usermod -aG libvirt,kvm "$USER"   # log out and back in

virt-install \
  --name guest1 \
  --memory 2048 \
  --vcpus 2 \
  --cpu host-passthrough \
  --disk path=/var/lib/libvirt/images/guest1.qcow2,size=20,format=qcow2,bus=virtio \
  --network network=default,model=virtio \
  --os-variant debian13 \
  --location https://deb.debian.org/debian/dists/trixie/main/installer-amd64/ \
  --graphics none \
  --console pty,target_type=serial \
  --extra-args 'console=ttyS0,115200n8'

Não é necessária uma sessão gráfica. Uma instalação série demora algum tempo, por isso inicie-a dentro de uma shell persistente: o mesmo fluxo de trabalho do tmux que mantém as sessões do Claude Code ativas numa VPS mantém uma consola virt-install ligada depois de uma quebra da ligação SSH. Se --os-variant debian13 for rejeitado, a sua osinfo-db é anterior a essa versão; execute osinfo-query os e escolha um nome existente. --cpu host-passthrough encaminha vmx para dentro de L2, sendo necessário apenas se L2 também tiver de executar virtualização. Torne o guest seguro para o arranque com virsh autostart guest1.

O bus virtio no disco e na NIC não é decorativo: os dispositivos IDE e e1000 emulados fazem o hypervisor intervir com muito mais frequência do que as filas virtio e, com nesting, cada intervenção tem de ser processada duas vezes.

Rede: a parte que os tutoriais ignoram

O seu VPS tem 1 IP público e está atrás de uma infraestrutura que filtra endereços MAC desconhecidos. Daqui resultam duas consequências.

Normalmente, não é possível ligar convidados L2 à rede pública através de uma bridge. Coloque br0 na NIC pública, atribua ao convidado o seu próprio MAC e verá pedidos ARP a sair sem qualquer resposta. O switch do fornecedor descarta os frames de um MAC que nunca lhe foi atribuído. Se esse for o sintoma, pare de depurar a bridge. Esse é o mecanismo.

Use a rede NAT. O libvirt fornece default: virbr0, 192.168.122.0/24, concessões do dnsmasq e conectividade de saída imediata. Para ligações de entrada, termine o TLS em L1 e faça proxy para o convidado. Os caminhos dos certificados abaixo vêm de emitir um certificado Let's Encrypt com Certbot no Nginx:

server {
    listen 443 ssl;
    server_name lab.example.com;

    ssl_certificate     /etc/letsencrypt/live/lab.example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/lab.example.com/privkey.pem;

    location / {
        proxy_pass http://192.168.122.50:8080;
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

Atribua primeiro uma concessão estática ao convidado (virsh net-edit default), para que o endereço em proxy_pass não mude.

As interfaces de gestão devem ficar fora da Internet: o VNC na porta 5900 e a interface web do Proxmox na porta 8006 devem ficar ligadas ao loopback e ser acedidas através de um túnel SSH (ssh -N -L 8006:127.0.0.1:8006 you@your-vps) ou por uma VPN WireGuard auto-hospedada para o VPS, que coloca todo o intervalo de convidados 192.168.122.0/24 a um salto privado de distância. Mantenha a firewall restritiva, sudo ufw allow 22,80,443/tcp, e nada mais. Se os convidados perderem a conectividade de saída logo depois de ativar o ufw, a causa habitual é DEFAULT_FORWARD_POLICY="DROP" em /etc/default/ufw. Defina-o como ACCEPT e recarregue o ufw.

Proxmox em um VPS

O Proxmox VE 9 usa o Debian 13 como base. Por isso, ele é instalado em um VPS Debian adicionando o repositório pve-no-subscription e o pacote proxmox-ve. Use as linhas do repositório e do keyring da documentação atual do próprio Proxmox. Uma URL copiada de uma publicação antiga em um blog pode interromper a instalação. Antes de passar uma noite a configurar a rede abaixo, vale decidir se o Proxmox deve mesmo ser usado em hardware alugado. A comparação de custos e capacidades entre um servidor Proxmox em casa e um VPS alugado apresenta essa questão com os cálculos de energia e hardware já feitos.

Os pacotes não são a parte difícil. O Proxmox espera que vmbr0 esteja ligado a uma NIC física por bridge. Isso conduz diretamente ao problema de filtragem de MAC descrito acima. A configuração que funciona em um VPS é uma vmbr0 com NAT ou roteamento, sem nenhuma porta física associada, com os guests em uma faixa privada e regras DNAT ou um reverse proxy no host para tudo o que for público. Quando os serviços públicos são containers em vez de VMs, Traefik encaminhando várias aplicações a partir de um único ficheiro Docker Compose executa a mesma função de encaminhamento com certificados automáticos. Faça primeiro um snapshot de /etc/network/interfaces. Uma definição incorreta da bridge pode bloquear o acesso a uma máquina cuja consola talvez não esteja disponível.

Desempenho, com honestidade

A virtualização aninhada é mais lenta do que a virtualização de um único nível, e o mecanismo é específico, não difuso: o custo não está no acesso à memória, mas nas saídas do modo convidado. Quando EPT/NPT está disponível, L0 mantém tabelas de páginas sombra para L2 e as leituras normais de memória são executadas à velocidade do hardware. O que fica caro são todas as operações que fazem o sistema sair do modo convidado: E/S, interrupções de temporizador, MMIO e interrupções entre processadores, porque uma saída de L2 é processada por L0 e pode ser refletida novamente através de L1. O trabalho limitado pela CPU que opera sobre dados já presentes na RAM fica próximo do desempenho nativo; qualquer carga dominada por syscalls, pacotes e E/S de disco evidencia as camadas.

Portanto: use dispositivos virtio em todo o sistema. Além disso, o ficheiro qcow2 fica num disco que o fornecedor já virtualizou, com duas camadas de thin provisioning sobrepostas, em que cache=none no disco convidado impede que os mesmos blocos permaneçam simultaneamente em duas caches de páginas. Não há números de benchmark aqui: meça a sua própria carga de trabalho na sua própria instância.

Modos de falha e mensagens apresentadas

INFO: /dev/kvm does not exist / KVM acceleration can NOT be used de kvm-ok. O módulo não está carregado ou a flag não está exposta. Verifique primeiro /proc/cpuinfo.

kvm: disabled by bios em dmesg. Em bare metal, alterne a opção VT-x/SVM no firmware. Numa VPS, isso significa que L0 não está a disponibilizar as extensões. Nada do que introduzir no guest altera essa situação.

modprobe: ERROR: could not insert 'kvm_intel': Operation not supported. A CPU que o kernel deteta não tem vmx. Mais uma vez, esta é uma decisão de L0.

Could not access KVM kernel module: Permission denied. É um problema de permissões, não de hardware. ls -l /dev/kvm deve apresentar o grupo kvm e o modo 660. Adicione a sua conta a esse grupo e inicie uma nova shell de login, porque a associação ao grupo não se aplica a uma sessão já em execução.

kvm: Device or resource busy quando o QEMU arranca. Outro módulo de hypervisor está a controlar a CPU. Execute lsmod, procure vboxdrv ou módulos VMware juntamente com kvm_intel e descarregue o módulo que não pretende utilizar.

/var/run/libvirt/libvirt-sock: No such file or directory de virsh. O daemon está parado: sudo systemctl enable --now libvirtd.

Proxmox: KVM virtualisation configured, but not available. Um guest tem a aceleração KVM ativada num host que não a consegue disponibilizar. Corrija o nesting ou desative a opção e aceite a emulação.

Emulador Android: x86_64 emulation currently requires hardware acceleration! /dev/kvm novamente, normalmente um problema de grupo.

Nenhum erro e tudo muito lento. O QEMU sem uma flag de acelerador recorre ao TCG, o seu emulador de software. O funcionamento está correto, mas é lento: um boot medido em segundos passa a ser medido em minutos. Indique -accel kvm explicitamente para que o QEMU termine com um erro em vez de emular silenciosamente.

Um guest desaparece durante a execução. Procure Out of memory: Killed process ... qemu-system-x86_64 em dmesg. Um guest L2 é um processo no L1 e o OOM killer trata-o como qualquer outro processo. A RAM do L2 é retirada da alocação fixa do L1; não há memória emprestada do host.

Operação: backups, atualizações e limites

Backups. Copiar o qcow2 de um guest em execução gera uma imagem corrompida. Faça virsh shutdown guest1 e copie, ou crie um snapshot externo (virsh snapshot-create-as guest1 snap1 --disk-only --atomic) para que as escritas sejam desviadas para um overlay enquanto copia a base, que fica estática. Depois, integre o overlay novamente com virsh blockcommit. Transfira as cópias para fora do VPS; um snapshot no mesmo disco não protege contra falhas desse disco.

Atualizações. apt full-upgrade instala novos módulos kvm_intel/kvm_amd, mas o kernel em execução continua a usar os módulos antigos até fazer reboot. Mantenha o kernel anterior instalado e execute novamente kvm-ok depois de cada alteração do kernel: se o host arrancar sem vmx, bastará selecionar outra entrada de boot para voltar a funcionar.

Quando isto deixa de escalar. Um único IP público significa que todos os serviços L2 chegam à Internet através de um proxy ou de uma regra DNAT em L1. A migração em tempo real não é uma opção. Sob contenção de CPU, o caminho de saída aninhado é o primeiro a sofrer. Além disso, um hypervisor com vários guests é uma máquina cuja RAM já foi alocada; VMs aninhadas não conseguem usar overcommit para ultrapassar uma alocação fixa. Quando um laboratório ultrapassa essa capacidade, a resposta não é criar uma camada aninhada adicional. É usar uma máquina dedicada, onde você está em L0 e nada disto se aplica.

FAQ

É necessário usar virtualização aninhada para executar Docker numa VPS?

Não. Os contentores partilham o kernel da sua VPS e nunca abrem /dev/kvm, por isso uma instância comum, sem as flags vmx ou svm, executa Docker e Docker Compose sem problemas. O aninhamento só é necessário quando pretende um segundo kernel: um laboratório Proxmox, um guest Windows, microVMs Firecracker, um emulador Android ou runners de CI que arrancam imagens de VM.

Como verifico se a minha VPS suporta virtualização aninhada?

Execute grep -o -E 'vmx|svm' /proc/cpuinfo | sort -u e, depois, kvm-ok a partir do pacote cpu-checker. Uma instância utilizável apresenta vmx (Intel) ou svm (AMD), kvm-ok indica KVM acceleration can be used, e /dev/kvm existe com o grupo kvm e o modo 660. Ignore /sys/module/kvm_intel/parameters/nested nesta verificação. Esse ficheiro descreve o seu próprio módulo KVM, não o que o hypervisor do fornecedor expôs à sua instância.

Por que motivo a maioria dos fornecedores de VPS desativa a virtualização aninhada?

Expor vmx significa fornecer ao guest um modelo de CPU que inclui essa flag. Um guest que dependa dessas funcionalidades da CPU não pode ser migrado em tempo real para uma máquina cuja CPU não as tenha. Um fornecedor que esvazia nós ao mover clientes entre máquinas abdica dessa flexibilidade. Os caminhos de código VMX/SVM aninhados também têm um longo histórico de CVEs. Alguns hosts continuam a ativar esta funcionalidade por VM, mediante pedido. Outros documentam o aninhamento como uma funcionalidade do plano.

A minha VM aninhada não tem rede na bridge pública. O que está errado?

O switch do fornecedor descarta frames provenientes de um endereço MAC que nunca lhe foi atribuído. Por isso, um guest L2 ligado em bridge à NIC pública envia ARP e não recebe resposta. Pare de investigar br0. Use a rede NAT default do libvirt (virbr0, 192.168.122.0/24), atribua ao guest uma lease estática e publique qualquer serviço público através de um reverse proxy ou de uma regra DNAT na própria VPS.

Quanto mais lenta é uma VM aninhada?

O custo ocorre nas saídas da VM, não no acesso à memória. Com EPT/NPT ativo, as leituras e escritas comuns dentro de L2 são executadas à velocidade do hardware. Já as operações de I/O, interrupções de temporizador, MMIO e IPI são tratadas por L0 e podem ser devolvidas através de L1. Processamento limitado pela CPU, sobre dados que já estão na RAM, aproxima-se do desempenho nativo. Cargas com muitas chamadas de sistema, pacotes ou operações de disco sentem cada camada. Use dispositivos virtio em todo o lado e cache=none nos discos dos guests. Depois, meça a sua própria carga de trabalho.