Proxmox VE 9: Actualização do 8.x e Novidades

A série 9.x já vai na 9.2 (e 9.2 para arm64), lançada a 21 de Maio de 2026, e é altura de planear a actualização com calma. Este artigo cobre o upgrade in-place do 8.4, as breaking changes que apanham quem não leu as release notes, e as novidades 9.0 a 9.2 que importam numa PME.

O Estado da Série 9.x

O roadmap oficial lista o historial:

  • 9.0 — 05/08/2025: base Debian Trixie (13), kernel 6.14.8-2, QEMU 10.0.2, LXC 6.0.4, ZFS 2.3.3, Ceph Squid 19.2.3
  • 9.1 — 19/11/2025: kernel 6.17.2-1, QEMU 10.1.2
  • 9.2 — 21/05/2026: kernel 7.0 como estável, QEMU 11.0, LXC 7.0, ZFS 2.4
  • 9.2 arm64 — 05/08/2026: primeira versão para outra arquitectura além de x86-64 (NVIDIA Grace/Vera, UEFI ARMv9-A)

Novidades 9.0 Relevantes para PME

  • VM snapshots em LVM thick-provisioned com “snapshots as volume chains” (technology preview): permite snapshots em LVM partilhado via iSCSI/Fibre Channel, típico de SANs de entrada.
  • HA rules de afinidade: node affinity (VMs só em nós específicos) e resource affinity (conjuntos de VMs sempre juntos ou separados). Numa PME com 2-3 nós, resolve o caso “esta VM é licenciada por socket, fica no nó com a licença”.
  • SDN Fabrics: OpenFabric e OSPF para redes roteadas sem switches L3 geridos. Útil para clusters Ceph full-mesh.
  • Interface web mobile reescrita: overview de guests e tarefas no telemóvel, escrita em Rust.
  • ZFS: adicionar dispositivos a pools RAIDZ existentes com downtime mínimo — finalmente RAIDZ expansion, um pedido de anos.

Novidades 9.1

  • LXC a partir de imagens OCI: containers de sistema a partir de imagens Docker/OCI de registos (application containers em technology preview).
  • TPM state em qcow2: snapshots de VMs com vTPM (Windows 11!) em storages de ficheiro como NFS/CIFS.
  • Nested virtualização granular: flag de vCPU para dar virtualização aninhada sem expor o CPU host completo.
  • SDN reporting na GUI: bridges e VNets mostram os guests ligados, EVPN mostra IPs/MACs aprendidos.

Novidades 9.2

  • CRS dynamic load balancing: o Cluster Resource Scheduler usa métricas reais de CPU/memória dos nós para migrar guests HA automaticamente e equilibrar o cluster. Parâmetros afináveis no painel HA.
  • SDN: WireGuard e BGP como protocolos de fabric, route maps e prefix lists para filtragem BGP/EVPN, IPv6 underlay em EVPN.
  • Modelos de CPU custom geridos pela web (Datacenter → CPU Models).

Breaking Changes do 8.4 para o 9

A lista que apanha quem actualiza sem ler:

  1. cgroupv1 removido: o parâmetro de kernel para voltar à hierarquia híbrida/cgroupv1 já não funciona. Containers LXC muito antigos (Debian Buster ou anterior) podem precisar de reconstrução.
  2. GlusterFS dropado: “As GlusterFS is no longer maintained upstream, Proxmox VE 9 drops support for GlusterFS storages.” Quem usa GlusterFS tem de migrar os dados para outro storage ou montar manualmente como Directory.
  3. Repositório renomeado: pvetest passou a pve-test.
  4. Nomes de interfaces de rede podem mudar (kernel 6.8 → 6.14). A doc recomenda o pve-network-interface-pinning antes de actualizar. VMs/CTs com config de rede por nome podem perder rede após o upgrade.
  5. MTU de VirtIO vNICs: campo vazio agora herda o MTU do bridge (antes assumia 1500). O pve8to9 detecta os afectados.
  6. AppArmor 4.1: possíveis regressões em pacotes fora do core (CUPS é o exemplo da doc). Docker dentro de LXC tem issue conhecida (#6538).
  7. Privilégios: VM.Monitor removido (usar Sys.Audit), novo VM.Replicate para replication jobs, criar containers privileged agora exige Sys.Modify. Roles custom precisam de revisão.
  8. maxfiles removido dos backups (deprecated desde o 7.0).
  9. /etc/sysctl.conf já não é lido pelo systemd-sysctl — migrar para /etc/sysctl.d/.

Na série 9.1: NVIDIA vGPU exige driver 19.4+ para o kernel 6.17, e há issues de boot no kernel 6.17 nalguns Dell PowerEdge (resolver activando SR-IOV Global e I/OAT DMA no firmware, ou pinning do kernel 6.14).

O Upgrade In-Place Passo a Passo

A wiki oficial de upgrade mantém duas vias: instalação nova em hardware novo (com restore dos backups) ou upgrade in-place via apt. O in-place na PME típica:

  1. Backups válidos e testados de todas as VMs e CTs. Não negociável — “A valid and tested backup is always required before starting the upgrade process.”
  2. Todos os nós no 8.4 mais recente (pve-manager ≥ 8.4.1). Ceph hiperconvergido: Quincy/Reef → Squid 19.2 antes do upgrade para o 9.0.
  3. pve8to9 --full várias vezes, corrigindo warnings até ficar limpo. O script só reporta, não corrige.
  4. Migração dos guests para fora do nó a actualizar (num cluster, um nó de cada vez).
  5. Acesso fiável ao nó: IPMI/iKVM ou consola física; SSH só com tmux/screen. Nunca pela consola web da GUI (cai durante o upgrade).
  6. Repositórios para Trixie: sed -i 's/bookworm/trixie/g' em /etc/apt/sources.list e nas listas enterprise/no-subscription.
  7. apt update && apt full-upgrade — cerca de 30-60 min por nó, com reboot.
  8. Repetir nó a nó, verificando o cluster entre cada passo.

Espaço mínimo no root: 5 GB (idealmente 10+).

Estratégia de Actualização para a PME

  • 1 nó só, tudo essencial: janela de manutenção, backup externo, upgrade directo. Se falhar, restaurar num hardware qualquer e voltar a montar.
  • 2-3 nós em cluster: actualizar um nó de cada vez, com migração de guests. O CRS/HA do 9.2 só funciona com o cluster inteiro na 9.x — em cluster misto, evita-se fazer failover durante a janela.
  • Proxmox Backup Server co-instalado: actualizar o PBS primeiro (guia PBS 3→4), depois o PVE.

Artigos Relacionados