ExistingVolumeConfig and VolumeStatuses.spec.phase missing (using ZFS)

[KimNorgaard]

Talos doesn't seem to update VolumeStatuses.spec.phase when using ExistingVolumeConfig. Not sure if it's by design or a bug or if I'm doing something wrong.

Everything works fine, though. The volume is mounted and I can write to it. It's just that Talos doesn't quite seem to set the correct state.

I create a ZFS filesystem that I mount using ExistingVolumeConfig like this:

# chroot /host zfs create -V 1G csi/myfs

# ls -l /host/dev/zvol/csi/myfs
lrwxrwxrwx    1 root     root            10 Mar 13 10:48 /host/dev/zvol/csi/myfs -> ../../zd16

# chroot /host mkfs.ext4 -L "MYFS" /dev/zvol/csi/myfs
mke2fs 1.47.3 (8-Jul-2025)
Discarding device blocks: done
Creating filesystem with 262144 4k blocks and 65536 inodes
Filesystem UUID: 405cd922-6b5d-450d-9958-92dea2a62eee
Superblock backups stored on blocks:
        32768, 98304, 163840, 229376

Allocating group tables: done
Writing inode tables: done
Creating journal (8192 blocks): done
Writing superblocks and filesystem accounting information: done

Talos discovers the volume:

node: 192.168.1.31
metadata:
    namespace: runtime
    type: DiscoveredVolumes.block.talos.dev
    id: zd16
    version: 2
    owner: block.DiscoveryController
    phase: running
    created: 2026-03-13T10:48:35Z
    updated: 2026-03-13T10:52:29Z
spec:
    dev_path: /dev/zd16
    type: disk
    device_path: /sys/devices/virtual/block/zd16
    offset: 0
    size: 1073741824
    pretty_size: 1.1 GB
    sector_size: 512
    io_size: 33554432
    name: ext4
    uuid: 405cd922-6b5d-450d-9958-92dea2a62eee
    label: MYFS
    block_size: 4096
    filesystem_block_size: 4096
    probed_size: 1073741824

I then apply this patch:

apiVersion: v1alpha1
kind: ExistingVolumeConfig
name: myfs
discovery:
  volumeSelector:
    match: volume.partition_label == "MYFS"

$ talosctl patch mc -p @uservol.yaml¬
  patched MachineConfigs.config.talos.dev/v1alpha1 at the node 192.168.1.31¬
  WARNING: extra kernel arguments are not supported when booting using SDBoot¬
  Applied configuration without a reboot

A VolumeConfig is created:

node: 192.168.1.31
metadata:
    namespace: runtime
    type: VolumeConfigs.block.talos.dev
    id: e-myfs
    version: 2
    owner: block.VolumeConfigController
    phase: running
    created: 2026-03-13T10:57:41Z
    updated: 2026-03-13T10:57:41Z
    labels:
        talos.dev/existing-volume:
    finalizers:
        - block.VolumeManagerController
spec:
    type: partition
    provisioning: {}
    locator:
        match: volume.partition_label == "MYFS"
    mount:
        targetPath: myfs
        selinuxLabel: system_u:object_r:ephemeral_t:s0
        projectQuotaSupport: false
        parentId: /var/mnt
        fileMode: 493

But notice that provisioning is empty.

Consequently the VolumeStatus is in phase missing:

node: 192.168.1.31
metadata:
    namespace: runtime
    type: VolumeStatuses.block.talos.dev
    id: e-myfs
    version: 1
    owner: block.VolumeManagerController
    phase: running
    created: 2026-03-13T10:57:41Z
    updated: 2026-03-13T10:57:41Z
    labels:
        talos.dev/existing-volume:
spec:
    phase: missing
    type: partition
    mountSpec:
        targetPath: myfs
        selinuxLabel: system_u:object_r:ephemeral_t:s0
        projectQuotaSupport: false
        parentId: /var/mnt
        fileMode: 493

[smira]

Talos doesn't have native support for ZFS, neither what you do is correct, you match on a partition label, while labeling ext4 filesystem.

[smira]

So Talos is correct - the volume you specified is indeed missing.

[KimNorgaard]

That's why i create an ext4 filesystem which makes Talos discover the device as a regular block device. Shouldn't really matter if the underlying provider for the ext4 filesystem is ZFS or not, right?

As I wrote, everything works except for how Talos reports it.

Would the correct approach be to create the ExistingVolumeConfig using the label and then a VolumeConfig using the device (zvol/csi/zot-registry) as the disk selector and let VolumeConfig handle the ext4 formatting?

[smira]

I can't speak for ZFS volumes, not sure. But my point is that partition label and filesystem label are two different things.

[KimNorgaard]

Using another selector did the trick. You can use either ExistingVolumeConfig like:

apiVersion: v1alpha1
kind: ExistingVolumeConfig
name: myfs
discovery:
  volumeSelector:
    match: volume.uuid == "5a9f81a0-0c64-4ef2-ad89-b0ce565c9e90"

or UserVolumeConfig like:

apiVersion: v1alpha1
kind: UserVolumeConfig
name: myfs
volumeType: disk
filesystem:
  type: ext4
provisioning:
    diskSelector:
        match: disk.uuid == "5a9f81a0-0c64-4ef2-ad89-b0ce565c9e90"
        # or match: disk.dev_path == "/dev/zd0" but this seems potentially less stable

After which you can do talosctl get volumestatuses e-myfs -o yaml:

node: 192.168.1.3
metadata:
    namespace: runtime
    type: VolumeStatuses.block.talos.dev
    id: e-myfs
    version: 2
    owner: block.VolumeManagerController
    phase: running
    created: 2026-03-13T19:35:42Z
    updated: 2026-03-13T19:35:42Z
    labels:
        talos.dev/existing-volume:
    finalizers:
        - block.MountController
spec:
    phase: ready
    type: partition
    location: /dev/zd0
    mountLocation: /dev/zd0
    uuid: 5a9f81a0-0c64-4ef2-ad89-b0ce565c9e90
    size: 524288000
    prettySize: 524 MB
    filesystem: ext4
    mountSpec:
        targetPath: myfs
        selinuxLabel: system_u:object_r:ephemeral_t:s0
        projectQuotaSupport: false
        parentId: /var/mnt
        fileMode: 493

[rlutsch18]

Hello! Maybe I am on the wrong thread, but I am fighting many hours getting ExistingVolumeConfig to run with v1.12.6. Not quite sure if this version already supports ExistingVolumeConfig? I have three HP ProDesk mini's having one /dev/sda SSD. I would like to use 100GiB of the 240GiB for a Longhorn volume, the rest should used by Talos. I deleted all partitions an created one XFS Partition with 100GiB and labled it "LONGHORN". I would be very greatfull getting a hint in the right direction. Maybe I did it wrong not to use the talosctl patch command.