SSD Nodes Learn
Guias Matt ConnorPor Matt Connor · Atualizado 2026-07-24

rodar Proxmox em VPS com nested virtualization

Verifique se o seu VPS suporta nested virtualization usando o comando kvm-ok. Saiba se o provedor expõe as flags vmx ou svm para rodar Proxmox ou KVM.

A resposta curta

Virtualização aninhada (nested virtualization) é um hypervisor rodando dentro de uma máquina virtual: seu VPS já é um guest, e você quer que ele hospede seus próprios guests. Isso só funciona se o hypervisor do seu provedor expuser deliberadamente as extensões de virtualização da CPU para sua instância — verifique /proc/cpuinfo para a flag vmx (Intel) ou svm (AMD); se nenhuma delas aparecer, nenhuma configuração dentro do VPS resolverá o problema.

Um aviso importante: o Docker não precisa de nada disso. Containers compartilham o kernel do seu VPS e nunca acessam o /dev/kvm. Se o seu objetivo real é "rodar vários serviços em containers no meu servidor", você já tem o que precisa. A virtualização aninhada é necessária quando você precisa de um segundo kernel — um laboratório Proxmox, um guest Windows, microVMs Firecracker, um emulador Android, um ambiente de teste Kubernetes com VMs reais ou runners de CI que dão boot em imagens de VM.

O que está sendo aninhado de fato

Três camadas:

  • L0 — o hypervisor do provedor, no hardware real. Você não tem acesso a ele.
  • L1 — sua VPS. Para o L0, esta é apenas uma guest.
  • L2 — a VM que você deseja executar dentro da sua VPS.

A virtualização de hardware é VT-x (a flag vmx) mais EPT na Intel, ou AMD-V / SVM (svm) mais RVI/NPT na AMD. Um hypervisor utiliza essas instruções para entrar em guest mode e permitir que a CPU percorra duas page tables simultaneamente.

Nenhuma delas foi projetada para ser reentrante, portanto o aninhamento é emulado: quando o L1 executa uma instrução VMX, ocorre um trap para o L0, que mantém as shadow structures para o L2 em nome do L1. O KVM faz isso bem, mas o L0 realiza trabalho extra em cada exit — por isso o provedor precisa habilitar essa opção.

Duas condições devem ser atendidas para um L2 acelerado:

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

Verifique 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 funcional exibe vmx ou svm, kvm-ok exibe KVM acceleration can be used, e /dev/kvm existe como root:kvm em modo 660. Se a flag estiver presente mas o nó do dispositivo não, carregue o módulo manualmente e verifique o log do kernel:

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

Um arquivo é citado constantemente e frequentemente interpretado de forma errada:

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

Dentro do seu VPS, este é o ajuste do seu módulo KVM, e ele determina se um guest L2 pode realizar nesting de um terceiro nível. Ele não indica se o L0 habilitou o nesting para você — /proc/cpuinfo e kvm-ok respondem isso. O parâmetro nested é o ajuste que você configura em uma máquina de sua propriedade:

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 uma VM estiver em execução; portanto, desligue os guests primeiro.

Por que a maioria dos hosts de VPS o mantém desativado

  • Live migration. Entregar vmx significa expor um modelo de CPU que possui a flag. Um guest que dependa desses recursos de CPU não pode ser migrado com segurança para uma máquina cuja CPU não os possua. Um host que esvazia nós migrando clientes perde essa capacidade no momento em que habilita o nesting.
  • Superfície de ataque. Os caminhos nested VMX/SVM estão entre os códigos mais complexos na camada de virtualização do kernel, com um histórico de CVE correspondente.
  • L0 pode não ser KVM. Se systemd-detect-virt imprimir vmware, xen ou microsoft, as regras de nesting pertencem àquela stack, não ao KVM.

Sem a flag na sua instância? Entre em contato com o suporte (alguns habilitam por VM), escolha um plano que documente nesting ou mude para um servidor dedicado. O restante deste guia assume acesso root em uma máquina que exibe a flag.

Executando 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. A instalação via serial demora um pouco, então inicie-a dentro de um shell persistente: o mesmo workflow tmux que mantém sessões do Claude Code vivas em um VPS mantém um console virt-install conectado mesmo após a queda da conexão SSH. Se --os-variant debian13 for rejeitado, seu osinfo-db é anterior ao lançamento — execute osinfo-query os e escolha um nome existente. --cpu host-passthrough encaminha vmx para o L2, necessário apenas se o L2 precisar virtualizar por sua vez. Torne o guest seguro para boot com virsh autostart guest1.

O barramento virtio em disco e NIC não é apenas decorativo: dispositivos IDE e e1000 emulados geram traps no hypervisor com muito mais frequência que filas virtio, e em cenários de nesting, cada trap tem o custo dobrado.

Networking: a parte que os tutoriais ignoram

