Kaique Mitsuo Silva Yamamoto
Arquitetura softwareInfra devops

Proxmox VE — Virtualização Open Source

Guia técnico sobre Proxmox VE 8.x: arquitetura KVM/LXC, cluster com Corosync, armazenamento (ZFS, Ceph, NFS, iSCSI), HA, networking, backups com PBS, automação com API/Terraform/Ansible e comparativo com vSphere e oVirt.

Arquitetura do Proxmox VE 8.x

Proxmox VE é uma plataforma de virtualização open source que combina KVM (máquinas virtuais completas) e LXC (containers de sistema) em uma única interface web e API.

Componentes centrais:

  • Hypervisor KVM: virtualização completa baseada em hardware (VT‑x/AMD‑V) para rodar VMs Windows, Linux e outros SOs, com suporte a virtio, snapshots, live migration, PCI/GPU passthrough.
  • Containers LXC: containers leves compartilhando kernel do host, ideais para workloads Linux menos acoplados ao sistema, com menor overhead de CPU/RAM em comparação a VMs.
  • Cluster: múltiplos nós Proxmox conectados via Corosync, que fornece comunicação de cluster, quorum e sincronização de configuração entre nós, permitindo live migration, HA e gerenciamento centralizado.

A interface web do Proxmox se conecta ao back‑end (PVE daemons) e ao banco de configuração (arquivo cluster‑wide baseado em corosync/pmxcfs), enquanto dados de VMs/containers ficam em storages configurados (ZFS, Ceph, LVM, NFS, etc.).


Instalação e configuração inicial

