Skip to content

Placement and disks

affinity_host steers each VM to a physical host, but the real anchor is the host-local SR its disks sit on: a VM cannot boot where its storage is not.

Node Host SR
talos-01 gewisvhost1 vhost1-ssd2
talos-02 gewisvhost1 vhost1-ssd2
talos-03 gewisvhost3 vhost3-ssd

Two nodes share vhost1 for now because vhost4 is out of space; move a node by changing one map entry once it frees up. The pool is vhost1/vhost3/vhost4 — there is no vhost2.

Two disks per node: a 40 GiB system disk (xvda) and a 150 GiB Longhorn data disk (xvdb). The system disk cannot be grown in place — Talos fixes the STATE partition boundaries at install, so resizing it later means replacing the VM (tofu apply -replace), cheap for a fresh node. The Longhorn disk is the opposite: grow the VDI and its UserVolumeConfig expands on the next boot.

Longhorn's data disk is mounted by a UserVolumeConfig named longhorn, which forces the mount to /var/mnt/longhorn; Longhorn's Helm defaultDataPath must match. The disk is selected by !system_disk rather than a device path, so Xen attach order cannot misroute it. machine.disks is deprecated from Talos 1.10 on and UserVolumeConfig is its replacement.

The kubelet needs a bind mount for that path as well, or Longhorn cannot publish volumes into workload pods:

machine:
  kubelet:
    extraMounts:
      - destination: /var/mnt/longhorn
        type: bind
        source: /var/mnt/longhorn
        options: [bind, rshared, rw]

Size the data disk above the largest volume it must hold: Longhorn schedules a replica only when the disk fits the whole volume, and a PVC the size of the disk does not fit it once filesystem overhead is taken. storageReservedPercentageForDefaultDisk: 0 is safe here only because the disk is dedicated to Longhorn.