If a disk / VDI is orphaned or only partially deleted you’ll notice that under the SR it’s not assigned to any VM.
This can cause issues that look like metadata corruption resulting in the inability to migrate VMs or edit storage.
For example:
[root@xenserver-host ~]# xe vdi-destroy uuid=6c2cd848-ac0e-441c-9cd6-9865fca7fe8b
Error code: SR_BACKEND_FAILURE_181
Error parameters: , Error in Metadata volume operation for SR. [opterr=VDI delete operation failed for parameters:
  /dev/VG_XenStorage-3ae1df17-06ee-7202-eb92-72c266134e16/MGT, 6c2cd848-ac0e-441c-9cd6-9865fca7fe8b.
  Error: Failed to write file with params [3, 0, 512, 512]. Error: 5],
Removing stale VDIs
To fix this, you need to remove those VDIs from the SR after first deleting the logical volume:

Sam McLeod

When a VDI (Virtual Disk Image) in XenServer becomes orphaned or only partially deleted, it can cause SR metadata corruption errors that prevent VM migration or storage edits. The fix involves two steps: first, remove the stale VDI by locating and deleting its logical volume with lvremove, then destroying it via xe vdi-destroy. If the SR still has metadata issues, the MGT (management volume) may be corrupt and can be rebuilt by renaming the existing MGT LV and rescanning the SR, which forces XenServer to regenerate it without requiring VMs to be powered off.

Fix XenServer SR with corrupt or invalid metadata