Proxmox VE 8 → 9: upgrade in-place sem perder o servidor

Antes de começar: você já está atrasado

O Proxmox VE 8 chegou ao fim de vida em 31 de agosto de 2026. Se o seu nó ainda está no 8.4, ele não recebe mais correção de segurança — nem no repositório enterprise, nem no no-subscription. Isso não é motivo para sair correndo e dar dist-upgrade às 23h de uma sexta, mas é motivo para parar de adiar.

E o aviso que importa mais que todos os comandos deste post: a parte perigosa do upgrade não é o apt. É a placa de rede mudar de nome e o servidor voltar do reboot sem rede. É o /etc/sysctl.conf deixar de ser lido e o roteamento parar de funcionar. É você descobrir, com o host offline, que o "backup" das VMs estava no mesmo disco do host.

Este guia é para um nó único, o cenário típico de homelab. Cluster e Ceph têm passos extras (ordem dos nós, quorum, HA, Ceph 19.2 Squid antes de tudo) que ficam fora do escopo.

---

O que realmente muda no PVE 9

Item	PVE 8	PVE 9
Base	Debian 12 (Bookworm)	Debian 13 (Trixie)
Kernel	6.8 / 6.11	6.14 ou mais novo
APT	2.6, .list	3.0, formato deb822 (.sources)
cgroups	v1 ainda suportado	v1 removido
/etc/sysctl.conf	lido	ignorado
Autoativação de LV	ligada	desligada por padrão em LVs novos
Nomes de NIC	podem mudar	ferramenta de pinning disponível

Cinco consequências práticas:

1. Nomes de interface de rede podem mudar. O kernel novo reconhece mais recursos do hardware e renomeia NICs (enp3s0 virando enp3s0f0np0, por exemplo). Se /etc/network/interfaces aponta para o nome antigo, a bridge não sobe e o host fica sem rede.
2. /etc/sysctl.conf deixa de ser honrado. Quem tem net.ipv4.ip_forward=1 ali (roteador, VPN, NAT em LXC) perde isso silenciosamente.
3. cgroup v1 foi removido. Containers com systemd anterior à versão 230 (Debian 9, CentOS 6 e afins) não iniciam mais.
4. LVM/LVM-thin: volumes novos nascem com autoativação desligada. Em setup local isso raramente incomoda; em LVM compartilhado é importante rodar a migração.
5. Passthrough de GPU: kernel novo, driver novo. NVIDIA GRID anterior à 18.3 é incompatível. Se você tem vGPU ou passthrough montado com driver compilado à mão, conte com retrabalho.

---

Parte 1 — Backup (a parte que as pessoas fazem errado)

Backup de VM não é backup do host. São duas coisas separadas e você precisa das duas.

1.1 Espaço e pré-requisitos

bash
df -h /            # mínimo 5 GB livres, ideal 10 GB+
pveversion         # precisa estar em 8.4.1 ou mais recente

1.2 Backup dos convidados (VMs e CTs)

Para um storage externo ao host — PBS, NFS, ou até um HD USB montado como storage do tipo Directory:

bash
# lista o que existe
qm list
pct list

# backup de tudo, comprimido, para o storage chamado "backup-externo"
vzdump --all --mode snapshot --compress zstd --storage backup-externo

Modo snapshot mantém o convidado ligado. Se a VM tem banco de dados e você quer consistência sem depender de qemu-guest-agent, use --mode stop.

Se o destino do vzdump é um dataset do mesmo pool ZFS que hospeda o host, isso não é backup. É uma cópia. Um pool que não importa leva as duas coisas junto.

1.3 Backup da configuração do host

O vzdump não salva nada disso, e é justamente o que você vai querer na mão se precisar reinstalar do zero:

bash
mkdir -p /root/pre-pve9 && cd /root/pre-pve9

# configuração do cluster/guests (pmxcfs)
cp -a /etc/pve  ./etc-pve

# /etc inteiro do host
tar czf etc.tar.gz /etc 2>/dev/null

# estado atual, para comparar depois
pveversion -v            > pveversion.txt
dpkg --get-selections    > pacotes.txt
ip -c addr               > rede-ip.txt
ip -c link               > rede-link.txt
cp /etc/network/interfaces interfaces.bak
lsblk -f                 > discos.txt
pvesm status             > storages.txt
{ pvs; vgs; lvs -a; }    > lvm.txt 2>&1
zpool status             > zpool.txt 2>&1
zfs list                 > zfs.txt 2>&1
cat /proc/cmdline        > cmdline.txt

Agora tire isso do servidor:

bash
scp -r /root/pre-pve9 usuario@outra-maquina:/caminho/seguro/