Passos comuns para um nó Proxmox VE 8.x:

  1. Instalar Proxmox VE via ISO oficial (baseado em Debian), escolhendo partição (ext4, XFS ou ZFS para raiz) e configurando rede básica (hostname, IP, gateway).
  2. Acessar a interface web (https://IP:8006), logar com usuário root e senha definida, aceitar certificado autoassinado inicialmente.
  3. Configurar repositórios (enterprise, no‑subscription) e atualizar o sistema.
  4. Adicionar storages (local‑lvm, diretórios, ZFS pools, NFS/iSCSI, Ceph) e preparar os primeiros VMs e containers.

Para clusters, cria‑se o cluster no primeiro nó (Datacenter → Cluster) e adicionam‑se outros via pvecm add, o que configura Corosync e sincroniza a configuração.


Gerenciamento de VMs: criação, snapshots, clones e templates

Criação e gerenciamento

  • Criação de VMs via UI ou CLI, escolhendo storage de disco, tipo de BIOS (SeaBIOS/UEFI), tipo de máquina (q35/i440fx), drivers virtio e cloud‑init se necessário.
  • Suporte a hardware virtual avançado: PCI/GPU passthrough, NUMA, CPU pinning, virtio‑SCSI, ballooning de memória.

Snapshots, clones e templates

  • Snapshots: capturam estado de disco e, opcionalmente, memória da VM; exigem storage compatível com snapshots (ZFS, Ceph RBD, LVM‑thin).
  • Clones:
    • Full clone: cópia completa do disco; independente do original.
    • Linked clone: depende de snapshot/base, economiza espaço mas adiciona dependência.
  • Templates: convertem uma VM em template, permitindo criar novas VMs rapidamente com base em uma imagem padrão (por exemplo, Debian/Ubuntu/Windows pré‑configurados).

LXC containers: quando usar vs VM

LXC containers são ideais quando:

  • O workload é Linux, não requer kernel customizado e pode compartilhar kernel do host.
  • Deseja‑se alta densidade de workloads com overhead mínimo (menos RAM/CPU por instância em comparação a VMs).

Vantagens:

  • Boot quase instantâneo, consumo reduzido de recursos, backups menores e mais rápidos.
  • Integração com templates LXC (Debian, Ubuntu, Alpine, etc.) e limites de recursos (CPU shares, memory/ swap, disk quotas).

Use VMs KVM quando:

  • Precisa rodar Windows ou outros SOs não Linux.
  • Precisa isolamento forte de kernel (segurança, drivers específicos, módulos customizados).
  • Workloads que exigem funcionalidades específicas de hypervisor (nested virtualization, snapshots complexos, etc.).

Armazenamento: ZFS, Ceph, NFS, iSCSI, local‑lvm

ZFS (local)

  • ZFS pode ser usado como storage local com recursos avançados: copy‑on‑write, snapshots, clones, compressão/transparente, checagem de integridade.
  • Estrutura: zpools (RAIDZ1/2/3, mirrors), datasets e ZVOLs (block devices para discos de VMs).
  • Exige RAM generosa (ARC) para máxima performance; recomenda‑se dezenas de GB de RAM em nós grandes.

Ceph (distribuído)

  • Ceph fornece armazenamento distribuído (RBD para blocos, CephFS para arquivos, RGW para objetos) ideal para clusters com 3+ nós, oferecendo alta disponibilidade e escalabilidade horizontal.
  • Cada servidor roda OSDs, MONs e, opcionalmente, MGRs; VMs acessam RBD como discos compartilhados, permitindo live migration entre nós sem copiar disco local.
  • Requer rede rápida e baixa latência (10–25GbE) e tuning cuidadoso.

Outros storages

  • NFS: storage de arquivos exportado por NAS/servidor; simples, bom para ISOs, templates e até discos de VMs menos críticos.
  • iSCSI: blocos exportados via rede; geralmente combinado com LVM no Proxmox.
  • local‑lvm: LVM‑thin local em disco único ou RAID do host, útil para setups simples ou laboratório.

Decisão comum: ZFS local + replicação para clusters pequenos; Ceph para clusters maiores e alta disponibilidade real de storage.


Clustering e alta disponibilidade (HA)

Cluster com Corosync

  • Corosync fornece heartbeat de cluster, quorum e replicação de configuração entre nós Proxmox.
  • Requer número ímpar de votantes (nós + qdevice) para evitar split‑brain; recomendam‑se 3+ nós em produção.

HA de VMs/containers

  • VMs/containers podem ser marcados como HA no data center; se um nó falhar, o gestor de HA reinicia as VMs em nós saudáveis usando storage compartilhado (Ceph, NFS, iSCSI, ZFS replicado).
  • HA não é “live” em caso de falha de nó (não há memória a ser migrada se o host caiu); as VMs são reiniciadas em outro nó, com pequeno downtime.

Para migrações sem downtime, usa‑se live migration manual ou orquestrada, quando ambos nós estão ativos e veem o mesmo storage.


Networking: Linux Bridge, VLAN, OVS e SDN

Proxmox oferece várias opções de rede:

  • Linux Bridge: padrão; cria bridges (vmbr0, etc.) que conectam VMs/LXC à interface física, similar a um switch virtual.
  • VLANs: tagging 802.1Q configurado na bridge ou porta física, permitindo múltiplas redes lógicas em uma NIC.
  • Open vSwitch (OVS): opção para topologias de rede mais avançadas (bonding, VLAN trunking, tunneling).
  • SDN: recursos de SDN integrados (Proxmox SDN) para redes virtuais overlay (VXLAN) entre nós do cluster, simplificando isolamento e multi‑tenant em ambientes maiores.

Backups com Proxmox Backup Server (PBS)

Proxmox Backup Server (PBS) é o componente especializado em backup incremental/deduplocado para VMs e containers Proxmox:

  • Integração nativa no PVE: adicionar PBS como tipo de storage e criar jobs de backup (mode snapshot/suspend/stop).
  • Backups incrementais e deduplicados (baseado em chunks), com compressão e verificação de integridade; ideal para retenções grandes e múltiplos pontos de restauração.
  • Restauração granular de VM/container, com compatibilidade com VZDump (fluxo de restore similar, mas usando backend mais eficiente).

PBS pode ser instalado em VM, bare‑metal ou LXC (com cuidados específicos), com storages ZFS, ext4/XFS, NFS, etc., e possui API própria para automação.


Live migration

Live migration permite mover uma VM em execução de um nó para outro com downtime mínimo:

  • Requisitos: cluster configurado, storage compartilhado ou replicado acessível por ambos nós (Ceph, NFS, iSCSI, ZFS replicado).
  • Fluxo: disco permanece no storage compartilhado; memória e estado da VM são copiados incrementalmente entre os nós até a sincronização ficar pequena o suficiente para um cutover rápido.

Com Ceph ou NFS, migrações são quase instantâneas; com storage local, o Proxmox pode copiar disco inteiro, tornando o processo mais lento.


Firewall integrado e segurança

Proxmox inclui firewall baseado em iptables/nftables, com:

  • Regras por datacenter, e VM/container.
  • Suporte a grupos de IP/porta, macros (SSH, HTTPS), logging e drops.
  • Integração com clusters (regras replicadas) e compatibilidade com VLANs/bridges.

Melhores práticas:

  • Habilitar firewall por padrão em data center/nós/VMs, permitir apenas portas necessárias.
  • Usar listas de IP confiáveis para acesso UI/API, autenthicação 2FA para usuários.

API REST do Proxmox VE

A API REST do Proxmox (/api2/json) expõe praticamente todas as operações da UI:

  • Gerenciamento de nós, VMs, LXC, storages, backups, usuários/roles, firewall, etc.
  • Pode ser consumida por scripts (curl, Python, Go) ou ferramentas como Terraform, Ansible e wrappers específicos.

Proxmox Backup Server também tem sua API própria (https://pbs-host:8007/api2/json), permitindo automação de jobs de backup/restore, gerenciamento de datastores, etc.


Automação com Terraform e Ansible

Terraform provider

  • O provider terraform-provider-proxmox permite provisionar VMs/LXC, storages, redes e recursos do Proxmox como código (HCL), integrando com pipelines de infra como código.
  • Uso típico:
    • Descrever templates e instâncias (CPU, memória, disco, network).
    • Executar terraform apply para criar/atualizar VMs em clusters Proxmox.

Ansible

  • Ansible é usado para configurar nós Proxmox e guests (VM/LXC) após provisionamento: instalar pacotes, aplicar configurações, join em clusters, etc.
  • Para o lado Proxmox/ PBS, pode‑se usar a API com módulos como uri ou collections específicas, ou simplesmente proxmox_* modules se disponíveis, para criar storages, usuários, datastores de PBS, etc.

Combinação comum:

  1. Terraform cria VMs/LXCs Proxmox.
  2. Ansible configura OS/apps dentro das VMs e também Proxmox/PBS via API.
  3. PBS realiza backups automatizados e replicação.

Monitoramento

Proxmox oferece:

  • Visão integrada de CPU, RAM, disco, rede por nó, VM e container na UI.
  • Notificações básicas via e‑mail (logs de tasks, falhas de backup, estado de cluster).
  • Integração com ferramentas externas: agente Zabbix dentro de hosts Proxmox, scraping Prometheus de /api2/json/exporters, forward de logs para syslog/ELK.

Muitos ambientes usam Proxmox VE como camada de virtualização e Zabbix/Prometheus/Datadog/Dynatrace para monitoramento mais avançado.


Comparativo: Proxmox VE vs VMware vSphere e oVirt

Proxmox VE vs VMware vSphere

  • Proxmox VE:

    • Open source, licenciamento baseado em subscription de suporte (não em CPUs/VMs).
    • Integração nativa de KVM + LXC, storage ZFS/Ceph, backups com PBS e interface web única.
    • Menos recursos enterprise específicos que vSphere em áreas como vSAN/vMotion/federation, mas cobre a maioria dos casos SMB/enterprise padrão com custo muito menor.
  • VMware vSphere:

    • Platform consolidada, com recursos enterprise maduros (vMotion/vSphere HA/DRS, vSAN, NSX).
    • Licenciamento mais caro e em transição após aquisição, muitos ambientes consideram migração para Proxmox por questões de custo e lock‑in.

Proxmox VE vs oVirt

  • oVirt (baseado em KVM + libvirt + Gluster/iscsi) foi, por muito tempo, a stack enterprise open source apoiada pela Red Hat (predecessora de RHV).
  • Proxmox VE oferece:
    • UI mais moderna, suporte integrado a LXC containers, Ceph/ZFS, PBS, community vibrante e releases frequentes.
    • Mais popular atualmente como alternativa open source para virtualização corporativa/homelab.

oVirt tende a ser encontrado em ambientes legados; novos projetos open source de virtualização convergem mais para Proxmox ou cloud/kube direto.


Fontes e leituras recomendadas

Documentação e guias oficiais:

Armazenamento:

Cluster, HA e live migration:

Backups com PBS e automação:

Esses recursos complementam o guia e servem como base prática para projetar clusters Proxmox VE 8.x com ZFS/Ceph, HA, PBS, automação e migração a partir de vSphere.

On this page