Base Copy / VDI not merged

Meth0d

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 ?

Meth0d

This is the storage in question

olivierlambert

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.

Meth0d

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).

olivierlambert

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.

Meth0d

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

olivierlambert

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

Meth0d

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]