Expose options for the incus dataset

Problem/Justification
I would like the ix-virt dataset to be exposed to the UI.
This would make it easier (especially for users newer to incus) to understand what it’s doing under the hood. Currently TrueNAS silently creates the dataset and stores new container volumes and templates there.
In the UI it says that there is something stored on the pool that takes x gigabytes but it doesn’t tell you where or what it is used for. Even when they go into the shell and search for it they can’t really find it. Not even with ls -a. This is especially bad for downloaded templates since there is (I think) currently no way to remove them via the UI.
It would additionally allow to set custom properties to the dataset like a separate snapshot schedule or compression method.

Another nice feature would be that when creating a new container the user gets to choose in which dataset the container disk gets stored (Similar to how it’s working for VMs in EE). Also another thing I would find useful is to limit the size a container volume can grow to. Proxmox already allows these things via it’s UI.

Impact
The change to expose the dataset to the UI would make things more clear and would allow people to choose compression or snapshot timing independently from the rest of the pool.
This would probably be a simple fix.

Limiting the size of a container disk is already supported by incus (I think the size property does exactly that) so it would probably also just have to be exposed to the UI.

User Story
Personally I found the current behavior confusing so I would guess other users would fall into the same trap when the next release gets out of the nightly stage.

I use the feature to limit container disk size all the time in proxmox and think it’s a very useful feature.

5 Likes
I don't know about this feature... I have a more nuanced approach...

YESSSSSSSSSSSS!!!1111 DO IT RIGHT NOW!!!

WHY ARE YOU STILL READING THIS? CLICK “VOTE” ALREADY.

Related thread for reference. See point #2.

1 Like

Update:
I’m not really sure how the instances are supposed to be backed up through the GUI without implementing this feature request.
I have setup a snapshot task for the entire pool where my incus is pointed to and then also added a cloudsync task (again for the entire pool). But when I go look into the statistics of the backup it seems like the content of .ix-virt hasn’t been backed up together with the other data on the pool.
Maybe I missed something but it definatly doesn’t seem very intuitive if I missed something.

On Core, with the iocage dataset[1], you can:

  1. Configure its properties, including encryption, compression, and recordsize
  2. Manually take a snapshot of it
  3. Create a Periodic Snapshot Task for it
  4. Include it in a Replication Task

All in the GUI.

I don’t see why this would be different for the .ix-virt dataset.


  1. The above can even be done on an individual basis for each jail or jail filesystem ↩︎

Never used Jails but yes, this seems exactly like what I had in mind for this feature request (+ limiting the size of the disks).