Base Copy / VDI not merged



  • I am facing a simmilar issue like this one https://xen-orchestra.com/forum/topic/1192/base-copy/
    I have a 900GB local SR with a single 300GB VM on it, and now my Backup fails with SR_BACKEND_FAILURE_44

    So there is a 300GB VDI and the 300GB Base Copy on that storage, so from what i understand the remaining ~260GB are NOT engough space to merge these 2 copys ?!

    xe vdi-list sr-uuid=646a7969-1ec5-66b0-e7d2-cc76a340b171
    uuid ( RO)                : b328d061-f9c0-4080-91bb-872c36fe6e76
              name-label ( RW): bitrix.np.disk1
        name-description ( RW): Disk Image
                 sr-uuid ( RO): 646a7969-1ec5-66b0-e7d2-cc76a340b171
            virtual-size ( RO): 322122547200
                sharable ( RO): false
               read-only ( RO): false
    
    
    uuid ( RO)                : ef6aa466-72ba-4430-b3d1-0fb7ddae6079
              name-label ( RW): base copy
        name-description ( RW):
                 sr-uuid ( RO): 646a7969-1ec5-66b0-e7d2-cc76a340b171
            virtual-size ( RO): 322122547200
                sharable ( RO): false
               read-only ( RO): true
    

    I have tried to use "reclaim space" on that SR, but that fails for me (and alot of others aparently) with:

    FAILED in util.pread: (rc 1) stdout: '', stderr: 'blkdiscard: /dev/VG_XenStorage-646a7969-1ec5-66b0-e7d2-cc76a340b171/646a7969-1ec5-66b0-e7d2-cc76a340b171_trim_lv: BLKDISCARD ioctl failed: Operation not supported
    

    I see alot of exceptions in SMlog:

    May  7 09:34:08 xen-01-b SM: [7866] Ignoring exception for LV check: /dev/VG_XenStorage-bb0f6287-2108-3772-928e-8048c1e8d868/bb0f6287-2108-3772-928e-8048c1e8d868_trim_lv !
    May  7 09:36:23 xen-01-b SM: [8838] Ignoring exception for LV check: /dev/VG_XenStorage-646a7969-1ec5-66b0-e7d2-cc76a340b171/646a7969-1ec5-66b0-e7d2-cc76a340b171_trim_lv !
    May  7 09:45:11 xen-01-b SM: [12626] Ignoring exception for LV check: /dev/VG_XenStorage-95ec05c5-59bd-888e-eddb-48d635b96116/95ec05c5-59bd-888e-eddb-48d635b96116_trim_lv !
    May  7 10:05:05 xen-01-b SM: [20938] Ignoring exception for LV check: /dev/VG_XenStorage-646a7969-1ec5-66b0-e7d2-cc76a340b171/b328d061-f9c0-4080-91bb-872c36fe6e76.cbtlog !
    May  7 10:05:17 xen-01-b SM: [21436] Ignoring exception for LV check: /dev/VG_XenStorage-646a7969-1ec5-66b0-e7d2-cc76a340b171/b328d061-f9c0-4080-91bb-872c36fe6e76.cbtlog !
    

    So what is the fix here ? Do i need to resize that VDI to fit 3 Times on the local storage ?



  • This is the storage in question

    4eda1f2a-6be9-4990-b50f-25cf27ebbf83-grafik.png

    d28330d6-a9ac-4a8e-88d3-f2ababee0dc8-grafik.png


  • Admin

    Hi!

    You simply don't have enough space to coalesce, due to how thick provisioning works. You should use Local ext or any other thin provisioned storage to avoid those issues.

    Larges VM disks on thick pro storage are a pain, thin will answer all your problems.



  • Well without XOA Backup working i have no other option as to shutdown and export that VM?
    I just noticed that XCP still reports "Cannot move virtual disks between local SRs" (havnt tried that for a long time).


  • Admin

    Let me rephrase: without space to coalesce (regardless XOA), your only option is indeed to shutdown it. Then, coalesce would happen (because no need for XCP/XS to make a snapshot to coalesce).

    As soon coalesce is done, you should be able to snapshot it again and to export the snapshot.

    Alternatively, you can shutdown and export/move the VM directly.



  • Oh! great, i will try that later when the server is less busy.
    Can i trigger it (coalesce) with an SR rescan ?


  • Admin

    SR rescan could help yes, and a bit of patience too 🙂



  • Damn i guess this does not work (due to insufficent space?):

    May  8 19:07:34 xen-01-b SMGC: [8597] Set vhd-blocks = eJzt2LEJgEAMhtHS0tFvFMdwHC0FA9ENDkEJeO/Vge+vs+TtzGyZkT0xdU8+tc+1/SjuH8X9tTYPAAAAAAAAAAAAAMAzrXoAADCcbfA+AAAA8H/+D++5AMbVs9Q= for *ef6aa466[VHD](300.000G//300.504G|n)
    May  8 19:07:34 xen-01-b SMGC: [8597] Num combined blocks = 153555
    May  8 19:07:34 xen-01-b SMGC: [8597] Coalesced size = 300.504G
    May  8 19:07:34 xen-01-b SMGC: [8597] Got other-config for b328d061[VHD](300.000G/242.496G/300.594G|n): {'leaf-coalesce': 'offline', 'content_id': 'c4cec5e9-e6f4-18a9-ad52-8db03ef0f2c9'}
    May  8 19:07:34 xen-01-b SMGC: [8597] No space to leaf-coalesce b328d061[VHD](300.000G/242.496G/300.594G|n) (free space: 254355177472)
    May  8 19:07:34 xen-01-b SMGC: [8597] ...but enough space if skip snap-coalesce
    May  8 19:07:34 xen-01-b SMGC: [8597] Set leaf-coalesce = offline for b328d061[VHD](300.000G/242.496G/300.594G|n)
    May  8 19:07:34 xen-01-b SMGC: [8597] Got sm-config for *ef6aa466[VHD](300.000G//300.504G|n): {'read-caching-reason-24097d1c-c678-417e-8a00-2257aee78fd2': 'SR_NOT_SUPPORTED', 'read-caching-enabled-on-24097d1c-c678-417e-8a00-2257aee78fd2': 'false', 'vdi_type': 'vhd', 'vhd-blocks': 'eJzt2LEJgEAMhtHS0tFvFMdwHC0FA9ENDkEJeO/Vge+vs+TtzGyZkT0xdU8+tc+1/SjuH8X9tTYPAAAAAAAAAAAAAMAzrXoAADCcbfA+AAAA8H/+D++5AMbVs9Q='}
    May  8 19:07:34 xen-01-b SMGC: [8597] No work, exiting
    May  8 19:07:34 xen-01-b SMGC: [8597] GC process exiting, no work left
    

    I dont fully understand that, nothing changed?!:

    May  8 19:07:34 xen-01-b SMGC: [8597] SR 646a ('Local SR R10 - 900GB') (2 VDIs in 1 VHD trees): showing only VHD trees that changed:
    May  8 19:07:34 xen-01-b SMGC: [8597]         *ef6aa466[VHD](300.000G//300.504G|n)
    May  8 19:07:34 xen-01-b SMGC: [8597]             b328d061[VHD](300.000G/242.496G/300.594G|n)
    May  8 19:07:34 xen-01-b SMGC: [8597]
    

Log in to reply