Under the “Import Zvol” menu, it says “Importing a zvol as Instances volume allows its lifecycle to be managed, including backups, restores, and snapshots. This allows portability between systems using standard tools.”
However, I cannot figure out how to actually perform backups, restores, and snapshots for Instance volumes through the GUI - I think it would be possible from the command line, but I generally like to stick to the GUI for such tasks. Is this functionality actually shipped with 25.04, or is planned for a later release?
Bumping because I’m actually getting a bit nervous here - still have not figured this out, and not super keen on my VM’s being vulnerable until, what, Goldeye?
Backing up the whole pool is not great for me. I have one VM that is doing rolling packet captures and I’m going to burn up a lot of my storage space on these snapshots now.
I setup a replication task in the UI from MYPOOL/.ix-virt/custom to BACKUPPOOL/custom with recursive checked and it seems to be doing the thing. Now I just need to tweak and fiddle with replication jobs until I get back to where I was before.
Importing allows Incus to manage the volumes, allowing access to it’s native backup tools. There is currently no UI support for the backup features, but it is being worked on.
You may be able to use Incus commands to manage this via the command line, but I don’t have any experience with it.
While I agree that using the Incus storage pool should be the main default way to manage VM volumes there is also available “Path in the host” method which could just mount any zvol on host which would quickly allow people to use Incus with snapshots managed by Truenas the same way as in EE while Incus implemention matures.
Implementing also seems simple.
Path on the host
You can share a path on your host (either a file system or a block device) to your instance by adding it as a disk device with the host path as the source:
incus config device add <instance_name> <device_name> disk source=<path_on_host> [path=<path_in_instance>]
The path is required for file systems, but not for block devices.
That’s basically reverting to 25.04-RC1 functionality, cool.
I’m going to move forward with bending the volume management to my will. There were some ARC caching changes they made that apply only to that dataset that I would like to take advantage of.
Lol yes, that is true. The only improvement is the ability to change boot priority and I/O Bus – I had issues with boot priority on the RC (wasn’t an option, and struggled with workaround). So I can honestly say that now, I’m in a relatively good place.
Is there any guidance that iX can provide about any gotchas or anticipated-safe practices would be here? Incus CLI is great, powerful, easy etc. but there’s the “don’t use the CLI” warning that the GUI flashes up…
I know an official position might be hard to come by, but as long as we use Incus tooling to remove anything we create (i.e. don’t go behind its back and delete something with ZFS tooling that we created with Incus tooling) would this be anticipated to be generally safe? At least within the range of the user not doing something stupid?
