How to Back Up and Export a Cisco Modeling Labs (CML) Lab

What a CML export actually is

A CML lab has two homes. One is the running simulation on the controller: booted virtual routers and switches, each with its own memory, virtual NVRAM, and disk. The other is the lab definition — a structured document that describes the nodes, their interfaces, the links between them, the on-canvas layout, and a stored configuration block for each device. Exporting a lab hands you that second thing: a single .yaml file that is a complete, portable recipe for the topology, not a copy of the live machines.

This distinction is the whole reason export is worth understanding. The .yaml is text, so it is tiny, diffable, and trivial to move between servers or hand to someone else. But because it is a recipe and not a running system, it captures only what the lab definition knows about — the wiring and the configs you have told it to store. Anything that exists only inside a booted node's disk or volatile memory is not in the file. Keep that line in your head and the rest of the workflow follows naturally.

Exporting from the lab view

Export lives in the lab's own menu, not buried in server administration. Open the lab, and if the nodes are currently running, do one thing first: run Extract Configurations from the lab (Simulate) menu. This reads the live running-config off each booted node and writes it back into the lab definition's stored configuration for that node. Skip this step on a running lab and your export will contain whatever the configs were the last time they were saved into the definition — often the day-0 config you started with, not the work you just did.

Then choose Download Lab from the same menu. CML generates and downloads a .yaml file (older labs imported from VIRL may carry a .virl extension; new exports are .yaml). If the lab is stopped, you can download it directly — there is no live state to extract, so the file simply reflects the stored definition as it stands. Exact menu wording shifts a little between CML 2.x releases, so if a label looks different from what you expect, check Cisco's current CML documentation for your version rather than hunting blindly.

One practical consequence: an export taken while nodes are stopped, or before you extract configurations, gives you topology plus the last-stored configs — which may be topology-only if you never saved device work into the definition. An export taken right after Extract Configurations gives you topology plus your current running-configs. Decide which you want before you click download.

What the file captures — and what it does not

The .yaml captures the structural, reproducible parts of your lab: every node and its node type, the interfaces, the links, the canvas positions, and the stored per-node configuration text. Re-import it and you get the same topology with the same configs injected at boot. That is exactly what you want for a lab you can rebuild anywhere.

What it does not capture is a full VM snapshot of each node's disk. CML does not fold a node's virtual hard drive into the exported lab file, so anything that lives only on a node's disk or in its volatile memory — files copied into flash, certificates or keys generated at runtime, guestshell contents, unsaved counters and state — does not travel with the export. The durable artifact you actually preserve is the configuration, and there are two separate places a config can live, which trips people up constantly.

Inside the device, running-config is in RAM and startup-config is in the node's virtual NVRAM. Saving running to startup (below) means the config survives a node reload within CML. That is device-level persistence. Separately, at the lab level, Extract Configurations copies running-config into the lab definition so it lands in your export and gets re-injected if the node is ever wiped or the lab is re-imported. Both are worth doing: save on the device so a reload does not lose your work, and extract at the lab level so your backup file reflects reality. A wipe returns a node to the lab's stored config, so the lab-level copy is your real safety net.

R1# show running-config | begin interface     ! confirm what you're about to keep
R1# copy running-config startup-config        ! persist to NVRAM (survives a node reload)
R1# write memory                              ! identical, older syntax
R1# show startup-config                       ! verify it saved

Re-importing to restore or share

Restoring is the mirror image of export. From the CML dashboard, use Import and select your .yaml file; CML creates a brand-new lab from the definition — it does not overwrite an existing one, so importing a backup is always safe. The new lab comes in stopped. Start it, and each node boots with the stored configuration injected as its day-0 config, so a freshly imported lab comes up already configured rather than blank. If a node was left in an odd state, wiping it before start guarantees a clean boot straight from the stored config.

Sharing works the same way, which is the quiet strength of the plain-text format. Send someone the .yaml and they import it to get a byte-for-byte copy of your topology and configs on their own controller — no screenshots, no step-by-step rebuild, no drift. This is how you hand off a study scenario, a repro case, or a graded lab and know the other person is looking at exactly what you built.

Versioning your lab files with a folder or git

Because the export is plain-text YAML, treat it like source code. Keep your labs in a dedicated folder, and put that folder under git. Every meaningful milestone — routing converges, an ACL finally does what it should, you break the lab on purpose for a troubleshooting exercise — is a moment to Extract Configurations, download, and commit. Line-oriented YAML diffs cleanly, so git will show you exactly which node's config or which link changed between two versions, and you can roll back to any point without redoing work by hand.

A few habits make this pay off: name files so they sort sensibly (a topic plus a date or version, not lab-final-final-2), write a one-line commit message describing what changed, and export deliberately after real progress rather than compulsively. One caution worth stating plainly — the stored configs inside the .yaml are the actual device configs, which means any passwords, keys, or SNMP strings in running-config are sitting in that file in whatever form the device stored them. Keep lab repositories private, scrub or dummy out real credentials before sharing a file publicly, and never push a lab full of production-like secrets to a public host.