Has anyone successfully exported a disk that has 4096 sectors

Apps and Virtualization
1

I am running Trune nas v25.20 and all of the exports of my disks with 4096 sectors will not work when i attach them in another system (TrueNAS or Windows based QEMU), the disks appear corrupt.

Any that have 512 sectors work. I have not extensively checked the disk contents but the VMs boot an appear healthy.

Not all disks images will accept 4096 sectors. The following should so only these should be considered. Exporting has been restricted in newer versions (NAS-143506)

  • RAW
  • QWCOW2
  • QED (I think)
  • VHDX (does accept 4096 but the export for this is definitely broken, fixed in V26 on github)

On my 26.0.0-BETA.3 I created an Ubuntu server, used 4096 sectors, exported the disk image and then used that image as a Raw file and that worked. On this VM I did use AHCI from the beginning, but on my VMs only my live server I used Virtio

Anyone got any similar experiences?

I am trying to track down if this is a bug that is on v25 and now fixed on v26 or if I am doing something wrong.

thanks

2

Aren’t you just testing QEMU capabilities on import and export? TrueNAS is basically Debian. Have you tried comparing or checking the QEMU versions. Are you able to import and export on those other systems?

3

Nope :smiley: , it depends how the inputs and outputs are provided to qemu-img I have already reported one glaring bug in regards to this.

V25 uses qemu-img 10.0.0 and v26 uses qemu-img 10.0.2

  • If I export a zvol as a raw file on v26 and it will work as expected on v26 as a RAW file device, so i can ignore the import conversion.
  • If I export a zvol as a raw file on v25 and it will work as expected on v25 as a RAW file device, so i can ignore the import conversion.
  • If I take that drive from V25 and try and use it on v26 it appears corrupt and will not work. I have also inspected it with DiskGenius.
4

Just incase anyone is interested

Disk images exported from zvols cannot be moved from v25.10 to a v26-Beta-3

5

I found the bug and it has been confirmed by the AI.

Disk sector size sets both physical_block_size and logical_block_size , but in TN v26-beta-3 only the physical_block_size is set causing logical_block_size to default to 512 sectors.

So if you have any VMs using 4096 sectors, do not upgrade until this is fixed.

6

This bug has been Closed Without Changes by the AI, so this will not be fixed.

So like feature requests, bugs reports apparently are also luck of the draw.

For me, this is an upgrade blocker

TL;DR

  • Anyone who has a VM that uses 4096 sectors on V25 (or lower) will fail to boot and will never work on v26.
  • Disk sector size no longer controls logical sector size so you can only ever make 512/512e disks, or only load disks that have a 512 sectors.
  • Because logical_sector_size is not defined in the QEMU (Virtual Machine) start command, logical sector sizes default to 512.
  • Logical sector configuration is much more important that physical sector.

I hope this gets fixed otherwise I am stuck on v25.10

If anyone else has chance and also want to verify this issue and post results here that might be useful.

7

Team is having a look at this issue.

Thanks,
Patrick

8

@patrickkeane There is no details on what was or was not done, but after interrogating the AI it is implying that there was a fix applied to 26.0.0-RC.1, 27.0.0-BETA.1 but the changes might be internal so I will never see them.

  • I dont need the explicit fixes, just that the bug was found and has been addressed or that I am bonkers :smiley:
  • I mentioned this to your colleague (full disclosure :smiley: ) , maybe in the JIRA small notes on closing what the out come of a bug report would be nice. Just along the lines of, bug found, bug fixed or no bug found, closed.

thanks again for looking at this.

9

It is fixed and will be present in upcoming RC.1 release.

10

awesome.

I will have to search the whole truenas GitHub next time :smiley: , i was looking in middleware.

11

The Fix Versions field on the bug tracker in right hand column is a reliable way to know if there is a PR for the issue, and which versions will have a fix applied.

Thanks,

Patrick

12

But then the status of the jira ticket is/was a bit missleading, when i looked this morning, german time, the status was, as shoulders wrote, “closed without changes”, now the status is “done”…

13

@LarsR

  • I agree the JIRA statuses are not clear. I work with GitHub and you can easily see.
  • This has literally been done in the last hour (thanks TN team).
  • The title was the symptom rather that the cause
  • The cause was unexpected, however on a plus, I think the VM backend has been recooked.
  • It has been a journey :smiley: