This message was deleted.

I don't think the default disk behaves any different than any other disk in this regard. It should be possible to apply the normal procedure for removing/replacing a disk with Longhorn: https://longhorn.io/docs/1.11.1/maintenance/maintenance/#removing-a-disk I.e. you'll first have to disable scheduling for that disk, then drain all replicas off it and then you can remove it. Once the old disk is removed from Longhorn, you can add the new disk. The only exception I can think of is when you've configured the default disk to be the same as the Harvester system disk. Then you'd obviously have to deal with the Harvester installation itself as well.

mount point is at least different

Do you mean the default storage disk or the boot disk?

the fs on the default disk also needs to be labelled HARV_LH_DEFAULT, or the system won't boot correctly

Thanks for the responses. Yes, this is about the default storage disk, which is on a separate physical disk and not the OS disk. @ambitious-daybreak-95996 So just to confirm — I should remove the disk via the Longhorn UI (since I can’t do it from the Harvester UI), and then format the new disk as ext4 with the label

HARV_LH_DEFAULT

. Also, as @rhythmic-article-81903 mentioned, do I need to update the UUID in the

longhorn-disk.cfg

as well?

If you remove the disk via the LH UI, then format the new disk as ext4 with the label HARV_LH_DEFAULT, then add that disk back via the LH GUI, I'd expect LH to treat it as a new disk, and (I hope) you wouldn't have to mess with longhorn-disk.cfg yourself. Disclaimer: I haven't actually tried this myself so I'm not 100% certain.

If you have enough nodes and an automated node deployment, I'd simply remove the node from Harvester, fix the disk and redeploy it again.

Hello @ambitious-daybreak-95996, I tested this and the solution is actually a combination of what both you and @rhythmic-article-81903 suggested. Here is the approach that worked for me. What I did was: 1. Set the default disk to

Disable Scheduling

so Longhorn would stop using it. 2. Unmounted the current default disk. 3. Removed the old disk and attached the new one. 4. Formatted the new disk and added the

HARV_LH_LONGHORN

label. 5. Mounted the new disk again. 6. Enabled scheduling on the disk. At this point, Longhorn created a new

longhorn-disk.cfg

file with a different

diskUUID

than the one stored in

<http://nodes.longhorn.io|nodes.longhorn.io>

, which caused an error because the values no longer matched. To fix this, I took the old

diskUUID

value from

<http://nodes.longhorn.io|nodes.longhorn.io>

and manually replaced the new

diskUUID

inside

longhorn-disk.cfg

. After that, Longhorn recognized the disk correctly and everything started working again. So, simply formatting the new disk, applying the

HARV_LH_LONGHORN

label, and mounting it again is not enough because Longhorn generates a new

diskUUID

. I performed all of this while the node was running, without requiring a reboot. This is currently my workaround. I tested it on an empty Harvester installation without any VMs, although I do not think it should matter whether VMs exist or not. Once the disk is set to

Disable Scheduling

, Longhorn stops writing to it and, as far as I understand. That means when the disk is enabled again with

Enable Scheduling

, Longhorn should automatically recreate everything, even if the disk itself is empty. If I get the chance, I will also test this scenario with a running VM.

Nice work @gentle-actor-15883 ! Juse one small thing, that label should be

HARV_LH_DEFAULT

(not

HARV_LH_LONGHORN

) to get mounted properly after a reboot

Hi @ambitious-daybreak-95996, thanks! I didn’t realize I’d written it incorrectly