Prior to 24.10 being released, a post by HoneyBadger noted that there would be a path in 24.10 to migrate Containers back to VMs, so it did not need to be done manually. Now that 24.10 is out, it notes (noted in this post) that Containers need to be migrated manually as there is no automated way to do this. Given this change, I figured it would be bettter to migrate now, than update to 24.10 and then run into a problem.
The .ix-virt directory contains the zvols used in Instance VMs. Ignore the entries with the .block extension, and those not included in the .ix-virt directory.
When I run the command to get the listing, I only have .block items listed:
geoffrey@TrueNAS:~$ sudo zfs list -t volume -r -d 10 data
NAME USED AVAIL REFER MOUNTPOINT
data/.ix-virt/deleted/images/7d7e85dc2ee6694dd99c327a43999425f0eb12e757e7393830dfa2b6b9590030.block 829M 6.47T 829M -
data/.ix-virt/virtual-machines/virtualmin.block 97.2G 6.47T 40.1G -
geoffrey@TrueNAS:~$
What is the best path forward, to migrate my Container to a VM, before upgrading to 24.10?
Also, if possible, I’d like to clone / copy the volume, not move it, in case there’s an issue and I need to revert. (I can always re-import it back into Incus, but it’d be better not to.)
I’m trying to run down this issue. Can you give me a little more about the history of this VM? Was virtualmin migrated from 24.10 into 25.04 or created natively in 25.04?
I need to think back on this. I remember setting it up in Containers under 25.04, as it would not migrate cleanly from its previous incarnation as a VM under EE, and I had to rebuild from scratch.
A few months back, I set up a weekly CRON job to export the Virtualmin container to a backup file, so that if there was an issue with the container, I could whack it and re-import it. When VMs were re-introduced in Fangtooth, I tried to migrate the Container back to a VM, but it failed - the new VM would not launch. After seeing the note that there would be a path to migrate automatically under 25.10, I restored from the backup file using the command line to import it back into Incus. That is likely the twist that is causing this issue.
When I first tried to migrate from a VM to a Container, I ran into the issue that it moved the volume, and caused a LOT of pain because I could not revert back to a saved copy of the working VM (That is on me, I missed the Copy vs Move toggle when I was doing it). Since then, I’ve learned my lesson in that one should always copy instead of move when possible, and have a tested backup in place before doing a migration… although in this case, it seems that restoring from backup introduced a new issue.
This fits with what I’m thinking is happening with this and a few other users who have similar issues. I have a feeling that when this was documented it was done using a migrated VM and natively created VMs use a different storage layout. Once I can confirm the issue and validate the process still works with .block volumes, the doc will likely be updated.
The updated procedure is being published now, but basically I believe you should be good to follow the original steps and commands, just use the *.block volume instead of the custom/default_*
