-
Bug
-
Resolution: Unresolved
-
Major
-
rhel-10.1
-
nbdkit-1.44.1-2.el10
-
No
-
Important
-
1
-
rhel-virt-tools
-
ssg_virtualization
-
14
-
None
-
False
-
True
-
-
None
-
Virt storage Sprint8 2025-08
-
Unspecified
-
Unspecified
-
Unspecified
-
None
Scenario:
- Migrating from vSphere 8.0.3 to OCP 4.18.10 using MTV 2.8.2
- Destination volume is Block
- Using VDDK or not makes no difference
- Reproduced on actual SAN (by Pure Storage/Portworx) but also on our own LVMS (see below)
Problem:
- The destination PVC is filled with zeroes even unnallocated blocks are correctly queried and not transfered from VMware.
- This fills up the SAN/Storage unnecessarily during conversions
Details:
1. VM is RHEL9 with single 32G disk (about 2G used), on vSphere. VMFS6, lazy zeroed.
2. MTV using destination storage class from LVMS (LVM Operator, which does Thin LVM)
3. Before conversion starts, just after volume e80d0c7d-3f51-45b2-bb29-1a5a02948f99 is allocated (32G), data usage on the LV is zero as expected:
# lvs LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert e80d0c7d-3f51-45b2-bb29-1a5a02948f99 vg1 Vwi-aotz-- 32.00g thin-pool-1 0.00 thin-pool-1 vg1 twi-aotz-- <179.82g 0.00 10.43
4. Conversion ends, with the LV fully inflated. But on VMware it uses just over 2G...
# lvs LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert e80d0c7d-3f51-45b2-bb29-1a5a02948f99 vg1 Vwi-aotz-- 32.00g thin-pool-1 100.00 thin-pool-1 vg1 twi-aotz-- <179.82g 17.80 15.95
5. If I power up the Guest and do a fstrim -a, it will discard all those zeroed blocks. This is what it should have been after conversion, ideally.
# lvs LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert e80d0c7d-3f51-45b2-bb29-1a5a02948f99 vg1 Vwi-aotz-- 32.00g thin-pool-1 12.86 thin-pool-1 vg1 twi-aotz-- <179.82g 2.29 11.15
----------
From v2v logs, its just getting the used blocks.
... nbdkit: debug: VDDK call: VixDiskLib_FreeBlockList (block_list) nbdkit: debug: VDDK call: VixDiskLib_QueryAllocatedBlocks (handle, 18816 sectors, 128 sectors, 128 sectors) nbdkit: debug: VDDK call: VixDiskLib_FreeBlockList (block_list) nbdkit: debug: VDDK call: VixDiskLib_QueryAllocatedBlocks (handle, 1231872 sectors, 1024 sectors, 128 sectors) ...
fstrim is done as well:
/sysroot/: 26.6 GiB (28550275072 bytes) trimmed /sysroot/: 743.1 MiB (779173888 bytes) trimmed /sysroot/: 591.8 MiB (620523520 bytes) trimmed
But this test failed (only when on block)
nbdkit: file[1]: debug: extents disabled: lseek: SEEK_HOLE: Invalid argument
----------
NOTE: the same problem does not exist on Filesystem type PVC
Do the same conversion of the same guest, but to a file PVC and I get the expected results after conversion. See it uses just 2.1G (so about 6.5%)
The error above is also not present in this case.
# du -h disk.img 2.1G disk.img # ls -lh disk.img -rw-rw----. 1 107 107 32G Apr 28 21:29 disk.img # filefrag -v disk.img Filesystem type is: 58465342 File size of disk.img is 34359738368 (8388608 blocks of 4096 bytes) ext: logical_offset: physical_offset: length: expected: flags: 0: 0.. 0: 280.. 280: 1: 1: 256.. 256: 536.. 536: 1: 2: 260.. 261: 540.. 541: 2: 3: 410.. 411: 690.. 691: 2: 4: 512.. 559: 792.. 839: 48: unwritten 5: 560.. 1769: 840.. 2049: 1210: 6: 1782.. 2357: 2062.. 2637: 576: 7: 2363.. 2365: 2643.. 2645: 3: 8: 2368.. 2559: 2648.. 2839: 192: unwritten 9: 153856.. 153861: 154136.. 154141: 6: 10: 153866.. 153867: 154146.. 154147: 2: 11: 153870.. 156159: 154150.. 156439: 2290: 12: 156160.. 156415: 156441.. 156696: 256: 156440: 13: 156416.. 157201: 156698.. 157483: 786: 156697: 14: 157248.. 157439: 157530.. 157721: 192: unwritten 15: 157952.. 157959: 158234.. 158241: 8: unwritten 16: 157960.. 168297: 158242.. 168579: 10338: 17: 168320.. 168447: 168602.. 168729: 128: unwritten 18: 169216.. 169346: 169498.. 169628: 131: unwritten 19: 169347.. 211070: 169629.. 211352: 41724: 20: 211072.. 211199: 211354.. 211481: 128: unwritten 21: 219392.. 219397: 219674.. 219679: 6: 22: 219406.. 219406: 219688.. 219688: 1: 23: 219408.. 219417: 219690.. 219699: 10: 24: 219456.. 219647: 219738.. 219929: 192: unwritten 25: 284928.. 285475: 285210.. 285757: 548: 26: 285476.. 285729: 285758.. 286011: 254: unwritten 27: 301312.. 301327: 301594.. 301609: 16: unwritten [...]
- clones
-
RHEL-89353 Block PVC is filled with zeroes during migration [rhel-9.7]
-
- Release Pending
-
- links to
-
RHBA-2025:148054 nbdkit bug fix and enhancement update