Troubleshooting pós-migração de máquina virtual

Resumo executivo

Contexto

Uma aplicação web crítica roda em uma máquina virtual Linux: o backend Java/Spring fica em um contêiner Docker e o Apache, instalado no próprio sistema, publica o serviço em HTTPS como proxy reverso. A máquina foi migrada a frio do cluster de origem, baseado em KVM, para o ambiente VMware.

Problema

Depois da conversão, a máquina ligava, mas ninguém conseguia usá-la. A senha de root não funcionava, o SSH não respondia e, depois de resolvidos esses dois pontos, o site mostrava HTTP 503 Service Unavailable. Cada bloqueio só aparecia quando o anterior era resolvido.

Meu papel

recuperar o acesso administrativo sem depender de rede, pelo console do hipervisor;
isolar a falha de rede entre sistema operacional, rota e switch virtual;
separar falha da aplicação de falha do proxy reverso no erro 503;
registrar causa raiz e ação de cada fase e propor as correções preventivas.

Resultado

Serviço 100% operacional, sem perda de dados e sem rollback da migração.
Três causas raiz independentes identificadas, uma por camada (acesso, rede, aplicação).
Três recomendações de arquitetura: adaptador de rede paravirtualizado, VMware Tools no convidado e dependência de inicialização entre Apache e contêiner.

O que este caso demonstra

Troubleshooting em camadas
Linux: boot, GRUB e recuperação
Redes virtuais: vSwitch e Port Group
Migração entre hipervisores
Proxy reverso e contêineres
Análise pós-incidente

Detalhes técnicos

Roteiro da investigação

Sintoma
Acesso pelo console
Senha de root
Interface e rota
Camada 2
Backend
Proxy reverso
Prevenção

Fase 1: acesso administrativo

Sem credencial válida e com o SSH inacessível, o único caminho era o console do hipervisor. A senha de root não foi aceita depois da conversão.

Interrompi a inicialização no menu do GRUB.
Na linha do kernel, troquei a montagem para leitura e escrita e pedi um shell como processo inicial: rw init=/bin/bash.
O sistema subiu direto em shell de root, sem serviços.
Redefini a senha com passwd root, gravei em disco com sync e reiniciei com reboot -f.

Fase 2: conectividade

O sistema subiu com endereço estático, mas sem nenhum tráfego de saída.

Interface renomeada: no KVM a placa era VirtIO e se chamava ens3; no VMware virou um adaptador emulado, com outro nome (ens32). A configuração de rede apontava para a interface antiga.
Rota conferida: depois de ajustar a interface, a rota padrão estava correta. Isso descartou a tabela de rotas do kernel.
Camada 2: ainda sem resposta, nem a ARP. A causa estava fora da máquina: o Port Group do switch virtual não correspondia à VLAN da rede de origem. Ajustado o Port Group, a resolução ARP e a comunicação externa voltaram.

Fase 3: HTTP 503

Com a rede de pé, o Apache respondia na porta 443, mas com 503.

Ordem de inicialização: o Apache subiu logo no boot, enquanto o backend Java/Spring do contêiner ainda carregava o contexto.
Backend saudável: os logs mostraram o pool de conexões com o banco (HikariCP/JPA) conectado e as transações fluindo. O problema não estava na aplicação.
Proxy: as primeiras tentativas falharam e o Apache marcou o destino interno como indisponível por um tempo. Um systemctl restart apache2 limpou esse estado e restabeleceu o encaminhamento para a porta interna.

Causa raiz por fase

Fase	Sintoma	Causa raiz	Solução
1. Acesso	Senha de root recusada, SSH fora do ar	Credencial de root não compatível ou redefinida na conversão	Boot interrompido no GRUB e senha redefinida pelo console
2. Rede	IP configurado, nenhum tráfego	Troca de VirtIO para adaptador emulado (novo nome de interface) e Port Group em VLAN divergente	Configuração da nova interface, rota conferida e Port Group corrigido
3. Aplicação	HTTP 503 na porta 443	Proxy reverso iniciado antes do backend; destino marcado como indisponível	Backend validado pelos logs e reinício limpo do Apache

Recomendações preventivas

Adaptador VMXNET3

O adaptador emulado funciona, mas custa mais CPU no host. Agendar janela para trocar pelo VMXNET3, paravirtualizado, que reduz interrupções e aumenta a vazão. A troca muda o nome da interface de novo, então entra no checklist com a configuração de rede.

VMware Tools no convidado

