How could I manage bootable volumes on Incus?

Incus
1

Hi everyone,

currently on openstack it’s possible create and manage bootable volume, basically is a volume that has been booted with an specific image before the VM creation, the main benefit of that is because we can specify IOPS limitations for the bootable volume for instance.

Is there something similar of that on Incus ?

2

I suspect the concepts are pretty different, but hopefully the ability remains mostly the same.

If you want to attach an existing disk (and potentially share it with other VMs), you can create a custom storage volume of block type:

incus storage volume create POOL NAME size=50GiB --type=block

And then attach it to a VM and tweak its boot priority to have it booted rather than boot from the VM’s primary disk. You can also tweak limits on that, in this case setting both read and write IOps limits.

incus config device add VM DEVICE-NAME disk pool=POOL source=NAME boot.priority=10 limits.max=500iops

Now if the goal is to have new VMs get an IOps limit out of the box, the easiest is to set an IOps limit on the root disk through a profile.

incus profile device set default root limits.max=500iops

At which point all current and future VMs using the default profile will get the 500iops limit applied to their primary (root) disk.

3

Hi @stgraber, thank you for your reply!

that’s amazing, related to resizing that bootable volume, is there any limitation on that ? I read somewhere that we can’t shrink the bootable volume, only increase it, is that true ?

4

That’s correct.

We could very easily allow shrinking the underlying block, the problem obviously is with its content. We don’t want to get into the re-partitioning and partition resizing game and it’s so so easy for someone to just mess up their resizing by a few bytes or by messing up GiB and GB which then causes irrecoverable data loss.

For that reason, we just flat out refuse to shrink a volume. Though as you’ve possibly seen in the other thread, it’s certainly possible to work around it and we may add a first party way to do it if we can figure out a good workflow where the user will be sufficiently warned :slight_smile: