RudderVirt

#Building VM Images

This guide is for people who want to build modules. A module is a collection of one or more virtual machines that get built, snapshotted, and cloned as a single group. You describe the VMs in the module, their base images, provisioning steps, and any networking, ISOs, or files they need during the build. The system boots the VMs, runs each VM's steps, captures their disks, and saves them as a reusable template module.

The editor has two modes, and you can switch between them at any time:

  • Visual: a form with sections for files, networking, and each VM (source, resources, communicator, network interfaces, provisioners). Use this when you want guided editing, or when you only need the common fields.
  • YAML: the underlying manifest as raw text. Use this for advanced fields the form does not expose, for diffing changes, or when copying a recipe from this guide.

The two modes round-trip through the same manifest, so switching does not lose data. Switching from Visual to YAML may reformat the document and drop comments, since serialization is regenerated from the form state.

The rest of this guide describes what to put in a build, not how it works internally.

  • Mental Model — If you have ever built an image for a class, you know how tedious the process is. By the time you need to rebuild it for next semester, half the context is gone. We hit this over and over, and decided there had to be a better way. That is why we require every image to be scripted and repeatable. Every module is an automated build, and every build must be reproducible from its manifest alone.
  • Concepts — Each part of a build, explained one at a time. Pick whichever piece you are trying to understand.
  • Recipes — Full worked examples for the situations you are most likely to hit.
  • Best Practices — Reboot any time a step changes something that needs a clean process tree:
  • Troubleshooting — Network resources couldn't be created. Check that:
  • Reference — The YAML field reference. The visual editor exposes the most common fields under the same names (see each concept page); the tables below list every field, including the ones reachable only by editing the YAML.
  • Under the Hood — You don't need any of this to write a build. It's here so the names you'll run into in upstream documentation, log output, and community forums make sense.