Migrando uma VM do GNOME Boxes para o Virt-Manager: O Processo de Investigação Que Revelou Dois Problemas Diferentes
Aprenda como migrar uma máquina virtual Rocky Linux do GNOME Boxes para o Virt-Manager em um Fedora Server sem reinstalar o sistema operacional. Neste estudo de caso real, mostramos todo o processo de troubleshooting, desde a transferência do disco QCOW2 até a investigação de problemas de conectividade envolvendo Libvirt, bridges virtuais, NAT, Firewalld e serviços de virtualização. Descubra a metodologia utilizada para identificar a causa raiz dos problemas e como uma abordagem lógica e cronológica pode acelerar a resolução de falhas complexas em ambientes KVM/QEMU.
Virtualização no Linux costuma ser extremamente confiável. Quando algo falha, a tendência é assumir que existe um único problema por trás de todos os sintomas. Mas, em alguns casos, a realidade é mais interessante.
Durante a migração de uma VM Rocky Linux da minha workstation Fedora para meu Home Server, me deparei com um daqueles cenários clássicos em que duas falhas completamente diferentes produziam sintomas praticamente idênticos.
O resultado foi um processo de troubleshooting que passou por rede, NAT, bridges, Libvirt, Firewalld, SELinux, KVM, QEMU e até mesmo pelos daemons internos do ecossistema de virtualização do Fedora.
Mais importante do que a solução final foi a lógica utilizada para chegar até ela.
Neste artigo vou mostrar exatamente como conduzi a investigação, quais hipóteses foram descartadas e por que a ordem correta dos testes foi fundamental para encontrar a causa real.
O Objetivo
A meta era simples:
Migrar uma VM Rocky Linux 10 criada originalmente no GNOME Boxes da workstation Fedora para um Fedora Server rodando KVM, QEMU, Libvirt e Virt-Manager remoto.
Nada de reinstalar sistema operacional.
Nada de recriar ambiente.
A ideia era aproveitar o disco virtual existente.
Primeira Etapa: Descobrindo o Disco da VM
O primeiro passo foi localizar exatamente qual arquivo de disco estava sendo utilizado pelo GNOME Boxes.
Após verificar a VM pelo Libvirt da workstation, identifiquei o disco QCOW2 utilizado pelo Rocky Linux e confirmei seu formato e tamanho.
Em seguida, utilizei o rsync para transferir o arquivo para o Home Server.
Esse tipo de migração é extremamente eficiente porque o QCOW2 já contém todo o sistema operacional instalado.
Na prática, estamos transportando um computador inteiro dentro de um único arquivo.
Preparando o Ambiente no Home Server
Após a transferência, foi necessário ajustar:
- Contexto SELinux
- Permissões do disco
- Storage Pools do Libvirt
- Redes virtuais
- Configuração do Virt-Manager remoto
Tudo isso foi sendo validado passo a passo.
Durante essa fase apareceu um primeiro problema interessante:
no polkit agent available
A causa era simples.
O usuário não fazia parte do grupo libvirt.
Depois de adicionar o usuário ao grupo correto e realizar novo login, o acesso remoto pelo Virt-Manager passou a funcionar normalmente.
A VM Inicializou Perfeitamente
Esse é o tipo de situação que engana muita gente.
A VM:
- Ligava normalmente
- Recebia endereço IP
- Detectava a placa de rede
- Obtinha gateway
Tudo parecia correto.
Mas existia um detalhe:
ping 8.8.8.8
Falhava.
O Erro Mais Comum em Troubleshooting
Quando uma VM não consegue acessar a internet, a maioria das pessoas pula imediatamente para:
- Firewall
- NAT
- DNS
- Docker
- SELinux
Eu segui um caminho diferente.
Em vez de procurar a solução, tentei primeiro descobrir exatamente onde a comunicação estava morrendo.
Essa pequena mudança de mentalidade economiza horas de troubleshooting.
Primeira Hipótese: SELinux
Como o Fedora utiliza SELinux em modo enforcing, esse foi um dos primeiros suspeitos.
O teste foi simples:
sudo setenforce 0
Nenhuma mudança.
Hipótese descartada.
Segunda Hipótese: Firewalld
O próximo suspeito foi o Firewalld.
Parei temporariamente o serviço para verificar se havia alguma regra bloqueando o tráfego.
Resultado:
Nenhuma alteração.
Problema continuava exatamente igual.
Terceira Hipótese: NAT
Como a rede virtual utilizava NAT, parecia uma explicação plausível.
Foram realizados testes nas tabelas NAT do sistema.
Nada mudou.
Nesse momento surgiu uma pergunta muito importante:
A VM sequer consegue chegar ao gateway?
A Descoberta Que Mudou Toda a Investigação
Dentro da VM executei:
ping 192.168.122.1
O resultado foi surpreendente.
Também falhou.
Isso mudou completamente o rumo da investigação.
Se a VM não alcança nem o gateway:
- Não é DNS
- Não é internet
- Não é NAT
- Não é roteamento externo
O problema está antes de tudo isso.
A Camada de Rede Virtual Virou o Foco
A partir desse ponto comecei a olhar para a infraestrutura virtual criada pelo Libvirt.
Foi então que apareceu o primeiro grande indício.
Ao verificar as bridges do sistema:
bridge link
A interface virtual da VM não aparecia conectada à bridge esperada.
Era esperado algo parecido com:
vnet0 master virbr0
Mas isso simplesmente não existia.
O Teste Decisivo
Em vez de continuar teorizando, resolvi testar.
Anexei manualmente a interface virtual à bridge:
sudo ip link set vnet0 master virbr0
Imediatamente a VM passou a responder aos testes de conectividade.
Esse foi um daqueles momentos clássicos em troubleshooting:
Você ainda não conhece a causa raiz.
Mas já sabe exatamente onde ela está.
Quando os Logs Finalmente Fazem Sentido
Com o problema isolado, parti para os logs.
Foi então que apareceu uma mensagem relacionada ao daemon:
virtnodedevd
O serviço não estava ativo.
Foram então habilitados:
- virtnodedevd
- virtnetworkd
- virtstoraged
Além do próprio virtqemud.
Mas a História Não Terminou Aí
Esse é o detalhe mais interessante.
Mesmo após corrigir os daemons do Libvirt, alguns sintomas continuavam aparecendo.
Isso indicava que talvez existisse um segundo problema.
E existia.
O Problema Anterior Que Estava Confundindo Tudo
Dias antes da migração da VM, eu já havia enfrentado um problema diferente.
A VM recebia IP normalmente.
Conseguia falar com o gateway.
Mas não acessava a internet.
À primeira vista parecia exatamente o mesmo defeito.
Mas não era.
A Diferença Entre os Dois Cenários
No primeiro problema:
VM -> Gateway -> Sem Internet
No segundo problema:
VM -> Nem chega ao Gateway
Percebe a diferença?
Os sintomas finais eram parecidos:
Sem internet
Mas a origem era completamente diferente.
O Uso do Tcpdump Mudou o Jogo
Para o problema anterior, utilizei capturas de tráfego.
Primeiro na bridge virtual.
Depois na interface física do servidor.
Os pacotes apareciam na bridge.
Mas nunca chegavam à placa de rede física.
Isso mostrou exatamente onde o tráfego estava morrendo.
Investigando o NAT da Libvirt
A análise avançou para as tabelas nftables e iptables.
Foi então que apareceu um detalhe fundamental.
As regras NAT do Docker estavam presentes.
Mas as regras MASQUERADE da Libvirt não existiam.
Ou seja:
O Libvirt criava a rede virtual.
Mas não criava corretamente as regras de NAT necessárias para que as VMs saíssem para a internet.
A Solução Temporária
A correção inicial foi feita manualmente utilizando regras de:
- FORWARD
- CONNTRACK
- MASQUERADE
diretamente no iptables.
O resultado foi imediato.
Os testes de conectividade voltaram a funcionar e a internet foi restabelecida.
O Que Realmente Aprendi Com Tudo Isso
A principal lição não foi sobre Libvirt.
Nem sobre Firewalld.
Nem sobre NAT.
Foi sobre metodologia.
Muita gente tenta resolver problemas de infraestrutura adicionando configurações aleatórias.
Eu prefiro responder uma pergunta simples:
Qual é exatamente o último ponto da comunicação que ainda funciona?
Quando você responde isso, o espaço de busca diminui drasticamente.
Foi exatamente isso que aconteceu aqui.
A Cronologia Correta da Investigação
O fluxo mental foi basicamente este:
1. Validar o sintoma
A VM não acessa a internet.
2. Validar a camada imediatamente anterior
A VM alcança o gateway?
3. Se não alcança o gateway
Investigar bridge, TAP e interfaces virtuais.
4. Se alcança o gateway
Investigar NAT, forwarding e roteamento.
5. Somente depois
Investigar DNS, aplicações e serviços externos.
Por Que Esse Método Funciona
Redes são sistemas em camadas.
Cada camada depende da anterior.
Se você ainda não provou que a VM alcança o gateway, não faz sentido perder horas analisando DNS.
Da mesma forma, se o gateway responde, talvez não faça sentido começar investigando aplicações.
O segredo está em eliminar possibilidades de forma sequencial.
Conclusão
A migração da VM Rocky Linux acabou revelando dois problemas completamente diferentes:
- Uma falha de NAT no ambiente Libvirt, onde as regras MASQUERADE não estavam sendo criadas corretamente.
- Um problema de conectividade entre a interface virtual da VM e a bridge do Libvirt, impedindo até mesmo a comunicação com o gateway.
O mais interessante é que ambos produziam o mesmo sintoma visível:
A VM não tem internet.
Mas a investigação mostrou que sintomas iguais não significam causas iguais.
Quando o troubleshooting é conduzido de forma cronológica, validando uma camada por vez, o processo deixa de ser tentativa e erro e passa a ser uma análise lógica.
E, no fim das contas, é exatamente isso que diferencia um administrador de sistemas que resolve problemas de alguém que apenas tenta configurações até algo funcionar.