Un invité ZVM peut disposer d’une adresse LAN valide tout en échouant à atteindre les services exécutés directement sur l’hôte ZimaOS. C’était le problème central de cette discussion. Lorsque la VM était configurée sur Bridge to eth0, l’invité pouvait participer au réseau local, mais n’avait aucune route vers l’hôte. Zima-Giorgio a recommandé de passer la VM en mode NAT lorsque l’objectif était de se connecter aux partages ZimaOS.
La source montre également que la « route réseau » et les « autorisations SMB » sont deux problèmes distincts. Plus tard, un autre utilisateur est passé en mode NAT et a atteint la boîte de dialogue de connexion, mais ne pouvait toujours pas accéder au partage RAID avec plusieurs comptes. Ce problème d’authentification et de stockage ne doit pas être confondu avec le problème d’isolation de l’hôte en mode bridge.
Le mode bridge donnait à la VM un accès LAN normal
L’utilisateur initial avait sélectionné Bridge to eth0 parce qu’il voulait que la VM se comporte comme un autre appareil du réseau local. Dans ce mode, la VM pouvait obtenir une adresse LAN et communiquer avec les autres systèmes du réseau local.
Le chemin manquant concernait spécifiquement la communication VM ↔ hôte ZimaOS.
Zima-Giorgio a recommandé le mode NAT pour accéder à l’hôte
Zima-Giorgio, d’IceWhale, a demandé à l’utilisateur d’arrêter la VM et de remplacer le mode réseau Bridge par NAT. Dans un message de suivi, il a décrit son expérience comme un compromis : le NAT permet d’accéder à l’hôte, tandis que le bridge permet d’accéder aux autres appareils du réseau local.
Il s’agit d’une recommandation officielle du support dans la discussion source de 2025, et non d’une affirmation générale concernant toutes les topologies libvirt.
Des témoignages ultérieurs de la communauté correspondaient toujours à l’isolation de l’hôte par macvtap
En mai-juin 2026, une autre discussion communautaire a décrit le même comportement : une VM en mode bridge recevait une adresse IP LAN normale, pouvait atteindre les autres appareils du réseau local, mais ne pouvait ni effectuer de requête ARP ni se connecter à l’hôte ZimaOS. Le passage au mode NAT a immédiatement rétabli la connectivité avec l’hôte.
Les utilisateurs soupçonnaient que le chemin « Bridge to eth0 » de ZVM était implémenté avec macvtap, dont le comportement d’isolation de l’hôte est bien connu. La discussion publique ne contenait aucune confirmation d’IceWhale concernant le backend exact. macvtap doit donc rester une explication communautaire solide plutôt qu’une affirmation officielle sur l’implémentation.
Les problèmes de connexion SMB constituent une couche distincte
Un participant est passé au mode NAT et a enfin pu atteindre la boîte de dialogue de connexion de ZimaCube, mais les comptes SMB se comportaient toujours de manière incohérente. Son compte principal pouvait parcourir certains chemins de l’hôte, tandis que l’accès au RAID échouait, et d’autres comptes renvoyaient des erreurs d’autorisation.
Une fois la connectivité IP de base établie, dépannez séparément le compte du partage SMB et ses autorisations.
Les documents actuels de ZimaOS décrivent le partage Samba par utilisateur ainsi que les autorisations de lecture et de lecture-écriture. Consultez le modèle actuel d’autorisations Samba multi-utilisateur de ZimaOS lorsqu’une VM peut atteindre le serveur, mais que l’authentification ou l’accès échoue encore.
Les entrées Partage de fichiers et Connexion à distance d’Ubuntu n’utilisent pas le même protocole
L’utilisateur source a remarqué qu’Ubuntu affichait « ZimaCube (File Sharing) » et « ZimaCube (Remote Login) ». Son gestionnaire de mots de passe affichait également une connexion sftp:// pour cette dernière.
SFTP via SSH et SMB sont deux services différents. Une connexion SFTP réussie ne prouve pas que les autorisations SMB sont correctes, et un partage SMB doit être testé avec une URL SMB ou un navigateur de partage réseau plutôt qu’avec l’entrée SSH.
Un utilisateur de la communauté a créé une solution de routage statique pour le mode bridge
Un autre participant a conservé la VM en mode bridge et utilisé un troisième serveur Debian comme routeur entre la VM et l’hôte, puis ajouté des routes statiques sur les deux extrémités. Il a indiqué que cela fonctionnait, tout en qualifiant le résultat de « pas très élégant ».
Ces commandes de routage Linux relevaient de l’expérimentation communautaire et ne constituaient pas une conception ZVM recommandée par IceWhale. Le routeur supplémentaire devient également un goulot d’étranglement pour le débit et un point de défaillance supplémentaire.
Choisissez le réseau en fonction du rôle réel de la VM
- La VM doit principalement accéder aux services ou aux partages hébergés par ZimaOS : le NAT est le premier test pris en charge par la source.
- La VM doit principalement se comporter comme un appareil distinct du réseau local : le mode bridge peut lui fournir une adresse LAN normale.
- La VM doit accéder à la fois à l’hôte et au réseau local : testez attentivement la version actuelle de ZVM ; la source historique montre que cette situation constituait une lacune non résolue.
Les paramètres réseau actuels de ZimaOS ne documentent pas de procédure br0 pour ZVM
La documentation publique actuelle sur le réseau de ZimaOS couvre les interfaces physiques, la configuration IP automatique ou manuelle et l’accès à distance. Elle ne publie pas de procédure prise en charge pour créer un bridge hôte personnalisé afin de contourner le comportement d’isolation de l’hôte de ZVM.
Consultez le modèle réseau actuel de ZimaOS avant de modifier manuellement les routes de l’hôte ou les fichiers NetworkManager.
FAQ sur l’accès de ZVM à l’hôte
Le NAT a-t-il permis à la VM source d’atteindre l’hôte ZimaOS ?
Oui. Les utilisateurs ont indiqué que le passage au NAT supprimait l’obstacle « aucune route vers l’hôte ».
Le NAT a-t-il automatiquement corrigé les autorisations SMB ?
Non. Un utilisateur a atteint la boîte de dialogue de connexion, mais rencontrait toujours des problèmes distincts d’autorisation sur les partages.
Le routage via un troisième serveur était-il officiel ?
Non. Il s’agissait d’une solution communautaire destinée aux utilisateurs souhaitant conserver le mode bridge.
