Fix NAS backup filename for legacy LINSTOR path - #13538
Conversation
|
Congratulations on your first Pull Request and welcome to the Apache CloudStack community! If you have any issues or are unsure about any anything please check our Contribution Guide (https://github.com/apache/cloudstack/blob/main/CONTRIBUTING.md)
|
There was a problem hiding this comment.
Pull request overview
Fixes CloudStack KVM NAS backup filename generation for legacy LINSTOR VMs whose live libvirt XML still references raw /dev/drbdNNNN device nodes, ensuring backups use the expected UUID-based naming so restores can locate the correct qcow2 files.
Changes:
- Add
get_linstor_uuid_from_device()to map raw DRBD device nodes back to a LINSTOR volume UUID via udev symlinks. - Apply the raw-DRBD handling consistently in the running-VM XML generation loop, the post-backup sparsify loop, and the stopped-VM convert loop.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## 4.22 #13538 +/- ##
============================================
- Coverage 17.67% 17.67% -0.01%
+ Complexity 15797 15793 -4
============================================
Files 5923 5923
Lines 533349 533349
Branches 65248 65248
============================================
- Hits 94253 94252 -1
Misses 428437 428437
- Partials 10659 10660 +1
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
rp-
left a comment
There was a problem hiding this comment.
yes, I agree to the copilot suggestions, they make sense
When backing up a running VM, nasbackup.sh derives the backup filename from the disk source path reported by libvirt. VMs started before the switch to /dev/drbd/by-res/ paths still carry the raw DRBD device node (e.g. /dev/drbd1098) in their live domain XML, which fell into the basename fallback and produced root.drbd1098.qcow2 instead of root.<volume-uuid>.qcow2. Restore always expects the UUID-based name, so these backups could not be restored until the VM was stopped and started. Resolve raw /dev/drbdNNNN device nodes back to the volume UUID by asking udev for the device's /dev/drbd/by-res/cs-<uuid> symlink. Apply the same handling in all three backup loops (running-VM XML build, sparsify, and stopped-VM convert). Signed-off-by: Moritz Tanner <moritz.tanner@linbit.com>
4e6ee49 to
5c5ac0a
Compare
|
Maybe @sbrueseke can help with testing, as they have been the initial starter for this change. |
|
It is not possible for me to test this at the moment, because we do not have any stage system which has instances/backups in this state. |
|
Awesome work, congrats on your first merged pull request! |
| exit 1 | ||
| fi | ||
| else | ||
| name="datadisk" |
There was a problem hiding this comment.
although this PR has been merged, I am curious why line 209 is added.
name="datadisk"
@WanzenBug
could you explain ?
There was a problem hiding this comment.
This fixes a pre-existing filename mismatch, if the first disk would be a non Linstor disk, it would keep root for the next Linstor disk instead of datadisk.
Anyway, a prepared PR, will change this again and the qemu-img convert will not be necessary anymore, but I have to wait until #13877 is merged.
There was a problem hiding this comment.
I am merging 4.22 branch to main branch, and will create 4.23.0.0-RC3
I would suggest to revert this PR. otherwise, 4.23.0.0 will have incomplete changes
There was a problem hiding this comment.
It isn't incomplete and fixes the transition from old volumes to new naming.
But if it helps with the 4.23.0.0 release, go ahead, I wasn't aware my merge would intervene with that...
There was a problem hiding this comment.
thanks @rp-
since you think it is not incomplete, let's leave as it is
Description
When backing up a running VM, nasbackup.sh derives the backup filename from the disk source path reported by libvirt. VMs started before the switch to /dev/drbd/by-res/ paths still carry the raw DRBD device node (e.g. /dev/drbd1098) in their live domain XML, which fell into the basename fallback and produced root.drbd1098.qcow2 instead of root..qcow2. Restore always expects the UUID-based name, so these backups could not be restored until the VM was stopped and started.
Resolve raw /dev/drbdNNNN device nodes back to the volume UUID by asking udev for the device's /dev/drbd/by-res/cs- symlink. Apply the same handling in all three backup loops (running-VM XML build, sparsify, and stopped-VM convert).
Types of changes
Feature/Enhancement Scale or Bug Severity
Feature/Enhancement Scale
Bug Severity
Screenshots (if appropriate):
How Has This Been Tested?
How did you try to break this feature and the system with this change?