#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.

#Build phase progression

#Per-VM phase progression

#Boot command tokens

#Template variables (boot commands)

#Top-level spec fields

#Per-VM spec fields

cpu takes a whole number of cores, or a quoted fractional value ("0.5", "100m") for a VM that sits idle most of the time. Quote fractional values, or YAML parses them as floats and the build is rejected. The guest sees ceil(cpu) cores, minimum 1. memory is a Kubernetes quantity, e.g. 4Gi.

#Service VMs

Set invisible: true on a VM that supports the module but that students are not meant to work inside. A webserver that just serves a page, a domain controller, or a DNS box are all good candidates.

spec:
    vms:
        - name: workstation
          # students work here
        - name: dc01
          invisible: true # supporting infrastructure

Grading, networking, and provisioning are unaffected. The flag is baked into the template at build time and every clone inherits it, so a clone cannot turn it on or off. Decide before you build.

Rudder shows service VMs in the console rather than hiding them. Students see the VM in the Switch VM menu with a Service VM badge, and opening it gives a read-only console with a banner explaining what the VM is for. Teachers, organization admins, and superusers keep full read/write access so they can still fix a broken service VM.

Note that aileron's own documentation describes invisible as excluding the VM from the console UI entirely. Rudder deliberately shows it read-only instead, so a student who wonders what the other VM does gets an answer rather than a gap.

#Disk fields

#What disks means depends on the source

The disks list means two different things depending on the VM's source, and the two are near-opposites. Read the row for your source before writing the list.

In both cases the implicit 20Gi virtio boot disk applies only when disks is omitted entirely for a non-build_ref source. Listing even one disk opts you out of it for those sources; there is no merge or backfill. build_ref is unaffected by this — the parent's disks are inherited regardless of whether the child lists any of its own.

#Layered builds inherit every one of the parent's disks

A build_ref child automatically inherits all of the parent VM's disks — the boot disk and any secondary/data disks — with their actual captured content, not just the declarations. You don't need to, and cannot, re-declare them to keep them.

# Parent build
disks:
    - name: rootdisk # boot disk, 40Gi virtio
      size: 40Gi
    - name: secondary
      bus: usb
      size: 1Gi

# Child layering on the above. No disks field needed — rootdisk and
# secondary both carry over automatically, secondary's content included.
source:
    build_ref:
        name: parent-build

This child ends up with the same two disks as the parent: rootdisk (40Gi virtio, boot) and secondary (1Gi usb) — and whatever was written to secondary during the parent build is still there.

Anything the child lists in its own disks is purely additional, appended after the full set of inherited disks:

# Child adds a third, genuinely new disk after the two inherited ones
disks:
    - name: scratch
      size: 2Gi

That child ends up with three disks in order: rootdisk (inherited, boot), secondary (inherited), scratch (new, blank).

Naming a child disk the same as any inherited disk — boot or secondary — is a hard error, not a silent override or a way to resize/rebus it:

VM builder: additional disk "secondary" collides with an inherited parent disk name; rename it

There is currently no way to opt out of inheriting one specific secondary disk, or to change its size/bus/storageClass, while keeping its name — the only escape hatch is giving your own disk a different name, which adds a new disk rather than replacing the inherited one.

#Attaching a data disk to a non-layered VM

For url, blank, source_pvc, and container_disk sources the first entry is the boot disk, and position decides that, not bus. Declaring bus: usb on the first entry does not make it a data disk. It makes your boot disk a USB disk. This does not attach a blank USB drive:

# WRONG: this is your boot disk, on a non-bootable bus
disks:
    - name: secondary
      bus: usb
      size: 1Gi

It clones the source image onto a usb-bus disk, which the guest reports as removable media and the firmware will not boot, and it creates no second disk at all, so a provisioner looking for a blank device finds nothing.

List the boot disk first and the extra disk after it:

# Attach a blank 1Gi USB drive alongside an 40Gi boot disk
disks:
    - name: rootdisk
      size: 40Gi # bus defaults to virtio
    - name: secondary
      bus: usb
      size: 1Gi

usb is the right bus for blank data/transfer drives you want the guest to see as removable, and it is slower than virtio, so use it only for that. scsi and sata are bootable; bus: scsi on the boot disk is the recommended pattern for Windows, matching the vioscsi driver (see Windows from ISO).

#NIC fields

#Subnet fields

#VPC fields