Network Lab Continuity Across Ephemeral Compute¶
Overview¶
HybridOps treats a network lab as an environment whose identity and operating record survive its current host. Environment-scoped intent, readiness, recovery authority, private access, release conditions, and run evidence remain bound through deployment, preservation, compute release, and reconstruction.
EVE-NG, GNS3, and Containerlab provide supported execution paths for that contract. Each platform supplies its own topology and recovery semantics. The runtime decides whether the declared environment is ready to run, safe to release, and acceptable after reconstruction.
| 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 and Linux | Topology source, local assets and native recovery data supported by the selected nodes; container images remain references |
The invariant across the three paths is that declared continuity state is verified before execution capacity is released.
Technical case study¶
Validation basis: HybridOps-controlled reference environments exercised to the 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: the runtime binds declared intent, authority, capacity, preservation, release, and reconstruction to one environment record. Existing labs enter through a verified same-platform recovery set; new labs begin from the environment blueprint. Both paths reach the same release and acceptance gates.
- 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 environment contract stays stable while each execution path retains the state appropriate to its platform. The release rule remains the same: the declared continuity outcome must be verified before the current host becomes disposable.
Existing lab intake¶
Migration intake establishes a portable, same-platform recovery set. Capture assesses the declared source streams and destination capacity before publishing an artifact. Import verifies that artifact and binds it to one environment and blueprint reference. Reconstruction then follows the normal environment lifecycle.
| 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¶
For Containerlab, the environment contract records which .clab.yml source is
authoritative when the retained recovery copy and current controller source
differ. The validated Google Cloud path verified recovery state off-host,
removed the original VM, created replacement compute with a different resource
identity, reconstructed the lab, passed final health, and released the declared
compute at closure.
Private operator and device access¶
The supported paths can expose session-scoped private access from the operator workstation without publishing topology-node management interfaces directly to the public network. Platform access varies by execution path; managed device targets resolve through one environment-scoped model for CLI, browser and local automation clients. 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.
IP addresses, hostnames and instance identifiers visible in the screenshots and recording belong to the ephemeral environments used for the exercise.
Implementation¶
| Platform | Cloud path | On-premises or local path | 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 |
linux/containerlab@v1 |
Cloud, local Linux |
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
- network-lab evaluation that requires one environment contract across execution locations
References¶
Further reading
Related¶
Related reading¶
- EVE-NG Network Simulation Architecture
- Operate EVE-NG
- Operate GNS3
- Operate GCP Containerlab
- Operate Local 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. Containerlab has exercised Google Cloud and local Linux paths, including managed device access, recovery-authority selection, preservation, teardown and fresh reconstruction. The Google Cloud path verified recovery state off-host before original-host removal. The recording above remains the worked visual record for the earlier cross-target EVE-NG delivery path.