| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
Sorry, something went wrong.
…up restore Script.executeCommand returns null when the command fails, it does not throw, so the try/catch around the mount and umount of the backup repository could never fire and the return value was discarded. A repository that fails to mount was therefore treated as mounted, and the restore carried on against an empty directory until it failed later with a misleading "backup file not found". A failed umount was ignored the same way, leaking the mount. Both now go through executeCommandForExitValue and check the exit value. The same refactor also dropped the timeouts. mountTimeout was still passed into mountBackupDirectory but never used, and the rsync of the volume lost the command timeout, so both fell back to the one hour default in Script instead of the configured values. An unresponsive repository could hold a restore up for an hour rather than failing after nas.backup.restore.mount.timeout seconds.
Codecov Report❌ Patch coverage is 75.00000% with 3 lines in your changes missing coverage. Please review.
@@ Coverage Diff @@
## 4.22 #14006 +/- ##
=========================================
Coverage 17.79% 17.79%
- Complexity 15995 15998 +3
=========================================
Files 5928 5928
Lines 534306 534315 +9
Branches 65383 65385 +2
=========================================
+ Hits 95069 95087 +18
+ Misses 428467 428457 -10
- Partials 10770 10771 +1
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Harness.
|
Sorry, something went wrong.
|
@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. |
Sorry, something went wrong.
|
Packaging result [SF]: ✔️ el8 ✔️ el9 ✔️ el10 ✔️ debian ✔️ suse15. SL-JID 19015 |
Sorry, something went wrong.
There was a problem hiding this comment.
This PR fixes restore-from-backup behavior for KVM/libvirt by correctly treating failed mount/umount operations as failures (via exit codes instead of relying on exceptions) and by restoring the intended command timeouts so restores don’t hang for Script’s 1-hour default.
Changes:
Copilot reviewed 2 out of 2 changed files in this pull request and generated 3 comments.
| File | Description |
|---|---|
| plugins/hypervisors/kvm/src/main/java/com/cloud/hypervisor/kvm/resource/wrapper/LibvirtRestoreBackupCommandWrapper.java | Validates mount/umount exit codes and restores rsync timeout usage during restore operations. |
| plugins/hypervisors/kvm/src/test/java/com/cloud/hypervisor/kvm/resource/wrapper/LibvirtRestoreBackupCommandWrapperTest.java | Updates mocks for timeout-aware executeCommandForExitValue and adds a test asserting the configured mount timeout is used. |
plugins/hypervisors/kvm/src/test/java/com/cloud/hypervisor/kvm/resource/wrapper/LibvirtRestoreBackupCommandWrapperTest.java:605
if (Arrays.stream(invocation.getArguments()).map(String::valueOf).anyMatch("mount"::equals)) {
mountTimeout[0] = invocation.getArgument(0);
return 1; // stop the restore right after the mount
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
Sorry, something went wrong.
| if (exitValue != 0) { | ||
| logger.error("Failed to mount repository {} of type {} to the directory {}, mount exited with {}", backupRepoAddress, | ||
| backupRepoType, mountDirectory, exitValue); | ||
| throw new CloudRuntimeException("Failed to mount the backup repository on the KVM host"); | ||
| } |
| String umountPath = Script.getExecutableAbsolutePath("umount"); | ||
| String[] umountCmd = new String[] { "sudo", umountPath, backupDirectory }; | ||
| Script.executeCommand(umountCmd); | ||
| exitValue = Script.executeCommandForExitValue(umountCmd); | ||
| } catch (Exception e) { |
| if (Arrays.stream(invocation.getArguments()).map(String::valueOf).anyMatch("rsync"::equals)) { | ||
| return 1; // Rsync failure |
| Back | FazBrowse Home | New Git URL |
Description
Script.executeCommand returns null when the command fails, it does not throw, so the try/catch around the mount and umount of the backup repository could never fire and the return value was discarded.
A repository that fails to mount was therefore treated as mounted, and the restore carried on against an empty directory until it failed later with a misleading "backup file not found". A failed umount was ignored the same way, leaking the mount. Both now go through executeCommandForExitValue and check the exit value.
The same refactor also dropped the timeouts. mountTimeout was still passed into mountBackupDirectory but never used, and the rsync of the volume lost the command timeout, so both fell back to the one hour default in Script instead of the configured values. An unresponsive repository could hold a restore up for an hour rather than failing after nas.backup.restore.mount.timeout seconds.
This is a regression from 56ad044
Types of changes
Feature/Enhancement Scale or Bug Severity
Feature/Enhancement Scale
Bug Severity
Screenshots (if appropriate):
How Has This Been Tested?
Verified that restore fails after the specified nas.backup.restore.mount.timeout with a dead address.
How did you try to break this feature and the system with this change?