# cml-community shares the node definitions CML users cannot get elsewhere > The CiscoDevNet cml-community repository holds community contributed YAML node definitions, base image references and lab topologies for Cisco Modeling Labs, and it exists because the licensed QCOW images cannot be shared there. **CiscoDevNet/cml-community** — Community Contributed Content and Resources for Cisco Modeling Labs - Repository: https://github.com/CiscoDevNet/cml-community - Stars: 669 · Forks: 180 - Language: Shell - License: BSD-3-Clause - Published: 2026-10-21 · Updated: 2026-10-21 · Language: en - Canonical page: https://hysenlabs.com/projects/ciscodevnet-cml-community ## A content repository with no software in it cml-community is described as community contributed content and resources for Cisco Modeling Labs, and the first thing to understand is what kind of repository this is. There is no program to install, no service to run and no API. The top-level entries are directories of content: node-definitions, virl-base-images, lab-topologies, documentation, scripts, use-cases, validation_schemas and readme_images, plus the usual community files such as CONTRIBUTING.md, CODE_OF_CONDUCT.md, LICENSE and NOTICE. The platform it serves is Cisco Modeling Labs, a network simulation platform from Cisco that lets you build network topologies out of virtual devices and, in one documented configuration, tie the simulation into physical components by bridging it to the real world. It supports virtual machine based devices using the QCOW or KVM disk formats. CML itself ships with a library of reference platforms for a range of Cisco network devices, along with images for Linux servers, traffic generators and unmanaged devices, and it also has Sample Labs available from the Tools menu in Lab Manager. The reason this repository exists is that the built-in library is not always enough, and because the obvious way to extend it cannot be done in a public repository. The README puts the constraint plainly: the actual QCOW image files for nodes that need proper licensing and rights from their platform owners cannot be shared. What can be shared, and what is shared here, is the metadata that describes them. So the audience is specific. It is a CML operator who needs to describe a node for a platform Cisco does not ship, and a teacher or author who wants a topology that demonstrates a particular simulation problem. ## Node definitions and base images, and the licensing line between them The two content types are related but not interchangeable, and the repository is organised to reflect the same folder structure and naming conventions used on the CML server itself for storing definitions. That mirroring matters, because content placed here is laid out the way CML expects to find it. The node-definitions directory holds YAML file definitions for a CML node. The README says the YAML includes details on how the virtual machine would be configured, naming CPU, RAM and network adapters among the settings. A node definition is therefore a description of hardware and interfaces, not an operating system image. The virl-base-images directory holds a folder per added platform disk image. Inside each platform folder is a YAML file that references a specific disk_image file for that platform, and the base image definition references a node definition. The relationship is a chain: a base image points at a disk, and a disk is described by a node definition. The note in the README is the constraint that decides how this is used in practice. The disk images have to be downloaded from the vendors yourself. The repository can tell you what a node should look like and which image file to point at, and it can give you the YAML for platforms from Cisco and from third party vendors, but the licensed bits stay with their owners. This is also where the bring your own image model comes in. CML accepts any KVM supported image, so the ceiling on what you can run is set by what you can legitimately obtain, and the repository's role is to remove the guesswork about how to describe that image to CML rather than to remove the licensing obstacle. ## Lab topologies that depend on nodes you may not have The lab-topologies directory holds network topologies that users have created to highlight a specific type of simulation challenge, and the README treats the built-in Sample Labs as a starting point rather than a limit. There is a caveat attached to all of them, and it is the kind of note that saves an afternoon. Sample Lab Topologies from this repository may use nodes that are not included in the standard reference platform for CML. The instruction is to check the requirements of any given topology before trying to run it, which means reading the topology's own documentation for the node definitions and images it expects, and confirming you have obtained those images legally from their vendors. The two other directories support that work. The use-cases directory suggests the repository is used to share scenarios, not just diagrams, and the validation_schemas directory suggests there is machine-checkable metadata alongside the human-readable files. The scripts directory holds helper scripts, and the documentation directory carries the platform notes that the README links to for the unofficial installation paths, which is discussed below. For someone building a teaching lab, this is the practical pattern. Take a topology from here, read its requirements, fetch the images you are missing, and import the node definitions that the topology names. The failure mode to avoid is assuming that a topology is self-contained because it is a single file in a folder. ## Sizing the host before you import the images The README points to a CML Sizing Calculator hosted at ciscolearning.github.io/cml-sizer, and it does so at the exact moment the question matters, which is when you are deciding how many total resources a CML deployment needs. This is a hardware planning step, not a configuration step. A CML install runs virtual devices, each of which needs disk space for its image and memory for the node definition's RAM setting, and the number of those devices is what the host has to accommodate. A topology that looks small on screen can require a substantial allocation once the image footprints are counted, and a lab with several vendors' platforms multiplies that. The order of operations therefore matters. Decide the topologies you want to teach or test with, read the node definitions for the images involved to learn their CPU and memory requirements, and size the host against the calculator before importing anything. Importing first and sizing afterwards is how people end up with a lab that will not start on the server they have. The same guidance applies to the disk images themselves, since the images are not in the repository. Whatever space they take has to be provisioned and available on the host before the import, not after it. ## Where CML itself is supported, and where it merely works The README draws an explicit line between official and unofficial platforms, and that distinction is the one to respect when planning a deployment. CML is officially supported on bare-metal x86_64 servers and in VMware ESXi and VMware Workstation virtual machines. That is the short list of configurations Cisco stands behind. Everything else is described as unofficially installable, and the repository carries the documentation for those paths: cml_on_hyperv.md, cml_on_proxmox.md and cml_on_nutanix.md, all in the documentation directory. Hyper-V, Proxmox and Nutanix AHV are the three named platforms, and each has a guide in the repository. The difference in wording is not cosmetic. Official support means Cisco answers for the product on that platform, and an unofficial installation means the combination may work without a commitment behind it, including at the next CML release. The bare-metal and VMware requirement also constrains the hardware a lab can use. A platform other than x86_64 is outside the officially supported list, which matters for anyone building on Apple silicon or on an ARM server, where the practical options are the unofficial paths or a virtual machine on supported hardware. One further capability is worth noting because it changes what a lab can be for. Beyond pure simulation, CML can be bridged to physical components, so a topology can include a real device alongside simulated ones. That is what turns it from a teaching tool into a test bench, and it is also the mode where a misconfiguration has consequences outside the virtual machine, so the isolation decisions belong to the person running the lab rather than to the topology author. ## DevNet Sandbox as the way to try CML without a lab The repository recommends DevNet Sandbox for anyone new to Cisco Modeling Labs, and describes it as a way to explore and test drive CML, with a specific instruction to search for "Cisco Modeling" in the Sandbox Catalog. The logic is straightforward. The content in this repository is only usable if you have a CML installation, and a CML installation wants a server with memory, storage and nested virtualisation. A sandbox removes that barrier, which is why the recommendation is aimed at newcomers rather than at established users. The sandbox guidance is also framed as a contribution habit. The README argues that a repository is easier for others to use if it links to a DevNet Sandbox that provides the network or other resources needed to run the code, together with instructions and configuration for using it. In other words, the sandbox serves two purposes: it is a way to evaluate a topology, and it is the mechanism a contributor uses to make a topology reproducible for somebody else. The distinction between evaluating and authoring is worth keeping in mind. Trying a topology in a sandbox tells you whether the concepts work. It does not tell you whether the topology will run on a customer's CML server, because the sandbox is a managed environment that is configured for you, and a real install is not. ## How content gets in, and what the licence permits The contribution path is described in the README and detailed in CONTRIBUTING.md, and the project's request is explicit: it would love to see the repository grow with community content. The audience for this repository is thus both consumer and producer, and the repository is structured to make sharing definitions straightforward, since the folder layout already matches what CML expects on the server. The licence is BSD-3-Clause, with the LICENSE and NOTICE files at the top level. That is a permissive licence with the standard three-clause obligations, so a definition or a topology can be reused and modified with attribution, and there is no copyleft requirement to pass on to a derivative work. The NOTICE file indicates that third-party attributions are recorded, which matters when content describes other vendors' platforms. As always, this is a reading of the terms and not legal advice. The project is not archived, and the last push was on 2026-10-22, so contributions are still landing. There are no GitHub releases, which is normal for a repository of definitions rather than a packaged product, since a node definition is consumed by dropping it into a CML server rather than by installing a version. The README also credits a list of individual maintainers and contributors by name, and points CML usage questions to the CML community support pages while asking for bug reports and concerns about this repository to be raised as issues against it. That division of support responsibility is a good model for a content repository: the content is community owned, and the platform questions still go to Cisco. ## Conclusion cml-community fits a network engineer or instructor who already runs Cisco Modeling Labs and needs a node definition for a platform the standard reference platforms do not cover, or a topology to teach from, and who is prepared to obtain the disk images from the vendor. It is the wrong place to look for a CML installation, since the repository ships no installer and no software, and it is the wrong source for the disk images themselves, since those are deliberately absent. Before depending on anything here, check the requirements of the specific topology or node definition against your own CML install, size the host for the images you intend to import with the CML Sizing Calculator, and confirm that an unofficial platform such as Proxmox or Hyper-V is acceptable for your environment, since Cisco supports only bare-metal x86_64 and VMware ESXi and Workstation. ## FAQ ### What does the cml-community repository actually contain? It contains YAML node definitions for CML nodes, base image definitions that reference a specific disk_image file, sample lab topologies, documentation for unofficial installation platforms, scripts, use cases and validation schemas. The folder structure mirrors the naming conventions used on the CML server itself. ### Why are the QCOW disk images not included in cml-community? The README states that the actual QCOW image files for nodes requiring proper licensing and rights from individual platform owners cannot be shared. The YAML definitions can be posted, and the disk images have to be downloaded from the vendors yourself. ### Which platforms is Cisco Modeling Labs officially supported on? CML is officially supported on bare-metal x86_64 servers and in VMware ESXi and VMware Workstation virtual machines. Installation on Hyper-V, Proxmox and Nutanix AHV is described as unofficial, with guides for each in the repository's documentation directory. ### How do I try Cisco Modeling Labs without my own server? The README recommends DevNet Sandbox and instructs users to search for "Cisco Modeling" in the Sandbox Catalog. The repository also asks contributors to link a topology to a DevNet Sandbox that provides the resources needed to run it. ### How do I plan host capacity for a CML lab? The README points to the CML Sizing Calculator at ciscolearning.github.io/cml-sizer and says to consult it when deciding how many total resources are needed. Node definitions list the CPU, RAM and network adapter settings, which feed that calculation. ## Sources - [CiscoDevNet/cml-community on GitHub](https://github.com/CiscoDevNet/cml-community) - [Issues](https://github.com/CiscoDevNet/cml-community/issues) - [License: BSD-3-Clause](https://github.com/CiscoDevNet/cml-community/blob/master/LICENSE) - [README](https://github.com/CiscoDevNet/cml-community/blob/master/README.md) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/ciscodevnet-cml-community