Backup restore of VM fails after ROOT volume migration (wrong disk id used) #12517

problem

Restoring a virtual machine from a backup fails if the VM’s ROOT volume has been migrated to another primary storage.
After migration, the ROOT volume’s identifiers in the database change (disk id and path id), but the backup restore process still tries to use the old disk id in the file name, which no longer exists on disk.
If a symbolic link is created from the actual qcow2 file (with the new path id) to the expected file name (with the old disk id), the restore completes successfully.

versions

Apache CloudStack version: 4.21.0.0

Hypervisor: KVM

Storage Type: NFS

VM state during restore: Stopped

Backup type: VM backup with ROOT-disk

The steps to reproduce the bug

Steps to Reproduce

1. Create a virtual machine.

2. Create a ROOT volume for this VM on one primary storage.

3. Migrate the ROOT volume to another primary storage.

4. Observe that in the database the ROOT volume identifiers change, for example:

   disk_id = 6e75d391-9368-4a1e-ad9d-ba53eb37721c

   path_id = f9f56997-8dee-4dab-b497-db7594dc9df5

5. Try to restore the VM from a backup.

6. Check the KVM/agent logs on the host performing the restore.

Observed Behavior

During restore, the system runs a command similar to:

/bin/bash -c rsync -az \
/usr/share/cloudstack-agent/tmp/csbackup.DpswS6644565578867592234/i-280-1642-VM/2026.01.26.15.07.27/root.6e75d391-9368-4a1e-ad9d-ba53eb37721c.qcow2 \
/mnt/e99ab53f-5b3a-36b6-ab01-86725eb45d4b/4f070e46-9b54-42d4-8b79-42a58edf5197

In this directory, the file root.6e75d391-9368-4a1e-ad9d-ba53eb37721c.qcow2 does not exist, but the file root.f9f56997-8dee-4dab-b497-db7594dc9df5.qcow2 is present.

The backup restore process fails with an error similar to:

VM: {'errorcode': 533, 'errortext': 'No destination found for a deployment for VM instance {"id":1577,"instanceName":"i-280-1577-VM","state":"Stopped","type":"User","uuid":"1421efbe-76a5-4f74-ab67-9e40385bcf88"}'}

If, before the restore proceeds, you manually create a hard link in:

/usr/share/cloudstack-agent/tmp/csbackup.DpswS6644565578867592234/i-280-1642-VM/2026.01.26.15.07.27/

like this

ln root.f9f56997-8dee-4dab-b497-db7594dc9df5.qcow2 \
   root.6e75d391-9368-4a1e-ad9d-ba53eb37721c.qcow2

then the restore from backup completes successfully.

Expected Behavior

The backup restore process should use the correct, current identifier of the ROOT volume file (e.g., the path_id-based file name) after volume migration, without requiring manual hard links or any manual intervention.

What to do about it?

No response