@Andrew This was the exact problem I was facing. The affected VMs still had the guest-tools.iso mounted in the virtual drive. Once I ejected the ISO, I was able to clear the errors and the backup jobs resumed normal operation.

For anyone else hitting this "stuck delta" or VDI_IN_USE state, here is the exact workflow I followed to resolve it:

• Shut down the VM (Essential to release all storage locks).
• Eject the ISO/CD from the VM console or CLI.
• Delete all snapshots associated with the VM (including any old or "ghost" backup snapshots).
• Delete the VM's backup folder from the remote SR/Backup target to ensure a clean metadata start.
• Monitor the Coalesce process (via SMlog) and wait for it to finish flattening the VHD chain.
• Power the VM back on.
• Manually trigger a Backup Job.

Following these steps, the first run was (as expected) a Full backup, but every subsequent run has been a successful Delta with no "hanging" snapshots left behind.

@florent PM sent with backup job log. Nothing is showing up for VDI_IN_USE in the xo-server logs. One thing I just noticed is that past two jobs have both been full backups when one should have been a full and then a delta.

Hi there,

First time poster, long time reader. I recently came across an odd problem with my Delta Backup Jobs. I have a a couple of delta backup jobs running daily backups of VMs. I have noticed that 2 of the VMs in the backup job fail to delete the old delta backup snapshot after a new one has been created. The backup job still succeeds and the next backup job runs without error but it creates a long snapshot chain that has to be manually cleaned up. I have noticed that it only seems to only effect Ubuntu 20.04 VMs if that has anything to do with it (there are two ubuntu 18 vms part of this job that seem to be deleting old delta snapshots).

Xen Orchesta Commit: commit db8ad