Topologie réseau

La vue topologie est un graphe d’état désiré éditable superposé à l’état runtime libvirt découvert. Garder ces deux couches distinctes évite de confondre une carte sur le canevas avec une infrastructure déployée.

Modèle de graphe

Élément	État désiré	Preuve runtime
Nœud VM	Nom, ressources, disques, variant de boot, position	ID/nom de domaine, état d’alimentation, interfaces, résultat de déploiement
Nœud réseau	Nom logique, type, sous-réseau, position	Nom réseau libvirt, bridge, état actif, état DHCP
Arête	Attachement VM-réseau voulu	Interface/MAC attachée au réseau runtime attendu

Les nœuds peuvent être planned, provisioning, running, stopped ou failed. Utilisez l’état texte et les détails de déploiement ; la couleur est un indice secondaire et peut changer avec le thème UI.

Choix réseau

Les réseaux NAT fournissent une sortie invité via un réseau libvirt géré lorsque l’hôte et la politique le permettent.
Les réseaux isolés fournissent une connectivité VM-à-VM sans route externe.
Un comportement bridge ou internet direct supplémentaire dépend de l’opérateur et du déploiement ; il n’est pas impliqué par le tracé d’une arête.

Pour adressage statique, le sous-réseau rédigé, la passerelle, adresses réservées, plage DHCP, réservations MAC et configuration invité doivent concorder. Une arête de graphe seule ne configure pas une adresse dans un invité arbitraire.

Édition et déploiement

Sélectionnez le bon périmètre projet/build avant édition.
Ajoutez nœuds VM et réseau et connectez leurs poignées.
Sélectionnez une image de boot et des ressources pour chaque VM.
Enregistrez la topologie et confirmez que la révision serveur avance.
Déployez les nœuds et attendez les données de superposition runtime.
Vérifiez chaque arête désirée contre les interfaces réelles de la VM.

La topologie projet est persistée sur le serveur avec vérifications de révision. L’UI utilise aussi des caches locaux et des enregistrements debounced ; attendez la fin de l’enregistrement avant de changer de périmètre ou fermer la page. Une erreur d’enregistrement signifie que le canevas n’est pas encore durable.

Exemples de vérifications d’acceptation

Pour une topologie client/API :


client -- isolated-lan -- api
                     \
                      nat-egress (only if required)

Vérifiez tout ce qui suit :

les deux domaines existent et sont en cours ;
les deux ont une interface sur le même réseau isolé runtime ;
la résolution nom/adresse mappe api vers l’invité voulu ;
une assertion http_responds côté client atteint le point de santé API ;
le réseau isolé n’a pas de route externe non voulue ;
toute arête NAT n’existe que là où la recette exige une sortie.

Rafraîchissement et export

L’état runtime est rafraîchi depuis l’inventaire backend et peut légerement retarder une requête de cycle de vie. Rafraîchissez manuellement lors de la validation d’une transition. Certaines vues topologie exposent un export JSON pour documentation ; un graphe exporté est une donnée d’état désiré, pas une sauvegarde de disques VM ni une preuve que le runtime correspondait.

Voir Créer des VM et Assertions personnalisées.