Este relatório de setembro de 2025 deve ser tratado como uma falha histórica específica da versão beta do ZVM, e não como uma conclusão atual de que o “ZVM não funciona”. O utilizador estava a executar o ZimaOS 1.4.4-beta1 e observava repetidamente uma falha no arranque da VM com a mensagem interna client socket is closed. A Zima-Giorgio testou uma VM Ubuntu na mesma versão beta e afirmou que funcionava normalmente, pelo que o problema não era universal em todas as instalações da 1.4.4-beta1.
A parte útil do tópico é o estreitamento do diagnóstico. O KVM estava carregado, a rede predefinida e o pool de armazenamento do libvirt estavam ativos, e a reposição da configuração do libvirt não ajudou. Os registos posteriores mostraram virtqemud a falhar ao estabelecer ligação a um socket de rede do libvirt e a ser depois desativado.
Reiniciar o libvirt-guests não era a camada certa
O utilizador original reiniciou primeiro o serviço libvirt-guests.service. Um membro da comunidade salientou que este serviço trata principalmente do comportamento de guardar e restaurar convidados durante o encerramento do anfitrião; não é o daemon principal do QEMU/libvirt que inicia a VM.
Assim, um reinício bem-sucedido não provava que a pilha de VMs estivesse íntegra.
A aceleração de hardware KVM estava disponível
O utilizador verificou os módulos carregados e descobriu que ambos kvm e kvm_intel. Isso excluiu uma causa comum: a inexistência total de suporte de virtualização ao nível do kernel.
A rede predefinida e os pools de armazenamento estavam ativos
O tópico também verificou a rede predefinida e o pool de armazenamento do libvirt. Ambos foram indicados como ativos e acessíveis.
Isso tornou menos provável que a causa principal fosse a ausência do armazenamento das VMs ou uma rede NAT inativa.
Uma reposição completa da configuração do libvirt não resolveu o problema
O autor original eliminou a configuração em /etc/libvirt e /var/lib/libvirt e a falha continuou a reproduzir-se. Esse foi um passo de diagnóstico destrutivo e não deve ser promovido como solução inicial atual.
Num sistema de produção moderno, faça uma cópia de segurança das definições das VMs e das imagens de disco antes de alterar o estado do libvirt.
O registo posterior apontava para o virtqemud e para um socket de rede
O utilizador publicou então um erro mais útil: virtqemud falha ao estabelecer ligação a um socket em /var/run/libvirt/..., após o que o serviço foi desativado. Por conseguinte, a mensagem da interface sobre o socket do cliente fechado era provavelmente um sintoma secundário do problema do daemon do backend.
Um daemon que mostra “terminado com sucesso” pode, ainda assim, interromper o funcionamento da aplicação
Vários daemons do libvirt são ativados por socket e podem parar quando estão inativos, pelo que “inativo” por si só não prova uma falha. Neste caso, porém, a ligação explícita ao socket que falhou, juntamente com os registos de término da VM, tornou suspeita a interação com o backend.
Interprete o estado do systemd em conjunto com o erro real do libvirt/QEMU, e não com base numa única linha de estado isolada.
A IceWhale não conseguiu reproduzir a falha no seu ambiente de teste
Zima-Giorgio afirmou que uma VM Ubuntu funcionava normalmente na versão 1.4.4-beta1 e pediu o tipo de sistema operativo, além de capturas de ecrã/vídeo. Este é um limite oficial importante: a fonte mostra uma falha real de um utilizador, mas não uma indisponibilidade confirmada em toda a versão beta.
O utilizador escalou o problema como um erro da versão beta no GitHub
O autor publicou os registos detalhados e um vídeo no rastreador do GitHub da IceWhale, porque era difícil carregar ficheiros no fórum. O anexo era um vídeo, não uma captura de ecrã estática do fórum.
O tópico público do fórum não apresenta uma nota de lançamento nem um patch final que identifique uma única causa-raiz confirmada.
Não aplique a intervenção nos serviços da versão 1.4.4-beta1 ao ZimaOS atual
O ZimaOS atual está muito além desta versão beta. O empacotamento do libvirt, a interface do ZVM, o suporte de imagens e o comportamento dos serviços do systemd podem ser diferentes.
Para uma falha atual semelhante, recolha o erro da VM, a versão atual do ZimaOS, o estado do KVM, o estado da rede e do armazenamento do libvirt e os registos do QEMU antes de alterar ficheiros do sistema.
A falha mudou à medida que o utilizador recolheu melhores evidências
A teoria inicial era simplesmente que a versão beta do ZVM tinha um erro mais profundo, porque reiniciar um serviço não ajudava. A ronda seguinte estabeleceu que o KVM existia e que a rede e o armazenamento predefinidos estavam funcionais. Só depois disso é que o erro de socket dentro de virtqemud ficar visível.
Esta progressão é um bom modelo para a resolução de problemas de virtualização: evite passar diretamente de um erro genérico da interface para a reinstalação do hipervisor. Elimine, por ordem, as camadas de aceleração de hardware, armazenamento, rede e serviços.
virtqemud depende do resto da stack modular do libvirt
A falha registada fazia referência a um socket de rede do libvirt. No libvirt modular moderno, a gestão do QEMU, a gestão da rede, o registo e outras funções podem residir em daemons e sockets separados. Assim, um daemon do QEMU pode estar presente e, ainda assim, não conseguir comunicar com o daemon de rede de que necessita.
Isto ajuda a explicar por que razão uma VM podia falhar apesar de o KVM e o pool de armazenamento parecerem normais.
Os registos do QEMU mostraram que os convidados estavam a ser terminados
Os registos do QEMU do utilizador mostravam repetidamente processos convidados a terminar com o sinal 15 de virtqemud. Isto apoia a ideia de que os convidados estavam a ser terminados pela pilha de controlo da virtualização, em vez de falharem devido a uma ISO do Windows ou do Linux danificada.
O utilizador também testou várias imagens ISO e observou o mesmo comportamento, enfraquecendo ainda mais a explicação de que se tratava de um “meio de instalação danificado”.
Uma regressão na versão beta deve ser comparada com a versão estável antes de uma reparação destrutiva
Uma resposta da comunidade sugeriu reverter para o canal estável se fosse necessário utilizar VMs imediatamente. Esse é um limite de diagnóstico sensato para uma falha exclusiva da versão beta: se a mesma VM e o mesmo hardware funcionarem na versão estável, a versão beta torna-se a variável alterada mais provável.
O tópico de origem não inclui uma confirmação final do rollback por parte do autor original, pelo que isto continua a ser uma estratégia de diagnóstico, e não uma correção verificada na origem.
Para uma falha atual do ZVM, preserve o primeiro erro do backend
As mensagens da IU, como “o socket do cliente está fechado”, ocorrem frequentemente depois do evento relevante no backend. Capture os registos do sistema e do QEMU no momento exato em que clica em Iniciar e preserve o erro mais antigo, em vez de guardar apenas a mensagem de estado final.
Isto reduz o risco de tratar um sintoma a jusante como a causa principal.
FAQ histórico da versão beta do ZVM
O KVM estava ausente no caso de origem?
Não. O utilizador confirmou que os módulos KVM estavam carregados.
A reposição da configuração do libvirt resolveu o problema?
Não.
O problema foi confirmado em todos os sistemas com a versão 1.4.4-beta1?
Não. A Zima-Giorgio afirmou que uma VM de teste do Ubuntu funcionou normalmente na mesma versão beta.
Qual foi a pista mais forte no backend?
virtqemud registou uma falha ao ligar a um socket de rede do libvirt antes de desativar.
