Identify the host network manager and provider MAC/VLAN rules. Reserve non-overlapping private subnets for NAT and document any required inbound service path. Keep independent console access before changing physical interfaces or bridges on a remote host.

1. Inspect existing networks with virsh -c qemu:///system net-list --all and review the intended network definition before modifying it.
2. For a managed NAT network, choose a subnet that does not overlap the host, VPN or other guest networks. Review DHCP, DNS and forwarding settings before starting it.
3. For a bridge, prepare the bridge through the host network manager using the provider-approved configuration. An existing-bridge libvirt network does not configure upstream routing or provide DHCP automatically.
4. Attach one disposable guest to the selected network. Keep the guest firewall enabled and expose only the intended services.
5. Test from the guest, the host and an external network. For NAT, add a deliberate supported proxy or forwarding design only when inbound access is required; do not assume the private address is externally reachable.

On the authorised KVM host, inspect the guest's interfaces and the available libvirt networks. Replace VM_NAME and default with the actual domain and network name. These commands read the current configuration without detaching an interface or changing a bridge.

sudo virsh -c qemu:///system domiflist VM_NAME
sudo virsh -c qemu:///system net-list --all
sudo virsh -c qemu:///system net-dumpxml default

Read the result: The interface source helps distinguish a managed virtual network from a host bridge. The network XML shows its forwarding mode where configured. A network named default is not proof that every guest uses it, and a bridge device can exist without providing the intended external connectivity.

Plan address assignment, routes, firewall and upstream MAC restrictions for the chosen model. On a host managed by SolusVM or another platform, change the network through that platform's supported workflow so manual libvirt edits are not overwritten or left inconsistent.

Only when the attached network, address allocation, routing and firewalls permit it. Some providers restrict additional MAC addresses or require a routed design instead.

Confirm the guest address and default route, external IP connectivity and DNS resolution. Verify expected isolation and any allowed inbound service. Restart the guest and, during an approved window, confirm persistent host networking and network autostart behavior.

If outbound access works but inbound does not, inspect NAT or upstream routing before changing guest services. If the host loses connectivity after bridge changes, recover through the console. Do not disable the firewall globally or move the management interface between bridges without a tested rollback.

• Checking Linux hardware virtualization support for KVM
• Preparing a Linux guest for virsh serial-console access
• Diagnosing CPU, memory and disk contention on a KVM host
• Creating and attaching a libvirt storage volume

• libvirt: Formatnetwork
• libvirt: Firewall

• libvirt virsh reference