Seu VPS possui um IP público e está atrás de um fabric que filtra endereços MAC desconhecidos. Isso gera duas consequências.

Fazer bridging de guests L2 na rede pública geralmente não funciona. Se você colocar br0 na NIC pública e atribuir um MAC próprio ao guest, o ARP será enviado mas nada retornará — o switch do provedor descarta frames de um MAC que não foi atribuído a você. Se este for o seu problema, pare de depurar o bridge; este é o comportamento esperado.

Use a rede NAT em vez disso. O libvirt inclui default: virbr0, 192.168.122.0/24, leases do dnsmasq, e o tráfego de saída funciona imediatamente. Para tráfego de entrada, termine o TLS no L1 e faça o proxy — os caminhos de certificado 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 um lease estático (virsh net-edit default) para que o endereço nesse proxy_pass permaneça fixo.

Interfaces de gerenciamento devem ficar fora da internet: o VNC na porta 5900 e a interface web do Proxmox na 8006 devem rodar no loopback, acessados via túnel SSH (ssh -N -L 8006:127.0.0.1:8006 you@your-vps) ou através de um WireGuard VPN auto-hospedado para o VPS, o que coloca todo o range de guests 192.168.122.0/24 a apenas um salto privado de distância. Mantenha o firewall restrito — sudo ufw allow 22,80,443/tcp, nada mais. Se os guests perderem conectividade de saída logo após você ativar o ufw, o culpado comum é o DEFAULT_FORWARD_POLICY="DROP" em /etc/default/ufw — defina para ACCEPT e recarregue o ufw.

Proxmox em um VPS

O Proxmox VE 9 é baseado no Debian 13. Para instalá-lo em um VPS Debian, adicione o repositório pve-no-subscription e o pacote proxmox-ve. Utilize as linhas de repositório e keyring da documentação oficial do Proxmox — usar uma URL copiada de posts antigos fará a instalação falhar.

Os pacotes não são a parte difícil. O Proxmox espera um vmbr0 conectado via bridge a uma NIC física, o que causa o erro de filtragem de MAC mencionado anteriormente. O método funcional em um VPS é usar um vmbr0 com NAT ou roteamento sem porta física, máquinas virtuais em uma rede privada e regras de DNAT ou um reverse proxy no host para serviços públicos. Quando os serviços públicos forem containers em vez de VMs, o Traefik à frente de múltiplos apps via um Docker Compose realiza o mesmo roteamento com certificados automáticos. Faça um snapshot do /etc/network/interfaces primeiro: uma configuração de bridge incorreta pode causar o bloqueio de acesso a uma máquina da qual você pode não ter o console.

Performance, de forma direta

O Nested é mais lento que o single-level, e o motivo é específico: o custo não está no acesso à memória, mas sim nos exits. Com EPT/NPT habilitado, o L0 mantém shadow page tables para o L2 e leituras de memória comuns operam na velocidade do hardware. O custo elevado ocorre em cada operação que sai do guest mode — I/O, timer interrupts, MMIO, inter-processor interrupts — pois um L2 exit é tratado pelo L0 e pode ser refletido de volta pelo L1. Cargas de trabalho CPU-bound com dados já na RAM apresentam desempenho próximo ao nativo; qualquer carga dominada por syscalls, pacotes e disk I/O sentirá o impacto das camadas.

Portanto: use virtio devices em tudo. E seu arquivo qcow2 reside em um disco que o provedor já virtualizou — duas camadas de thin-provisioning empilhadas, onde cache=none no disco do guest evita que os mesmos blocos ocupem dois page caches simultaneamente. Não incluímos números de benchmark aqui: meça sua própria carga de trabalho em sua própria instância.

Modos de falha e as strings que você verá

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 /proc/cpuinfo primeiro.

kvm: disabled by bios em dmesg. Em bare metal, ative o toggle VT-x/SVM no firmware. Em uma VPS, isso significa que o L0 não está fornecendo as extensões, e nenhum comando no guest alterará isso.

modprobe: ERROR: could not insert 'kvm_intel': Operation not supported. A CPU que o kernel detecta não possui vmx — novamente, uma decisão do L0.

Could not access KVM kernel module: Permission denied. Problema de permissão, não de hardware. O ls -l /dev/kvm deve mostrar o grupo kvm e o modo 660; adicione seu usuário ao grupo e inicie um novo shell de login, pois a participação em grupos não se aplica a sessões já em execução.

kvm: Device or resource busy ao iniciar o QEMU. Outro módulo de hypervisor está ocupando a CPU: execute lsmod, procure por vboxdrv ou módulos VMware junto com kvm_intel, e descarregue o módulo indesejado.

/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 aceleração KVM marcada em um host que não pode fornecê-la. Corrija o nesting ou desmarque a opção e aceite a emulação.

