Uploaded image for project: 'RHEL'
  1. RHEL
  2. RHEL-89353

Block PVC is filled with zeroes during migration [rhel-9.7]

Linking RHIVOS CVEs to...Migration: Automation ...Sync from "Extern...XMLWordPrintable

    • Icon: Bug Bug
    • Resolution: Unresolved
    • Icon: Major Major
    • rhel-9.7
    • rhel-9.7
    • nbdkit
    • nbdkit-1.38.5-6.el9
    • No
    • Important
    • ZStream
    • 1
    • rhel-virt-tools
    • ssg_virtualization
    • 13
    • None
    • False
    • True
    • Hide

      None

      Show
      None
    • None
    • Virt storage Sprint8 2025-08
    • Approved Blocker
    • 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
      [...]
      

              rhn-eng-rjones Richard Jones
              rhn-support-gveitmic Germano Veit Michel
              virt-maint virt-maint
              Votes:
              0 Vote for this issue
              Watchers:
              14 Start watching this issue

                Created:
                Updated: