Remove volume size check in restoreBackupToVM #11384
Conversation
|
@blueorangutan package |
|
@abh1sar a [SL] Jenkins job has been kicked to build packages. It will be bundled with KVM, XenServer and VMware SystemVM templates. I'll keep you posted as I make progress. |
|
Packaging result [SF]: ✔️ el8 ✔️ el9 ✔️ debian ✔️ suse15. SL-JID 14533 |
| vmVolume.getSize(), vmVolume.getUuid(), backupVolume.getSize(), backupVolume.getUuid())); | ||
| } | ||
| index++; | ||
| } |
There was a problem hiding this comment.
@abh1sar new volumes restored will have backed-up volumes size, correct? should we update any disk offering for the new size?
There was a problem hiding this comment.
Users can configure a different disk offering, or a larger size in case of custom disk offering.
Only limitation is that the volume size should not be less than the backed-up volume size.
If not configured, the volume will use the same disk offering and size as the backed-up volume.
So, nothing to configure at this point.
rajujith
left a comment
rajujith
left a comment
There was a problem hiding this comment.
LGTM.
Tested.
Created a volume of size 5gb in 4.20
Created an instance with root disk size 20GB in 4.20
Attached the data volume to the Instance
Take a NAS backup
Upgraded to 4.21
Created new instances from the backup
github-project-automation
bot
moved this from In Progress
to Done
in Apache CloudStack 4.21.0
4 participants
Description
This PR fixes #11383
PR #11258 addressed a bug in backup restore where the data disk was created before the root disk. As part of the fix, it ensured that the list of backed-up volumes stored in the backup table is sorted by deviceId (rather than the id from the volumes table), and also re-sorted the volumes by deviceId during restore to correctly align with the backed-up volume paths.
In the “Create new instance from backup” feature, the new instance is provisioned using the volumes listed in the backup metadata. Starting with version 4.21, these volumes are sorted by deviceId. However, in 4.20, there may be backups where the data volume appears before the root volume. When such a backup is used after upgrading to 4.21, the volume size comparison after instance creation fails because:
• The root volume is always allocated first during instance creation.
• This results in volumeDao.findByInstance(vmId) returning volumes with root volume first.
• But in the older backup metadata (4.20), the data volume appears first.
• This mismatch causes a false failure in the post-creation volume size check.
Importantly, this issue does not affect the actual restore process, since volumes are re-sorted by deviceId before restore. Also, a volume size check is already performed in allocateVMFromBackup (before Instance creation) — where the order matches the backup data — and it passes correctly there.
Types of changes
Feature/Enhancement Scale or Bug Severity
Feature/Enhancement Scale
Bug Severity
Screenshots (if appropriate):
Before fix :
How Has This Been Tested?
How did you try to break this feature and the system with this change?