Bring your EVE-NG lab with you.
Keep the vendor images you already use. Labtris runs QEMU/KVM guests on your own Linux host, with a browser canvas, consoles and packet capture, and no licensed node ceiling.
Start with one familiar lab. Check its image and template mappings, bring the saved state you need, and verify the running result before moving more.
Start with one existing lab.
On the Labtris host, scan the EVE-NG server over SSH. The dry run lists labs, image choices and the transfer plan without copying them.
sudo -u labtris labtris-migrate-eveng --dry-run- Select one lab and only the images it needs. Review any unknown templates or placeholders.
- Choose working disks if you need the configuration saved inside the guests. Stop the source lab for a clean copy.
- Run the migration without --dry-run. Boot the lab in Labtris and verify interface names, routing, saved configuration and end-to-end reachability.
Saved configuration is the key check.
The importer does not import startup-configs embedded in .unl files today. Working disks preserve state saved on those disks, not unsaved guest RAM. Devices that boot from a separate configuration file may need a manual config transfer.
What changes if you switch.
The differences worth knowing before reading anything else. The concept map further down answers the other question — where each thing you already use ended up.
- EVE-NG
- Your appliance library and templates.
- Labtris
- Copy the QEMU images you are entitled to use. Check each template; unknown appliances become placeholders until mapped.
- EVE-NG
- A .unl file with nodes, networks and positions.
- Labtris
- Import the shape and positions. Verify interface mappings and every warning before booting.
- EVE-NG
- May live in a working disk or exported startup-config.
- Labtris
- Bring working disks for disk-saved state. Embedded .unl startup-configs are not imported yet; transfer them separately when required.
- EVE-NG
- Depends on the EVE-NG edition and licence.
- Labtris
- No licensed node cap. Host memory, CPU and the actual images set the practical limit.
- EVE-NG
- Depends on host configuration and the guest workload.
- Labtris
- KSM configuration and diagnostics. The published 931-node result is a container-based FRR workload, separate from VM density.
- EVE-NG
- Access and terms depend on the edition.
- Labtris
- MIT-licensed network emulator. The source is public on GitHub.
Start with a copied lab and validate it on the destination. The migration tools are young, and unsupported templates need manual work.
Keep using these ideas.
- Real vendor guests under QEMU/KVM, with familiar images and guest consoles.
- An established appliance catalogue and existing lab files that encode your topology.
- Saved working disks often contain the configuration you want to preserve.
The reasons to look elsewhere.
- A move needs a reliable mapping for appliance templates, NIC models, disk buses and interface names.
- Base images alone do not carry configuration saved in a node's working disk.
- Host RAM limits lab capacity. A page-sharing ratio from one workload does not establish the size of a mixed vendor lab.
What you know, and what it’s called here.
Same primitives, mostly. A few things are actually different — those get their own row.
- Topology
- EVE
- .unl XML
- Labtris
- Labtris nodes, network segments and geometry. Unknown appliances carry warnings.
- Appliance template
- EVE
- RAM, CPU, NIC model, disk bus and interface naming
- Labtris
- Corresponding template fields, editable from the palette. Verify vendor boot settings.
- Base images
- EVE
- QEMU image directories
- Labtris
- Copy selected images through the migration tool or upload them manually.
- Working disks
- EVE
- Per-node qcow2 overlays
- Labtris
- Flattened copies, independent of the source backing path. Saved disk state can come across.
- Consoles
- EVE
- Guest console access
- Labtris
- Serial, VNC and RDP in the browser.
- Link testing
- EVE
- Guest interfaces and host links
- Labtris
- Labtris-managed links support per-direction impairment and packet capture.
Importing existing topologies.
Labs and images. The interactive migration command scans over SSH, lets you select labs and versions, and copies only the referenced image directories. A repeat run skips images already transferred and registered.
Working disks. Stop the source lab for a clean copy. A hot read is crash-consistent and can lose unflushed changes. Flattening also means the transfer can be much larger than the source overlay file.
Compatibility. The .unl parser maps a fixed set of templates. Other appliances need the image library adopted and template fields checked manually. Companion BIOS and CD-ROM files may need attachment.
Install
One command on Ubuntu 24.04 or 26.04, one compose file anywhere Docker runs. MIT, no telemetry.