VM Disk missing after update to Fangtooth and rollback to EE

Apps and Virtualization
1

I updated my TrueNAS Scale to Fangtooth, and attempted to recreate my existing VM under the new OS. After failing to do so, I rebooted back into EE, hoping to launch the VM there and post for support once I had it back up and running.

However, when I got back into EE, the VM was unable to launch. After digging a bit, it appears the disk for the VM is missing - I suspect the volume was accidentally deleted when I tried to remove the disk during setting it up under Fangtooth.

I have snapshots of my datasets, including /mnt/data/vmware, which used to include the volume under it. I rolled the dataset back to last night’s snapshot, but the volume is still missing.

When I look in the Virtualization settings, I see that the settings for the volume point to: /dev/zvol/data/vmware/virtualmin-5uzyho However, the path /dev/zvol/data no longer exists - when I go to /dev/zvol, I only see /dev/zvol/onsite-backup as the only sub-path.

What are my options to bring back the missing volume for my VM? I have snapshots of my data, and I can see the volume in my backup datasets.

2

I think I know what happened - I may have accidentally clicked on “move” instead of “copy” when importing.

3

Why would you need to move or copy when importing? Can you not just point to the existing zvol where it is?

1 Like
4

Apparently, this is a part of the migration process from EE to FT - it needs to update the volume to use the new vm system, Incus.

5

I had a similar situation - a virtual machine with Windows 10 did not boot and the zvol with the disk of this system disappeared from the original location. Windows could not boot because it was installed with a legacy BIOS. I had to restore the zvol from a backup copy, boot into TrueNAS 24.10, run and migrate to UEFI using mbr2gpt.exe. After that, I booted into 25.04 again and created a VM by importing a new GPT zvol. All fine after that.

6

OK, I was able to restore the zvol (thank goodness), and I was able to import it into volumes in Instances without a problem. I can see it now, and I still have the original file if needed.

Now I am trying to add it to an Instance. When I set up the new Instance, I choose an existing volume, and choose the volume from the list. But when I create the instance, it automatically adds a 10GB root volume as well, and is not booting from the volume I imported.

I did google this up, and all of the advice I am seeing says to just choose the existing volume at creation. But I can’t figure out how / why it’s adding the additional disk, and not using the volume I want to boot from.

7

OK, even weirder, when I create a brand new Instance, it’s automatically adding a 10 GB Root Disk as well, in addition to the ISO or any other disks I create.

8

Incus creates a root volume by default for instances. I believe there was some discussion on this but it was decided not to fight the upstream behavior.

9

Relevant statement from main Incus dev:

stgraber4:34 pm

The root disk must always exist and is the only one that gets snapshotted, backed up and moved around as part of the instance.

For VMs, you can make it tiny and never use it, instead relying on external disks (custom block volumes) for everything, but you can’t fully remove the root disk as it’s assumed by a lot of different code paths to be present.

1 Like
10

The beta and RC allowed to use an existing z volume without a need to move or clone it.

So when I updated from the RC to the release my haos zvol stayed in place and did not disappear on me.

I’m getting kind of frustrated here as well.

I understand the root disk is an upstream requirement but per developer comment the root disk can be created to a tiny size but we’re forced to a 10 GB minimum in TrueNAS.

And why do we now have to import the zvol in some fashion? Does either the clone or move option import it to the root disk?

11

Yeah, I feel you.
The “Instances” are experimental at best !

Unfortunately I installed a Win10 VM with legacy BIOS, dont ask my why. Now I either have to wait for the fix in Incus with the seabios location to make it to Truenas or convert the VM to UEFI - possibly opening another can of worms… :grimacing:

Thankfully I just cloned the zvol and didnt move it, so it was easier for me to roll back.

1 Like
12

Easy way to convert Windows VM from BIOS to UEFI loader from Microsoft: Redirecting
Pre-requisites:

  1. The MBR disk must have at most 3-partitions.
  2. The OS must be 64-bit.
  3. Bitlocker or encryption must be turned off .
  4. There should be an Operating system on the disk.
  5. One of the partitions must be active (confirm that from disk Management).
  6. No dual boot.
  7. Windows 10 version must be at least version 1703.
13

This is good to know, thank you! I’m trying to determine if it’s better to recommend a clone or a move when importing.

I got some better understanding of the reasoning behind having to now import a zvol in another thread. Basically, it seems like there may have been some performance issues with directly using a zvol. Additionally, this will allow Incus to fully manage the instance volumes, which in turn will allow Incus’s native backup/restore and snapshot functionality.