Disk layouts: worked examples

How the node installer is told what to do with a node's disks: one layout per shape, with the commands that put it in place. Every layout below is written in the shorthand the luna command accepts; luna group showdisklayout shows the same layout with every default filled in.

All examples assume a group that installs to disk, so its scripts must not mount a tmpfs root:

# luna group clone compute diskful
# luna group change diskful --install-mode auto -qpart 'true' -qpost 'true'

A layout is loaded from a file with -qdl, or written in $EDITOR with --disklayout:

# luna group change diskful -qdl /root/layout.yaml
# luna group showdisklayout diskful

Note

Luna stores a disk layout in JSON, its own format. YAML is accepted for convenience, for instance when writing a first layout: it is converted to JSON when it is stored, so comments and formatting in the YAML are not kept. luna group showdisklayout -R prints the stored JSON. The editor opens the stored layout as YAML.

Nodes inherit the group's layout; a layout set on a node replaces it as a whole.

One disk, found at boot

The OS on any disk of at least 20 GB. The three volumes take their defaults: a 600 MB EFI partition, a 1 GB /boot and the rest as / on LVM.

version: 2
sets:
  - role: os
    match: {min_size: 20G}
    volumes: [/boot/efi, /boot, /]

Stored, and as the node receives it, the same layout reads:

{
  "version": 2,
  "sets": [
    {
      "name": "os", "role": "os", "selection": "discover", "raid": "none",
      "match": {"min_size": "20G"},
      "volumes": [
        {"name": "uefi", "mountpoint": "/boot/efi", "fs": "vfat", "provider": "partition", "size": "600M"},
        {"name": "boot", "mountpoint": "/boot",     "fs": "xfs",  "provider": "partition", "size": "1G"},
        {"name": "root", "mountpoint": "/",         "fs": "xfs",  "provider": "lvm",       "size": "100%"}
      ]
    }
  ]
}

One disk with swap and a separate /var

One discovered disk of at least 100 GB: a 2 GB /boot, and on LVM 16 GB of swap, 64 GB for /var and the rest as /. Swap is a partition unless lvm is given.

version: 2
sets:
  - role: os
    match: {min_size: 100G}
    volumes:
      - /boot/efi
      - [/boot, 2G]
      - [swap, 16G, lvm]
      - [/var, 64G]
      - /

luna group showdisklayout shows it in full:

sets:
- match: {min_size: 100G}
  name: os
  raid: none
  role: os
  selection: discover
  volumes:
  - {fs: vfat, mountpoint: /boot/efi, name: uefi, provider: partition, size: 600M}
  - {fs: xfs, mountpoint: /boot, name: boot, provider: partition, size: 2G}
  - {fs: swap, mountpoint: swap, name: swap, provider: lvm, size: 16G}
  - {fs: xfs, mountpoint: /var, name: var, provider: lvm, size: 64G}
  - {fs: xfs, mountpoint: /, name: root, provider: lvm, size: 100%}
version: 2

One named disk

The same, on exactly one device. Listing devices makes the set manual.

version: 2
sets:
  - role: os
    devices: [/dev/disk/by-path/pci-0000:03:00.0]
    volumes: [/boot/efi, /boot, /]

RAID 1: the OS mirrored over two SSDs

version: 2
sets:
  - role: os
    raid: "1"
    match: {tags: [ssd]}
    volumes: [/boot/efi, /boot, /]

The mirror takes the two smallest SSDs that match. Quote the RAID level: "1", not 1.

RAID 0: the OS striped over two NVMe disks

Speed, no redundancy; a lost disk means a reinstall, which auto performs by itself.

version: 2
sets:
  - role: os
    raid: "0"
    match: {tags: [nvme]}
    volumes: [/boot/efi, /boot, /]

RAID 5: a data set next to the OS

The OS on one SSD; four spinning disks as a single-parity set mounted on /data. Parity RAID is for data sets only — the OS set refuses it. A data volume needs an explicit size.

version: 2
sets:
  - role: os
    match: {tags: [ssd]}
    volumes: [/boot/efi, /boot, /]
  - role: data
    raid: "5"
    match: {tags: [rotary]}
    volumes:
      - {mountpoint: /data, size: 100%}

auto and sync never wipe a data set; only full does.

RAID 1 OS with a RAID 6 workspace

The OS mirrored over two SSDs, and six spinning disks of at least 8 TB as a dual-parity workspace on /scratch. count fixes the number of members where the RAID level allows a range.

version: 2
sets:
  - role: os
    raid: "1"
    match: {tags: [ssd]}
    volumes: [/boot/efi, /boot, /]
  - role: data
    raid: "6"
    count: 6
    match: {tags: [rotary], min_size: 8T}
    volumes:
      - {mountpoint: /scratch, size: 100%}

A legacy BIOS node that boots from its own disk

A node whose firmware is in BIOS or CSM mode installs like any other. Asking for a bootloader puts GRUB in the master boot record of the boot disk, so the node starts the installed system without the network.

version: 2
sets:
  - role: os
    bootloader: grub
    devices: [/dev/sda]
    volumes: [/boot/efi, /boot, /]

The EFI partition is created on a BIOS node too, so the same disk needs no repartitioning if the node is later switched to UEFI.

On a mirror, every boot disk gets the bootloader:

version: 2
sets:
  - role: os
    raid: "1"
    devices: [/dev/sda, /dev/sdb]
    bootloader: grub
    volumes: [/boot/efi, /boot, /]

A node that never boots from disk

The node network boots every time and the controller stays in charge of what it runs. No bootloader is written, and one left by an earlier install is removed:

version: 2
sets:
  - role: os
    bootloader: none
    devices: [/dev/sda]
    volumes: [/boot/efi, /boot, /]

OS from RAM, local data kept

The node runs diskless, and one local disk holds data that must survive every reinstall. A persistent set is never partitioned, formatted or written by the installer; it is only mounted, and only sanitize erases it. With no OS set declared, install_mode: auto runs the OS from RAM.

version: 2
sets:
  - role: data
    persistent: true
    devices: [/dev/disk/by-path/pci-0000:05:00.0]
    volumes:
      - {mountpoint: /data, size: 100%}

Discover once, then pin

The first install resolves the recipe and writes the disks it used back to the node as a manual layout; every boot after that reproduces exactly those disks.

version: 2
sets:
  - role: os
    raid: "1"
    match: {tags: [ssd]}
    save: true
    volumes: [/boot/efi, /boot, /]

After the first install, luna node showdisklayout node001 shows the pinned devices. To return the node to the group's recipe, clear its layout:

# luna node change node001 -qdl ''

Re-provisioning a node that boots from its own disk

Once a node's entries are first in the boot order, setting netboot on its own no longer brings it back for a reinstall: the firmware starts the disk before it asks the controller. Send it through the network once, from the node

# efibootmgr -n <the EFI network boot entry>
# reboot

or out of band, without touching the node:

# ipmitool -H <bmc> -U <user> -P <password> chassis bootdev pxe options=efiboot

Both are one-shot: the saved boot order is left alone, so the node returns to booting its own disk on the next boot. Nodes left on the default last are unaffected, because the network entry is already ahead of the disk.

Reinstalling and handing over

The layout stays; only the mode changes.

# luna node change node001 --install-mode full       # wipe and reinstall, data sets included
# luna node change node001 --install-mode sanitize   # securely erase every disk, no install
# luna node change node001 --install-mode auto       # back to normal disk use afterwards