Um convidado ZVM pode ter um endereço LAN válido e, ainda assim, não conseguir aceder aos serviços executados no próprio anfitrião ZimaOS. Esse foi o problema central neste tópico. Com a VM definida como Bridge to eth0, o convidado podia participar na LAN, mas indicava não ter uma rota para o anfitrião. Zima-Giorgio recomendou mudar a VM para NAT quando o objetivo fosse ligar-se às partilhas do ZimaOS.
A fonte também mostra que “rota de rede” e “permissão SMB” são problemas distintos. Mais tarde, um utilizador mudou para NAT e chegou à caixa de diálogo de início de sessão, mas continuou sem conseguir aceder à partilha RAID com várias contas. Esse problema de autenticação e armazenamento não deve ser confundido com o problema de isolamento do anfitrião no modo bridge.
O modo Bridge proporcionou à VM uma conectividade LAN normal
O utilizador original selecionou Bridge to eth0 porque queria que a VM se comportasse como outro dispositivo na rede local. Nesse modo, a VM podia obter um endereço LAN e comunicar com outros sistemas da LAN.
O caminho em falta era especificamente a comunicação VM ↔ anfitrião ZimaOS.
Zima-Giorgio recomendou NAT para acesso ao anfitrião
O Zima-Giorgio da IceWhale disse ao utilizador para desligar a VM e mudar a rede de Bridge para NAT. Num seguimento, descreveu a sua experiência como um compromisso: o NAT permite o acesso ao anfitrião, enquanto o bridge proporciona acesso a outros dispositivos da LAN.
Trata-se de uma orientação oficial do suporte no tópico de 2025, não de uma afirmação genérica sobre todas as topologias libvirt.
Relatos posteriores da comunidade continuaram a corresponder ao isolamento do anfitrião por macvtap
Em maio-junho de 2026, outro tópico da comunidade descreveu o mesmo padrão: uma VM em bridge recebeu um IP LAN normal, conseguiu aceder a outros dispositivos da LAN, mas não conseguiu fazer ARP nem ligar-se ao anfitrião ZimaOS. Mudar para NAT restaurou imediatamente a conectividade com o anfitrião.
Os utilizadores suspeitavam que o caminho “Bridge to eth0” do ZVM fosse implementado com macvtap, cujo comportamento de isolamento do anfitrião é bem conhecido. O tópico público não incluiu uma confirmação da IceWhale sobre a implementação exata, pelo que macvtap deve continuar a ser considerado uma explicação forte da comunidade, e não uma afirmação oficial sobre a implementação.
Os problemas de início de sessão SMB pertencem a uma camada separada
Um participante mudou para NAT e conseguiu finalmente aceder à caixa de diálogo de início de sessão do ZimaCube, mas as contas SMB continuaram a comportar-se de forma inconsistente. A conta principal conseguia navegar por alguns caminhos do anfitrião, mas o acesso ao RAID falhava, e outras contas devolviam erros de permissão.
Quando já existe conectividade IP básica, resolva separadamente a conta da partilha SMB e as respetivas permissões.
A documentação atual do ZimaOS descreve a partilha Samba por utilizador e as permissões de leitura/leitura e escrita. Utilize o modelo atual de permissões multiutilizador do Samba no ZimaOS quando uma VM consegue chegar ao servidor, mas a autenticação ou o acesso continuam a falhar.
As entradas Partilha de ficheiros e Início de sessão remoto do Ubuntu não utilizam o mesmo protocolo
O utilizador da fonte reparou que o Ubuntu apresentava “ZimaCube (File Sharing)” e “ZimaCube (Remote Login)”. O gestor de palavras-passe também mostrava uma ligação sftp:// para esta última.
SFTP sobre SSH e SMB são serviços diferentes. Um início de sessão SFTP bem-sucedido não prova que as permissões SMB estejam corretas, e uma partilha SMB deve ser testada com um URL SMB ou com um navegador de partilhas de rede, e não através da entrada SSH.
Um utilizador da comunidade criou uma solução com uma rota estática para o modo Bridge
Outro participante manteve a VM em bridge e utilizou um terceiro servidor Debian como router entre a VM e o anfitrião, adicionando depois rotas estáticas em ambos os pontos finais. Relatou que funcionava, mas descreveu o resultado como “não muito elegante”.
Esses comandos de encaminhamento do Linux foram experiências da comunidade, não o design recomendado pela IceWhale para o ZVM. O router adicional também se torna um estrangulamento da largura de banda e mais um ponto de falha.
Escolha a rede com base na função efetiva da VM
- A VM precisa principalmente de aceder a serviços ou partilhas alojados no ZimaOS: NAT é o primeiro teste suportado pela fonte.
- A VM precisa principalmente de se comportar como um dispositivo LAN separado: Bridge pode fornecer o endereço LAN normal.
- A VM precisa de acesso ao anfitrião e à LAN: teste cuidadosamente a versão atual do ZVM; a fonte histórica mostra que esta era a lacuna não resolvida.
As definições de rede atuais do ZimaOS não documentam um fluxo de trabalho ZVM com br0
A documentação pública atual sobre redes do ZimaOS abrange interfaces físicas, configuração de IP por DHCP/manual e acesso remoto. Não publica um procedimento suportado para criar uma bridge personalizada no anfitrião especificamente para contornar o comportamento de isolamento do anfitrião do ZVM.
Consulte o modelo de rede atual do ZimaOS antes de editar manualmente rotas do anfitrião ou ficheiros do NetworkManager.
Perguntas frequentes sobre o acesso do ZVM ao anfitrião
O NAT permitiu que a VM da fonte acedesse ao anfitrião ZimaOS?
Sim. Os utilizadores relataram que a mudança para NAT eliminou a barreira de não existir uma rota para o anfitrião.
O NAT corrigiu automaticamente as permissões SMB?
Não. Um utilizador chegou à caixa de diálogo de início de sessão, mas continuou a ter problemas separados com as permissões da partilha.
O encaminhamento através de um terceiro servidor era uma solução oficial?
Não. Era uma solução da comunidade para utilizadores que queriam manter o modo bridge.