Anote também os nomes das NICs atuais e o endereço IP da interface de gerência. Você vai precisar dessa lista se a rede não voltar.

1.4 Ponto de retorno de verdade

Se o root é ZFS — a rede de segurança mais barata que existe:

bash
zfs snapshot -r rpool/ROOT@pre-pve9
zfs list -t snapshot | grep pre-pve9

Em caso de desastre, você dá boot por uma ISO do Proxmox em modo Rescue/Debug, importa o pool e faz zfs rollback -r rpool/ROOT/pve-1@pre-pve9. Não é instantâneo nem trivial, mas é a diferença entre uma hora ruim e uma reinstalação.

Se o PVE roda dentro de uma VM (aninhado, para testes): tire um snapshot do disco. É o rollback perfeito.

Se o root é ext4 em LVM: considere um snapshot LVM do volume root se houver espaço livre no VG, mas trate-o como um paraquedas frágil — em dist-upgrade grande ele pode encher e invalidar. O backup em 1.3 continua sendo o essencial.

1.5 A regra que ninguém segue

Restaure uma VM de teste a partir do backup, num storage diferente, antes de tocar no host. Backup não testado é fé, não é backup.

---

Parte 2 — Preparação

2.1 Console de emergência

Se o upgrade for pelo SSH e a rede cair, você fica sem servidor e sem sessão. Ou você tem IPMI/iDRAC/iLO, ou você tem acesso físico com teclado e monitor. Não existe terceira opção aceitável. Se você só tem SSH, no mínimo rode tudo dentro de um multiplexador:

bash
apt install -y tmux
tmux new -s upgrade
# se a conexão cair: ssh de volta e "tmux attach -t upgrade"

Alternativa: o shell do próprio nó pela interface web (noVNC) sobrevive a queda de SSH, mas não a queda de rede.

2.2 Desligue os convidados

Não é obrigatório, mas evita desligamento abrupto no reboot e libera I/O:

bash
qm list | awk 'NR>1 && $3=="running" {print $1}' | xargs -r -n1 qm shutdown
pct list | awk 'NR>1 && $2=="running" {print $1}' | xargs -r -n1 pct shutdown

Espere de fato pararem antes de seguir.

2.3 Rode o verificador

bash
pve8to9 --full

Ele não muda nada — só aponta problemas. Leia todo o resultado:

• PASS — ok.
• WARN — leia e decida. Muitos são informativos (aviso de subscription, por exemplo); outros são o seu próximo problema disfarçado.
• FAIL — pare e resolva. Não continue com FAIL na tela.

Os dois achados mais comuns:

"proxmox-ve package is too old" — você não está no 8.4.1+. Confira que os repositórios ainda apontam para bookworm/PVE 8, então:

bash
apt update && apt dist-upgrade
pveversion

Autoativação de LVM/LVM-thin — se o checker recomendar, rode a migração (relevante principalmente para LVM compartilhado):

bash
/usr/share/pve-manager/migrations/pve-lvm-disable-autoactivation

Rode o pve8to9 --full de novo até a lista ficar limpa.

2.4 Silencie o log de auditoria

O Trixie liga o systemd-journald-audit.socket, o que enche o journal de mensagens durante e depois do upgrade:

bash
systemctl disable --now systemd-journald-audit.socket

2.5 Migre o /etc/sysctl.conf agora

Faça isso antes do upgrade, enquanto o sistema ainda está saudável:

bash
grep -v '^\s*#' /etc/sysctl.conf | grep -v '^\s*$'

Cada linha que aparecer aí precisa virar um arquivo em /etc/sysctl.d/:

bash
cat > /etc/sysctl.d/90-local.conf <<'EOF'
net.ipv4.ip_forward = 1
EOF
sysctl --system

---

Parte 3 — Trocar os repositórios

3.1 Debian: bookworm → trixie