Garantir o open-vm-tools ativo, para desligamento limpo, sincronismo de relógio e snapshots consistentes. É a contrapartida do agente de convidado que a plataforma de origem usava.

Apache depois do contêiner

Fazer o serviço do Apache esperar o contêiner ficar healthy antes de abrir a porta 443, por exemplo com uma verificação de saúde antes da inicialização no systemd. Assim um reboot programado não mostra 503 ao usuário.

Lições para a próxima migração

Antes de migrar, confirmar uma credencial local de recuperação e testar o acesso pelo console de destino.
Registrar o nome e o tipo da interface de rede e a VLAN de origem; conferir os dois logo depois da conversão.
Validar a aplicação de fora para dentro: porta pública, proxy, backend e banco, nessa ordem.

Limitações

A Fase 1 mostra que quem tem console do hipervisor tem root na máquina. Proteger o GRUB com senha e restringir o acesso ao console reduzem esse risco, mas não fizeram parte deste atendimento.
As recomendações preventivas foram propostas no relatório; a implantação depende de janela de manutenção.
Endereços, máscara, gateway, VLANs, nomes de servidores e da aplicação e identificadores do ambiente não são publicados.

Evidências

Endereços IP, MAC, máscara, gateway, VLAN, hostnames e nome da aplicação foram omitidos ou trocados por marcadores. Os blocos abaixo são reconstruções sintéticas a partir do relatório: os comandos e as etapas são os do atendimento, e a saída foi simplificada.

Mapa das fases: o usuário via um único sintoma (“o sistema não abre”), com três causas em camadas diferentes.

Recuperação de acesso pelo console

# menu do GRUB: tecla e na entrada padrão, linha do kernel
linux /boot/vmlinuz-5.15... root=[DISCO] rw init=/bin/bash
# Ctrl+X para iniciar
root@(none):/# passwd root
root@(none):/# sync
root@(none):/# reboot -f

Rede depois da conversão

# a interface mudou de nome com a troca de adaptador
$ ip -br link
lo      UNKNOWN
ens32   UP        [MAC do fabricante do hipervisor]
# rota padrão correta: a tabela do kernel não era o problema
$ ip route
default via [GATEWAY] dev ens32
# sem resposta ARP até corrigir o Port Group no switch virtual

Erro 503 e validação do backend

# porta pública: proxy responde, destino interno indisponível
$ curl -sk -o /dev/null -w '%{http_code}\n' https://localhost/
503
# logs do contêiner: backend terminou de subir e conectou ao banco
HikariPool-1 - Start completed.
Initialized JPA EntityManagerFactory for persistence unit 'default'
# proxy ainda com o destino marcado como indisponível: reinício limpo
$ systemctl restart apache2
$ curl -sk -o /dev/null -w '%{http_code}\n' https://localhost/
200

Linhas de log e chamadas de teste reconstruídas a partir do relatório, no formato padrão das ferramentas; nomes de contêiner, banco e aplicação omitidos.

Matriz de ações

Ação	Prioridade	Status
Redefinir senha de root	Crítica	Concluído
Interface e Port Group	Crítica	Concluído
Reinício limpo do proxy	Crítica	Concluído
Trocar adaptador para VMXNET3	Média	Recomendado
open-vm-tools ativo	Média	Recomendado
Apache esperar contêiner saudável	Alta	Recomendado

Versão didática

Como eu ensinaria este conceito

O caso mostra que um sistema funciona em camadas e que um único sintoma pode esconder vários problemas empilhados. A turma aprende a testar de baixo para cima: primeiro “consigo entrar?”, depois “tenho rede?” e só então “o programa responde?”.

Público

Ensino Médio técnico, cursos de redes e suporte e formação de professores de Computação.

Pré-requisitos

Noção de sistema operacional, endereço IP e site na internet.

Analogia

Mudança de casa: a chave antiga não abre a porta nova, o endereço no correio ainda é o antigo e, quando a loja abre, o estoque ainda está nas caixas. Cada problema só aparece quando o anterior é resolvido.

Experimento mínimo

Com uma máquina virtual de laboratório, a turma desliga a placa de rede, para o serviço web e anota o erro que o navegador mostra em cada caso. Depois tenta descobrir, só pelo erro, qual camada falhou.

Erro comum

Ver “erro 503” e concluir que o programa travou, sem conferir se o problema está no meio do caminho, no servidor que repassa os pedidos.

Pergunta de reflexão

Se quem tem acesso ao console consegue trocar a senha de root, como proteger um servidor contra isso?

O laboratório A Rede Parou usa o mesmo método de investigação com registros fictícios de uma escola.