New VM creation error (Image conversion failed)

Apps and Virtualization
1

I’m trying to create a Windows VM as the last part of staging/testing before I rebuild that server.

I’ve exported the Windows system drive using Starwinds P2V and Disk2VHD, mostly relying on VHDX containers (in case I need to give up on getting it running via TrueNAS and add them to Hyper-V on my desktop[1]). The files seem to copy to my TN pool ok over the network, and a validation check shows no issues (qemu-img check $file / No errors were found on the image).

When I go to create the new VM in TN - sometimes it will let me create new a new zvol from the selected disk image, sometimes it’s really unhappy until I manually create a zvol and then use exisitng. Sometimes - like tonight - it doesn’t matter which way I try, I get the same error:

Image conversion failed: One path must be a disk image and the other must be a ZFS volume

image
image391×819 18 KB
image
image386×900 19.3 KB

Sometimes I get lucky and I can run the import/conversion via SSH - but not today, where it gives the same error:

% midclt call vm.device.convert '{"source": "/mnt/slow/data/media/disk2vhd/VMs/vnichers/20260919_nichers_c-only.VHDX", "destination": "/dev/zvol/slow/data/vNichers6"}'

[EINVAL] vm.device.convert: One path must be a disk image and the other must be a ZFS volume

image
image403×343 6.42 KB

  • apart from trash path naming (because my /slow pool is just a temporary mirror vdev), I don’t feel like I’m doing anything outlandish here

FWIW:

  • TrueNAS 26b3
    • running as a VM under Hyper-V on Win11 Pro
      • TN is running on a 250GB Samsung SSD, not a virtual disk image/file
      • when I’m happy with some migration stuff, I’ll change my boot order and boot TN natively
    • Host hardware:
      • AMD 3700x, 64GB RAM
    • VM hardware passed through:
      • 1x 250GB SATA SSD (pool: boot)
      • 3x 100GB SAS SSD RaidZ1 (pool: fast)
      • 2x 14TB HDD mirror vdev (pool: slow)
      • 16GB RAM
      • 8 vCPUs

Not really sure if this is a bug or if I’m fundamentally misunderstanding the TN process for this :woman_shrugging:

  1. I saw Divad had some luck converting to qcow2 first. I’m setting up a vhdx->qcow2 conversion overnight, but I’d like to think that if the TN UI is explicitly stating it can work with vhdx images, then I shouldn’t need to be manually holding it’s hand by doing intermediate steps like this ↩︎

2

yeah that midclt error is usually the convert helper not seeing one side as an image / the other as a real zvol.

two things that bite me on that:

  1. uppercase .VHDX. rename (or copy) to lowercase .vhdx first. the convert path matches on the extension and ive seen uppercase fail the “is a disk image” check even when qemu-img check is fine.

  2. skip midclt and write it yourself after the zvol exists:

sudo qemu-img convert -p -O raw /mnt/slow/data/media/disk2vhd/VMs/vnichers/20260919_nichers_c-only.vhdx /dev/zvol/slow/data/vNichers6

make sure ls -l /dev/zvol/slow/data/vNichers6 actually exists before that (create the empty zvol in the ui first, sized at least as big as the image).

then in the vm wizard pick Use existing disk / Select Existing Zvol, dont Import Image again.

if qemu-img convert works but the guest wont boot later, that is usually the disk2vhd/p2v image itself (gen1 vs gen2 / uefi), which is a separate fight from this convert error.

3

I don’t know if it is related, but v26 beta 3 cannot run virtual disks with 4096 logical sectors and the vhdx import also has this issue.

4

Good call, @shoulders - I’ve just checked now and the base Windows fs I imaged is set to 512, not 4k - and the same for the VHDX created. It looks like the zvol I manually created decided to use 16k blocks, tho’ :thinking:

Thanks @nite_route - I completely overlooked the quirks of moving to a case-sensitive filesystem : (

When I was up earlier this morning, the example I included was after I’d manually made the zvol, and it checked out ok via ls. Renaming the extension to be lower case, and it’s at least handling the image to zvol conversion ok!

Fingers crossed this works out and is reliable, and then I can go back to working out why disk2vhd keeps exiting early during the snapshot creation, and why Starwinds’ V2V doesn’t show me physical disks to image (or if I go another route, won’t let me export a single disk from the whole machine to a local file)

5

This is normal. These are the internal block sizes used for Zfs/zvol volblocksize or the virtual disk image to write to disk.

16k is the recommended block size for general vms on a zvol.

The only issue, but will not cause a fail, is that the import export wizard does not let you set this, I will be making a feature request soon.

6

Making sure the disk image was using .vhdx and not .VHDX made the import wizard happy.