bash
sed -i 's/bookworm/trixie/g' /etc/apt/sources.list
sed -i 's/bookworm/trixie/g' /etc/apt/sources.list.d/*.list

Depois confira à mão — o sed não pensa:

bash
cat /etc/apt/sources.list
ls -la /etc/apt/sources.list.d/
grep -r bookworm /etc/apt/sources.list*

Qualquer coisa que ainda diga bookworm, ou qualquer repositório de terceiro (Docker, Grafana, Zabbix, *-backports) que não tenha suíte para o Trixie: comente com #. Repositório de terceiro pendurado é a causa número um de upgrade travado no meio. Você reativa depois, com calma.

3.2 Repositório do Proxmox no formato deb822

O PVE 9 usa o formato novo do APT. Garanta o keyring e crie o arquivo .sources correspondente ao seu caso.

bash
apt install -y proxmox-archive-keyring

Sem subscription (homelab):

bash
cat > /etc/apt/sources.list.d/proxmox.sources <<'EOF'
Types: deb
URIs: http://download.proxmox.com/debian/pve
Suites: trixie
Components: pve-no-subscription
Signed-By: /usr/share/keyrings/proxmox-archive-keyring.gpg
EOF

Com subscription:

bash
cat > /etc/apt/sources.list.d/pve-enterprise.sources <<'EOF'
Types: deb
URIs: https://enterprise.proxmox.com/debian/pve
Suites: trixie
Components: pve-enterprise
Signed-By: /usr/share/keyrings/proxmox-archive-keyring.gpg
EOF

Remova o arquivo .list antigo equivalente para não ter a mesma origem duas vezes:

bash
rm -f /etc/apt/sources.list.d/pve-enterprise.list
# e o pve-no-subscription.list, se existir

Ceph hiperconvergente: existe um .sources próprio (ceph-squid, suíte trixie) e o cluster Ceph precisa estar em 19.2 Squid antes do upgrade do PVE. Fora do escopo deste post — consulte a wiki.

3.3 Valide antes de puxar o gatilho

bash
apt update
apt policy

Se aparecer erro de chave, 404, ou "Release file not found", resolva agora. Depois do dist-upgrade iniciado, o custo do erro é outro.

Uma simulação a seco é barata e mostra o tamanho do estrago:

bash
apt dist-upgrade --dry-run | tail -30

Se a saída mencionar remoção do pacote proxmox-ve, pare. Isso significa repositório inconsistente — volte ao passo 3.1.

---

Parte 4 — O upgrade

bash
apt dist-upgrade

São milhares de pacotes; de 15 a 45 minutos, dependendo do disco e da internet. Não interrompa.

No meio do caminho o dpkg vai perguntar sobre arquivos de configuração modificados. As respostas seguras:

Arquivo	Resposta
/etc/issue	manter local (N) — é gerado automaticamente
/etc/lvm/lvm.conf	instalar a nova versão (Y)
/etc/ssh/sshd_config	Y se você não alterou; N se alterou (porta, chaves, PermitRootLogin)
/etc/default/grub	manter local (N), salvo se você não personalizou nada
/etc/chrony/chrony.conf	Y se não alterou

Na dúvida, escolha D para ver o diff antes de decidir. Quando você mantém a versão local, o pacote deixa a nova em .dpkg-dist ao lado — dá para conciliar depois.

Se a tela ficar parada muito tempo sem I/O aparente, é provavelmente um prompt de serviço aguardando confirmação. Não mate o processo.

---

Parte 5 — Depois do upgrade, antes do reboot

bash
pve8to9 --full

Resolva o que aparecer. Se o sistema for UEFI com root em LVM, a wiki recomenda garantir o GRUB EFI:

bash
[ -d /sys/firmware/efi ] && apt install -y grub-efi-amd64

E então:

bash
reboot

O reboot é o momento de verdade

Fique no console. Se a rede não voltar, é aqui que você descobre — e é aqui que o acesso físico/IPMI paga a si mesmo.

Depois que voltar:

bash
pveversion              # deve mostrar pve-manager/9.x
uname -r                # kernel 6.14+
systemctl --failed      # nada aqui, idealmente
ip -c a                 # as interfaces têm os nomes de antes?
pvesm status            # storages online?
qm list ; pct list
journalctl -p err -b    # erros deste boot

Na interface web, force o recarregamento com Ctrl+Shift+R. Tela em branco ou layout quebrado quase sempre é cache do navegador, não o servidor.

Modernize os repositórios (opcional)

Com o sistema estável, converta o que sobrou de .list para o formato novo:

bash
apt modernize-sources
apt update

Reative, um a um, os repositórios de terceiros que você comentou, verificando se já têm suíte para Trixie.

---

Parte 6 — Quando dá errado

O host voltou sem rede

O sintoma clássico do PVE 9. Do console:

bash
ip -c link          # quais NICs existem AGORA
cat /etc/network/interfaces   # quais nomes o arquivo espera

Comparou e viu que mudou? Edite /etc/network/interfaces trocando o nome antigo pelo novo (a bridge-ports da vmbr0 costuma ser o único ponto) e:

bash
ifreload -a
# se o ifupdown2 reclamar:
systemctl restart networking

Para nunca mais passar por isso, o PVE 9 traz o pinning de interfaces, que gera arquivos .link do systemd fixando nomes estáveis (nic1, nic2, …):

bash
pve-network-interface-pinning generate

Ele reescreve a configuração de rede com os nomes fixos. Faça isso com o sistema já estável, com console à mão, e reveja o resultado antes de reiniciar.

"O apt quer remover o proxmox-ve"

Nunca aceite. Significa que algum repositório ainda está em Bookworm ou que o repositório do PVE 9 não foi lido. Revise /etc/apt/sources.list*, corrija, apt update, e repita o --dry-run.

O dist-upgrade parou no meio

bash
dpkg --configure -a
apt -f install
apt dist-upgrade

Se a causa foi disco cheio, libere primeiro:

bash
apt clean
journalctl --vacuum-size=200M

Depois retome. Não reinicie com o upgrade pela metade se puder evitar.

Não boota / erro do GRUB

Boot pela ISO do Proxmox VE 9 em modo Rescue. Se o root é ZFS com BIOS legado, instalado antes do PVE 6.4, o problema costuma ser o GRUB antigo lendo o pool — a solução recomendada é migrar para o proxmox-boot-tool. Consulte os artigos da wiki "Recover From Grub Failure" e o de migração para o proxmox-boot-tool.

Um LXC não inicia mais

Se for Debian 9, CentOS 6 ou outro sistema com systemd < 230, ele dependia de cgroup v1 e não vai voltar. Não há workaround suportado. Caminhos: migrar o serviço para um container moderno, ou converter o LXC em VM.

Roteamento/NAT parou de funcionar

/etc/sysctl.conf não é mais lido. Confira:

bash
sysctl net.ipv4.ip_forward

Se voltou 0, você esqueceu o passo 2.5. Crie /etc/sysctl.d/90-local.conf e rode sysctl --system.

Passthrough de GPU quebrou

Kernel e QEMU novos. Reconfira /etc/modprobe.d/vfio.conf, os IDs em vfio-pci, o blacklist do driver nativo e os parâmetros de kernel em /etc/default/grub ou no proxmox-boot-tool (se você mudou o GRUB, update-grub; se usa proxmox-boot-tool, proxmox-boot-tool refresh). Drivers NVIDIA GRID anteriores à 18.3 não funcionam com o kernel do PVE 9 — atualize o driver do host e o dos convidados juntos.

Aviso de "no valid subscription"

Continua existindo no PVE 9, e continua sendo só um aviso. Ignore, ou compre uma subscription.

---

Sobre rollback: não existe

Vale dizer isso com todas as letras, porque quase todo tutorial omite: não há downgrade de PVE 9 para PVE 8. Não existe apt que desfaça um dist-upgrade de versão maior. As únicas saídas reais são:

1. Rollback do snapshot ZFS do root (se você fez).
2. Rollback do snapshot da VM (se o PVE era virtualizado).
3. Reinstalar o PVE 8.4... que está EOL, o que só faz sentido como medida temporária.
4. Reinstalar o PVE 9 do zero e restaurar os backups.

Isso é exatamente por que a Parte 1 é a metade importante deste post.

---

Checklist para imprimir

Antes

• [ ] pveversion mostra 8.4.1 ou mais recente
• [ ] 5 GB+ livres em /
• [ ] vzdump de todas as VMs/CTs em storage externo
• [ ] Uma restauração de teste feita com sucesso
• [ ] /etc/pve e /etc copiados para fora do host
• [ ] Nomes de NIC e IPs anotados
• [ ] Snapshot ZFS do root (ou snapshot da VM)
• [ ] Console físico ou IPMI disponível
• [ ] pve8to9 --full sem nenhum FAIL
• [ ] sysctl.conf migrado para /etc/sysctl.d/
• [ ] Repositórios de terceiros comentados

Durante

• [ ] Convidados desligados
• [ ] Sessão dentro do tmux (ou console)
• [ ] apt dist-upgrade --dry-run não remove proxmox-ve
• [ ] Prompts de conffile respondidos com critério

Depois

• [ ] pve8to9 --full limpo
• [ ] Reboot acompanhado pelo console
• [ ] pveversion em 9.x, kernel 6.14+
• [ ] Rede, storages, VMs e CTs conferidos
• [ ] systemctl --failed vazio
• [ ] Cache do navegador limpo
• [ ] apt modernize-sources executado
• [ ] Repositórios de terceiros reativados um a um

---

Fontes

• Upgrade from 8 to 9 — Wiki oficial do Proxmox VE
• Roadmap / Release Notes do Proxmox VE
• Network Configuration — Wiki do Proxmox VE
• Still Running Proxmox VE 8? Here's What You Need to Do Before End of Life
• The Proxmox 9 Feature That Finally Fixes NIC Renaming Problems

Este guia cobre nó único. Para cluster e Ceph, a wiki oficial tem a ordem correta de operações — e ali a improvisação custa caro.