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. It can start from a new lab declaration or a verified same-platform import, then prepare the execution target, verify the lab, provide private operator access, preserve the required continuity state, 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, selected stopped-QEMU overlays and optional referenced base images
GNS3	Google Cloud and Proxmox	Project and controller state including writable node disks, with an optional image library
Containerlab	Google Cloud	Topology source, local assets and native recovery data supported by the selected nodes; container images remain references

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

Technical case study

Basis: HybridOps-controlled reference environment, not a customer deployment. Claims are limited to the verification scope stated on this page.

• 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: for an existing lab, HybridOps assesses the requested source streams, checks destination capacity, verifies the resulting bundle and binds it to the selected same-platform blueprint. The normal lifecycle then prepares the execution host, restores the retained state, verifies the lab and uses off-host continuity proof as the release gate.
• Outcome: existing labs can enter the managed lifecycle without being translated into another emulator format. The EVE-NG path restored IOL, vEOS and Ubuntu state from Proxmox to Google Cloud. The Google Cloud Containerlab path also removed its original host and reconstructed the lab on fresh compute.

Shared lifecycle

Stage	Operating result
Intake	A new lab is declared or an existing same-platform bundle is inspected, verified and bound to the target blueprint.
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

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.

Existing lab intake

Migration intake does not convert labs between EVE-NG, GNS3 and Containerlab. Capture reads the selected source data through SSH, assesses the requested streams and refuses unsafe or incomplete output. Import verifies the archive, checks local capacity and binds the retained copy to one environment and blueprint reference. A normal blueprint deployment performs the restore.

Platform	Portable intake
EVE-NG	Lab definitions, optional guest-quiesced QEMU overlays and an optional companion containing referenced base images
GNS3	Projects and controller state, with the image library included only when requested
Containerlab	Authoritative topology source, local relative assets and native saved configuration; image references remain external

The source tree remains unchanged. Existing target labs and images are not replaced silently. Appliance boot and service checks remain part of migration acceptance because archive integrity alone does not prove guest portability.

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. Archive verification proves the retained state, while guest boot and service checks determine whether an appliance is portable across the selected source and target hypervisors.

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.

Live EVE-NG appliance with an active VPCS workload.

Nested-virtualisation host on Google Cloud.

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

• EVE-NG architecture decision
• Operate EVE-NG
• Operate GNS3
• Operate Containerlab
• Network architecture

Related

Related reading

• EVE-NG Network Simulation Architecture
• Operate EVE-NG
• Operate GNS3
• Operate GCP Containerlab
• Network Architecture

What was verified

EVE-NG and GNS3 have exercised Google Cloud and Proxmox delivery paths with private access, preservation and controlled teardown. Existing-lab intake is implemented for EVE-NG, GNS3 and Containerlab. The cross-target EVE-NG exercise restored IOL, vEOS and Ubuntu state from Proxmox to Google Cloud. Appliance boot and service acceptance, including the current portability limit, is documented in the EVE-NG runbook. The Google Cloud Containerlab path completed off-host recovery verification, original-host removal and fresh-host reconstruction. The recording above remains the worked visual record for the earlier cross-target EVE-NG delivery path.