Netzwerk-Topologie

Die Topologie-Ansicht ist ein editierbarer Desired-State-Graph mit entdecktem libvirt-Runtime-Zustand. Diese zwei Schichten getrennt halten verhindert, eine Karte auf der Canvas für deployed Infrastruktur zu halten.

Graph-Modell

Element	Desired state	Runtime-Nachweis
VM-Node	Name, Ressourcen, Disks, Boot-Variant, Position	Domain ID/name, power state, interfaces, deployment result
Network-Node	Logischer Name, Typ, Subnet, Position	Libvirt network name, bridge, active state, DHCP state
Edge	Beabsichtigte VM-to-network attachment	Interface/MAC am erwarteten runtime network

Nodes können planned, provisioning, running, stopped oder failed sein. Text state und Deployment-Details nutzen; Farbe ist sekundärer Hinweis und kann mit UI-Theme wechseln.

Netzwerk-Wahl

NAT-Netzwerke liefern Gast-Egress über managed libvirt network, wenn Host und Policy es erlauben.
Isolated networks liefern VM-to-VM-Konnektivität ohne externe Route.
Zusätzliches Bridge- oder Direct-Internet-Verhalten ist operator- und deployment-spezifisch; es folgt nicht allein aus einer gezeichneten Edge.

Bei statischer Adressierung müssen authored subnet, gateway, reserved addresses, DHCP range, MAC reservations und Gast-Konfiguration übereinstimmen. Eine Graph-Edge allein konfiguriert keine Adresse im beliebigen Gast.

Bearbeiten und Deployen

Korrekten Projekt-/Build-Scope vor Edit wählen.
VM- und Network-Nodes hinzufügen und Handles verbinden.
Boot-Image und Ressourcen für jede VM wählen.
Topologie speichern und bestätigen, dass Server-Revision vorrückt.
Nodes deployen und auf Runtime-Overlay-Daten warten.
Jede desired edge gegen tatsächliche VM-Interfaces verifizieren.

Projekt-Topologie wird serverseitig mit Revision checks persistiert. Die UI nutzt auch lokale Caches und debounced saves; auf Save-Abschluss warten vor Scope-Wechsel oder Seiten schließen. Save-Fehler bedeutet, die Canvas ist noch nicht durable.

Beispiel-Abnahme-Checks

Für Client/API-Topologie:


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

All das verifizieren:

beide Domains existieren und laufen;
beide haben Interface am selben runtime isolated network;
Name/Address resolution mappt api auf intended guest;
client-side http_responds assertion erreicht API health endpoint;
isolated network hat keine unintended external route;
NAT edge existiert nur, wo das Rezept Egress verlangt.

Refresh und Export

Runtime state wird aus Backend-Inventar refreshed und kann lifecycle request kurz hinterherhinken. Manuell refreshen bei Transition-Validierung. Manche Topologie-Views exponieren JSON export für Dokumentation; exportierter Graph ist desired-state data, kein Backup von VM disks und kein Nachweis, dass Runtime matched.

Siehe VMs anlegen und Eigene Assertions.