Deployment · Servers and Virtualization
Deploy an Isolated Virtual Lab Network with Libvirt
An isolated libvirt network is a managed virtual network without a forward element. Guests communicate over a bridge without libvirt-provided external forwarding. Because the host…
Technical review:
Architecture and operating model
An isolated libvirt network is a managed virtual network without a forward element. Guests communicate over a bridge without libvirt-provided external forwarding. Because the host attaches to that bridge, this is not isolation from the host itself.
Choose an unused private subnet and check host route conflicts first. Define/start the network XML and attach only the pilot guest NIC. A second NIC, host forwarding or additional NAT rules can bypass isolation.
Restrict management access with separate rules and identities. Anonymize lab data. Detach guests before removing the network; undefining it does not delete guest disks or sensitive test data.
- 1Network XML definition
- 2Isolated bridge
- 3Pilot guest NICs
- 4Negative access test
Design parameters
- Subnet
- 10.77.0.0/24 is an example; check corporate, VPN and bridge route conflicts.
- DHCP range
- Exclude the gateway from the pool and record static guest addresses.
- Host access
- Absence of forwarding does not block host-guest access; add host firewall policy.
Worked example
Define a 10.77.0.100–150 pool for two guests. Guest-to-guest access should work while production VLAN access is denied. Scope host management access to the pilot administrator source and verify guests have no second NIC.
Example commands: replace lab values and confirm permissions and software versions before use.
<network>
<name>doz-lab</name>
<bridge name="virbr77"/>
<ip address="10.77.0.1" netmask="255.255.255.0">
<dhcp><range start="10.77.0.100" end="10.77.0.150"/></dhcp>
</ip>
</network>
<!-- Save as lab-network.xml; then: virsh net-define lab-network.xml -->Troubleshooting
| Observation | Likely cause / distinction | Verification |
|---|---|---|
| Guest reaches Internet | Additional NIC or host NAT. | Inspect domain interfaces and host rules. |
| No DHCP lease | Wrong network attachment or DHCP service failure. | Inspect network XML and DHCP leases. |
Acceptance checks
- Check subnet conflicts.
- Verify absence of a forward element.
- Inspect guest NIC lists.
- Restrict host management access.
- Run a negative production-access test.
- Handle lab data in teardown procedures.
Related concepts
Isolation versus virtualization
Containers and VMs provide different isolation boundaries. Containers share the host kernel; VMs run guest operating systems. Rootless execution, namespaces and capability restrictions can reduce risk, but configuration and host security still matter. Images, running containers and persistent volumes have separate lifecycles. Updating an image does not back up data. Verify process privileges, mounts, network access and persistence after recreation separately.
Layer 2 and Layer 3 boundaries
A VLAN creates a separate broadcast domain; routing and access policies govern communication between VLANs. Review trunk allowed lists, access-port assignment and gateway placement together. A network diagram should show where packets are routed and filtered, not merely which cables connect devices. Sharing a switch does not require sharing privileges. When access fails, confirm VLAN and addressing first, then gateway, route and policy matching.
File permissions and service identities
File access combines users/groups, permission bits, ACLs and security policies. Running an application as root can hide permission problems; prefer a justified, restricted service identity in production. Directory traversal permission differs from file-read permission. Sharing permissions do not necessarily override filesystem restrictions. Identify the actual runtime user, directory chain and ACLs when troubleshooting. Test narrowly required access rather than opening permissions globally.
Trust boundary and failure domain
A trust boundary separates components governed by different access decisions; a failure domain groups resources that one event can affect together. Two VLANs do not create a strong trust boundary when routing between them is unrestricted. Backups in different folders still share a failure domain if one administrator can delete both. Assess physical location, identity provider, management account, network path and power source separately. Test which access paths and recovery options remain available when a component is lost.
DNS caching and dependencies
DNS results depend on client and recursive-resolver caches as well as authoritative data. Changing a TTL does not retroactively shorten already cached answers. A/AAAA, CNAME, MX and TXT records serve different purposes. Test internal and external views separately; split DNS may intentionally return different results. Record resolver, response type, TTL and query time when troubleshooting. Successful access by IP address alone does not prove correct DNS configuration.
Version and support lifecycle
Installability does not prove production support. Review the compatibility chain across OS, application, drivers, extensions and management tools. Update plans should record version, support end, restart needs and rollback methods. An unrepresentative test environment can produce misleading results. Validate service health and existing workflows after a change, not just version numbers. Remember that pinning a version can also prevent future security fixes.
Primary documentation
Prepared by the Doz Teknoloji technical team using the primary references below. Calculations and lab scenarios state their assumptions; validate the applicable product version before rollout.