Maintenant place à la synthèse :
J’ai donc étudié la question pendant deux-trois jours avec les docs fournies ici et trouvées sur le net et j’ai finalement réussi à faire fonctionner cette histoire de VM.
Je suis maintenant capable de gérer complètement à distance le serveur lui-même (démarrage par wake-on-lan et arrêt via ssh) ainsi que la création suppression et administration des VM, quelles qu’elles soient…
Pour cela il m’a fallu :
- passer en IPv4 full-stack chez Free, je le conseille à tous, ça m’a déjà résolu une très grosse partie du problème en m’octroyant le contrôle sur tous les 65000 et quelques ports…
- à partir de là il ne reste plus qu’à configurer “Virt-Manager”, Remmina, ssh et autres avec les bonnes ouvertures de port au niveau de la box et du serveur hôte.
Je n’irai pas jusqu’à dire que c’est uniquement l’histoire de l’IP en full-stack qui était à la source du problème, j’avais également une vision du problème erronée..
Par contre je ne peux toujours pas communiquer directement avec mes VM (en dehors de Virt-Manager) et pour une raison de taille, c’est écrit noir sur blanc dans la documentation “libvirt” :
- l’interface virbrX par défaut permet la communication entre les VM elles-même, entre les VM et l’hôte physique et les communication sortantes des VM
- elle restreint toute communication entrante
Il faut donc trouver un autre subterfuge…. La réponse à ça dans la suite, avec citation du commentaire de @VINDICATORs :
VINDICATORs Il y a des solutions qui demande de bonnes connaissances sur le sujet. Voir la doc dont je parle plus haut avec les tables de routages sur les hôtes physiques par exemple.
Après j’ai aussi des VM avec 2 cartes réseaux dont une sur le réseau interne virbrx et l’autre direct/macvtap. La première servant a administrer la VM a partir de l’hôte et de communiquer entre celles de celui-ci.
Mais bon là le sujet c’est l’accès par vnc/spice a distance qui est géré par l’hôte.
J’ai indiqué les Modifs a faire. Pour le reste il faut voir comment ce fut géré de base.
Commençons par les modifs… Effectivement ce furent les bonnes modifs, mais ça n’a pas très bien fonctionné avant le passage en IPv4 full-stack. Néanmoins avec ce passage + la configuration de “Virt-Manager” qui permet un contrôle total, c’est un pur bonheur de gérer tout ça… J’adore “Virt-Manager” je l’ai déjà dit, non? 😃
Donc @VINDICATORs merci encore une fois! Je ne connaissais pas toutes les possibilités de “Virt-Manager”, et bien sûr comme la plupart du temps on se contente de lire et apprendre que ce qui nous intéresse, parfois par manque de temps aussi, voilà où ça nous mène… Mais tu m’as mis sur la voie, et ça a payé.
Revenons maintenant à cet accès extérieur aux VM…
Alors oui là le sujet c’était à la base l’accès par Spice/VNC à distance, du moins c’est comme ça que je l’ai dénommé… Mais en fait je disais plus haut que j’avais eu une vision erronée du problème et pour cause : j’avais mis dès le départ dans le même sac les deux problèmes… Pour moi c’était la même chose, alors qu’en réalité ça ne l’est pas… C’est ce qui m’a conduit à m’éparpiller en fait.
Donc effectivement, il devrait y avoir plusieurs solutions à ce problème de communications entrantes directement vers les VM :
- les tables de routage
- intégrer deux interfaces virtuelles ou plus sur chaque VM afin que l’une (virbrX) communique en local et l’autre offre un accès public bi-directionnel
- …
Encore une fois, je pensais m’en tirer simplement et rapidement, mais je vois que c’est mort, que je vais encore avoir droit aux études de docs… 😃
Pourtant, j’avais fait ce genre de choses à l’époque de l’avènement de “systemd-nspawn” que j’utilisais pour monter mon serveur BIND et quelques machines minimales lancées avec cette commande au démarrage.
J’utilisais NetworkManager pour la connexion réseau par défaut, mais pour tout ce qui était lancé avec “systemd-nspawn” j’avais utilisé “systemd-networkd” et “systemd-resolved”.
Notamment “systemd-networkd” m’avait permis de gérer ces différents sous-réseaux que j’avais configuré manuellement avec les fichier '*.network" et qui m’avaient permis de créer des interfaces avec une adresse IP à l’intérieur du sous-réseau des machines, et une autre adresse IP vue de l’extérieur de cette interface et qui appartenait au sous-réseau local… Et cette interface ainsi configurée faisait la translation d’adresses.
Le problème est que ça date maintenant de quelques années et que je ne me rappelle plus comment faire… Donc je vais sans doute avoir droit aux docs… 😃
