Skip to content

Network Lab Continuity Across Ephemeral Compute

Overview

High-resource network labs can preserve continuity while their execution compute remains ephemeral. HybridOps applies one surrounding lifecycle to EVE-NG, GNS3 and Containerlab: prepare the execution target, verify the lab, provide private operator access, preserve the continuity state required for the next session, release compute when that gate passes, and reconstruct the environment later.

Each lab platform remains authoritative for its topology, nodes and native recovery semantics. HybridOps governs the execution-host lifecycle, private access, preservation policy, release gate and evidence around those systems.

Lab platform Execution targets Continuity contract
EVE-NG Google Cloud and Proxmox Lab definitions plus selected stopped-QEMU overlay state
GNS3 Google Cloud and Proxmox Project and controller state including writable node disks
Containerlab Google Cloud Topology plus native save, redeploy and snapshot-recovery semantics supported by the selected nodes

The operating boundary is the same across the three paths: useful lab state is protected before ephemeral execution capacity is released.

Case study

  • Context: network and security labs can outgrow workstation CPU, memory and nested-virtualisation capacity, while keeping equivalent cloud compute running between sessions ties continuity to an idle host.
  • Challenge: topology source alone may not be enough. Depending on the lab, continuity can also require writable node disks, controller state, native save products, image availability, private management access and final health proof.
  • Approach: HybridOps resolves the target and continuity policy, prepares the execution host, hands topology and node behaviour to the selected lab platform, verifies the retained recovery set away from the host, and uses that proof as the release gate.
  • Outcome: the same operating contract now covers EVE-NG and GNS3 on Google Cloud and Proxmox, plus the validated Google Cloud Containerlab lifecycle in which the original host was removed and the lab reconstructed on fresh compute.

Shared lifecycle

Stage Operating result
Prepare Target credentials, capacity, virtualisation support, runtime directories and required inputs are checked before deployment.
Deliver The selected platform is installed or prepared and receives its declared topology, images and environment-specific configuration.
Verify Platform health is checked independently of infrastructure creation.
Access Private UI, console or device-management paths are created for the active session where the platform requires them.
Preserve The recovery set required by the selected continuity policy is produced and verified away from the execution host.
Release Compute is retained or released according to the declared continuity decision and terminal infrastructure state is recorded.
Reconstruct Fresh compute is prepared, retained state is re-verified, the owning lab platform performs its native deployment or restore, and final lab health is checked.

Architecture

Network-lab continuity architecture showing one HybridOps execution lifecycle around EVE-NG, GNS3 and Containerlab, an off-host continuity gate, ephemeral compute release, fresh-host reconstruction and final lab verification.

The lifecycle stays common while the retained recovery set remains platform-specific. EVE-NG owns its labs and QEMU state, GNS3 owns project and controller state, and Containerlab owns topology deployment and native recovery behaviour. The shared release rule is that the selected continuity outcome is protected before the execution host becomes disposable.

Continuity contracts

EVE-NG

The EVE-NG path retains lab definitions and, when required, selected stopped-QEMU overlays that contain node-owned changes. Base images, licence material and environment secrets remain independently managed and are reapplied when fresh capacity is prepared.

GNS3

The GNS3 path retains project directories and controller metadata. Project state includes topology files and writable node disks. Restore verifies the recorded integrity value before the retained state is applied to the reconstructed service.

Containerlab

Containerlab remains authoritative for .clab.yml, nodes, links, convergence, native save behaviour and supported snapshot or restore semantics. The validated Google Cloud path verified the recovery set off-host, removed the original VM, created replacement compute with a different resource identity, reconstructed the lab through native Containerlab deployment, passed final health and removed the declared compute at closure.

Private operator and device access

EVE-NG and GNS3 can expose session-scoped private access from the operator workstation without publishing topology-node management interfaces directly to the public network. The current paths support platform access, console use and managed topology-node access for local automation tools. Live endpoint discovery and generated client material are session state; durable device metadata remains with its declared authority.

Worked EVE-NG path

The recording and screenshots below show the original cross-target EVE-NG path on Google Cloud and Proxmox. That path is one worked implementation of the wider network-lab continuity contract.

EVE-NG status dashboard from the training environment, showing the live appliance state and active VPCS workload count
Live EVE-NG appliance with an active VPCS workload.
Google Cloud Compute Engine details for the EVE-NG nested-virtualisation host
Nested-virtualisation host on Google Cloud.
Proxmox summary for the companion EVE-NG host
Equivalent EVE-NG host on Proxmox.

IP addresses, hostnames and instance identifiers visible in the screenshots and recording belong to the ephemeral environments used for the exercise.

Implementation

Platform Google Cloud Proxmox Operator path
EVE-NG gcp/eve-ng@v1 onprem/eve-ng@v1 Operate EVE-NG
GNS3 gcp/gns3@v1 onprem/gns3@v1 Operate GNS3
Containerlab gcp/containerlab@v1 n/a Operate Containerlab

Where it fits

  • network and security labs that exceed workstation capacity
  • training environments that need continuity with high-resource execution allocated for active sessions
  • practitioner labs that need private management access from local automation tools
  • repeated cloud lab sessions where preservation, teardown and reconstruction must be explicit
  • cross-platform evaluation where emulator-native semantics remain authoritative

References

Further reading

Validation scope

EVE-NG and GNS3 have exercised Google Cloud and Proxmox delivery paths with their current continuity contracts. The Google Cloud Containerlab path completed end-to-end release and fresh-host reconstruction validation before merge to Core main. The EVE-NG screenshots and recording above remain the worked visual record for the original cross-target lab path.