Android emulator: x86_64 emulation currently requires hardware acceleration! /dev/kvm novamente — geralmente o caso de grupo.

Nenhum erro, mas tudo está extremamente lento. O QEMU sem a flag de acelerador utiliza o TCG, seu emulador de software. O comportamento está correto, mas é lento — um boot de segundos passa a levar minutos. Passe -accel kvm explicitamente para que o QEMU pare com um erro em vez de emular silenciosamente.

Um guest desaparece durante a execução. Verifique dmesg em busca de Out of memory: Killed process ... qemu-system-x86_64. Um guest L2 é um processo no L1, e o OOM killer o trata como qualquer outro. A RAM do L2 sai da alocação fixa do L1 — não há empréstimo do host.

Operação: backups, upgrades, limites

Backups. Copiar o qcow2 de um guest em execução resulta em uma imagem corrompida. Ou use virsh shutdown guest1 e copie, ou tire um snapshot externo (virsh snapshot-create-as guest1 snap1 --disk-only --atomic) para que as escritas sejam desviadas para um overlay enquanto você copia a base estática, e depois aplique o merge com virsh blockcommit. Envie as cópias para fora do VPS — um snapshot no mesmo disco não oferece proteção.

Upgrades. O apt full-upgrade instala novos módulos kvm_intel/kvm_amd, mas o kernel em execução mantém os antigos até o reboot. Mantenha o kernel anterior instalado e execute o kvm-ok após cada mudança de kernel: um host que retornar sem o vmx estará a apenas uma entrada de boot de voltar a funcionar.

Limites de escalabilidade. Um IP público significa que cada serviço L2 alcança a internet através de um proxy ou uma regra DNAT no L1. Live migration não está disponível. Sob contenção de CPU, o caminho de nested exit é o primeiro a sofrer impacto. E um hypervisor com vários guests é uma máquina com a RAM já consumida — VMs aninhadas não podem usar overcommit para contornar uma alocação fixa. Quando um laboratório cresce além disso, a solução não é uma pilha aninhada maior; é um servidor dedicado onde você é o L0 e nenhuma dessas limitações se aplica.

FAQ

Eu preciso de virtualização aninhada para rodar Docker em um VPS?

Não. Containers compartilham o kernel do seu VPS e nunca abrem /dev/kvm. Uma instância comum sem as flags vmx ou svm roda Docker e Docker Compose normalmente. O aninhamento só é necessário quando você precisa de um segundo kernel: um laboratório Proxmox, um guest Windows, microVMs Firecracker, um emulador Android ou runners de CI que dão boot em imagens de VM.

Como eu verifico se meu VPS suporta virtualização aninhada?

Execute grep -o -E 'vmx|svm' /proc/cpuinfo | sort -u e depois kvm-ok do pacote cpu-checker. Uma instância funcional imprime vmx (Intel) ou svm (AMD). kvm-ok reporta KVM acceleration can be used, e /dev/kvm existe com o grupo kvm e modo 660. Ignore o /sys/module/kvm_intel/parameters/nested para esta pergunta — esse arquivo descreve o seu próprio módulo KVM, não o que o hypervisor do provedor expôs para você.

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

Expor vmx significa entregar ao guest um modelo de CPU que possui a flag. Um guest que depende desses recursos de CPU não pode sofrer live-migration para uma máquina cuja CPU não os possua — provedores que movem clientes entre nodes para balanceamento evitam isso. Os caminhos de código VMX/SVM aninhados também possuem um longo histórico de CVEs. Alguns hosts ainda habilitam o recurso por VM sob demanda, e outros listam o aninhamento como um plano premium.

Minha VM aninhada está sem rede na bridge pública. Qual é o problema?

O switch do provedor descarta frames de um endereço MAC que nunca foi atribuído a você. Assim, um guest L2 em bridge na NIC pública envia ARP e não recebe resposta. Pare de depurar o br0 — use a rede NAT default do libvirt (virbr0, 192.168.122.0/24), atribua um lease estático ao guest e publique qualquer serviço público através de um reverse proxy ou regra de DNAT no próprio VPS.

O quanto uma VM aninhada é mais lenta?

O custo recai sobre os VM exits, não sobre o acesso à memória. Com EPT/NPT ativo, leituras e escritas comuns dentro do L2 rodam na velocidade do hardware, enquanto I/O, interrupções de timer, MMIO e IPIs são tratados pelo L0 e podem ser reencaminhados via L1. Cargas de trabalho limitadas por CPU com dados já na RAM apresentam desempenho próximo ao nativo; cargas de trabalho pesadas em syscalls, pacotes e disco sentem cada camada. Use dispositivos virtio em todos os lugares e cache=none nos discos do guest, então meça sua própria carga de trabalho.

#nested-virtualization#kvm#proxmox#vps#qemu#libvirt