calvix commented on code in PR #13922:
URL: https://github.com/apache/cloudstack/pull/13922#discussion_r4260850523
##########
plugins/hypervisors/kvm/src/main/java/com/cloud/hypervisor/kvm/resource/wrapper/LibvirtRestoreBackupCommandWrapper.java:
##########
@@ -127,11 +129,38 @@ private void
restoreVolumesOfExistingVM(KVMStoragePoolManager storagePoolMgr, Li
String backupPath, List<String>
backupFiles, String mountDirectory, int timeout, Integer mountTimeout) {
String diskType = "root";
try {
- for (int idx = 0; idx < restoreVolumePaths.size(); idx++) {
- PrimaryDataStoreTO restoreVolumePool =
restoreVolumePools.get(idx);
- String restoreVolumePath = restoreVolumePaths.get(idx);
- String backupFile = backupFiles.get(idx);
+ // Match each backed up volume to the instance's volume with the
SAME UUID. Both lists
+ // arrive ordered by device id, but device ids are not stable
across restores, so relying
+ // on the position within the list can write a backup into a
different volume than the one
+ // it was taken from.
+ Map<String, Integer> targetIndexByVolumeUuid = new HashMap<>();
+ for (int i = 0; i < restoreVolumePaths.size(); i++) {
+
targetIndexByVolumeUuid.put(getVolumeUuidFromPath(restoreVolumePaths.get(i),
restoreVolumePools.get(i)), i);
Review Comment:
> what happens if a disk's file name on storage isnt the same as its id,
like after it was moved to another pool? looks like the match fails here and
the restore stops saying the disk is no longer attached
Sorry for the late reply. You seem to have caught a potential bug. I will
wire fix in short.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
