Мережева топологія

Topology view , editable desired-state graph overlaid with discovered libvirt runtime state. Keeping two layers distinct prevents card on canvas mistaken for deployed infrastructure.

Graph model

Element	Desired state	Runtime evidence
VM node	Name, resources, disks, boot variant, position	Domain ID/name, power state, interfaces, deployment result
Network node	Logical name, type, subnet, position	Libvirt network name, bridge, active state, DHCP state
Edge	Intended VM-to-network attachment	Interface/MAC attached to expected runtime network

Nodes can be planned, provisioning, running, stopped, or failed. Use text state and deployment details; color is secondary cue and can change with UI theme.

Network choices

NAT networks provide guest egress through managed libvirt network when host and policy allow.
Isolated networks provide VM-to-VM connectivity without external route.
Additional bridge or direct-internet behavior is operator- and deployment-specific; not implied by drawing edge.

For static addressing authored subnet, gateway, reserved addresses, DHCP range, MAC reservations, and guest configuration must agree. Graph edge alone does not configure address inside arbitrary guest.

Editing and deployment

Select correct project/build scope before editing.
Add VM and network nodes and connect handles.
Select boot image and resources for every VM.
Save topology and confirm server revision advances.
Deploy nodes and wait for runtime overlay data.
Verify each desired edge against VM actual interfaces.

Project topology persisted on server with revision checks. UI also uses local caches and debounced saves, wait for save completion before switching scope or closing page. Save error means canvas not yet durable.

Example acceptance checks

For client/API topology:


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

Verify all of the following:

both domains exist and running;
both have interface on same runtime isolated network;
name/address resolution maps api to intended guest;
client-side http_responds assertion reaches API health endpoint;
isolated network has no unintended external route;
any NAT edge exists only where recipe requires egress.

Refresh and export

Runtime state refreshed from backend inventory and may lag lifecycle request briefly. Manually refresh when validating transition. Some topology views expose JSON export for documentation; exported graph is desired-state data, not backup of VM disks or proof runtime matched it.

See Creating VMs and Custom assertions.