This message was deleted.

afaik the boot disk must be block storage. The boot disk was still Longhorn? You're just adding a secondary disk for a data volume?

My secondary disk is an HDD, which is why I wanted to test creating VM volumes on the SSD boot device instead. By default, the Harvester StorageClass only points to the HDD (

/dev/sdb

), and from the UI it doesn’t seem possible to create a StorageClass that uses the boot device (

/dev/sda

). So I wanted to confirm whether this limitation is expected. Here is the output of

lsblk -fl

from the host:

NAME FSTYPE FSVER LABEL      UUID                                 FSAVAIL FSUSE% MOUNTPOINTS
loop0
     ext2   1.0   COS_ACTIVE 929fd4fd-2295-4b9a-ab4c-fc8b6da36aff    1.2G    56% /
sda
sda1
sda2 ext4   1.0   COS_OEM    4fba76b1-5e3b-44db-b2ce-153c213dae3f     38M     1% /oem
sda3 ext4   1.0   COS_RECOVERY
                             0a06f934-70e2-4f92-b420-5346f03323f1
sda4 ext4   1.0   COS_STATE  57bb34ce-2ca9-4fda-8a23-539f98848710   10.6G    23% /run/initramfs/cos-state
sda5 ext4   1.0   COS_PERSISTENT
                             6c8f906a-66a1-46a2-bdb0-0e7cd5dfaed1    1.5T     4% /var/lib/longhorn
                                                                                 (plus various kubelet/system dirs)
sdb  ext4   1.0   HARV_LH_DEFAULT
                             dfc5f58c-85d5-445a-8a0a-bc5efbd51ddc    7.2T     0% /var/lib/harvester/defaultdisk

From what I can see, Longhorn is using

/dev/sda5

heavily for system components, which might explain why the UI doesn’t allow creating a StorageClass on the boot disk. Just trying to confirm if the boot disk is intentionally unavailable for VM data volumes.