Topologia de rede

A view de topologia é grafo de estado desejado editável sobreposto ao estado de runtime libvirt descoberto. Manter essas duas camadas distintas evita confundir card no canvas com infraestrutura implantada.

Modelo de grafo

Elemento	Estado desejado	Evidência de runtime
Nó VM	Nome, recursos, discos, variant de boot, posição	ID/nome de domínio, power state, interfaces, resultado de deployment
Nó rede	Nome lógico, tipo, subnet, posição	Nome de rede libvirt, bridge, estado ativo, estado DHCP
Aresta	Anexo VM-rede pretendido	Interface/MAC anexada à rede de runtime esperada

Nós podem estar planned, provisioning, running, stopped ou failed. Use estado textual e detalhes de deployment; cor é pista secundária e pode mudar com tema da UI.

Escolhas de rede

Redes NAT fornecem egress guest por rede libvirt gerenciada quando host e política permitem.
Redes isolated fornecem conectividade VM-a-VM sem rota externa.
Comportamento adicional bridge ou internet direta é específico de operador e deployment; não é implicado por desenhar aresta.

Para endereçamento static, subnet autoria, gateway, endereços reservados, faixa DHCP, reservas MAC e configuração guest devem concordar. Aresta no grafo sozinha não configura endereço dentro de guest arbitrário.

Edição e deployment

Selecione escopo correto de projeto/build antes de editar.
Adicione nós VM e rede e conecte handles.
Selecione imagem de boot e recursos para toda VM.
Salve topologia e confirme que revisão do servidor avança.
Deploy nós e aguarde dados de overlay de runtime.
Verifique cada aresta desejada contra interfaces reais da VM.

Topologia de projeto persiste no servidor com checagens de revisão. A UI também usa caches locais e saves com debounce; aguarde conclusão do save antes de trocar escopo ou fechar página. Erro de save significa que canvas ainda não é durável.

Exemplo de checagens de aceitação

Para topologia client/API:


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

Verifique tudo:

ambos domínios existem e estão running;
ambos têm interface na mesma rede isolated de runtime;
resolução nome/endereço mapeia api ao guest pretendido;
asserção http_responds no client alcança endpoint de health da API;
rede isolated não tem rota externa não intencional;
aresta NAT existe só onde receita exige egress.

Refresh e export

Estado de runtime é atualizado do inventário backend e pode atrasar brevemente após pedido de ciclo de vida. Atualize manualmente ao validar transição. Algumas views de topologia expõem export JSON para documentação; grafo exportado é dado de estado desejado, não backup de discos VM nem prova de que runtime correspondeu.

Veja Criando VMs e Asserções personalizadas.