kvm: delete primary-only RBD snapshots before the volume - #14132
kvm: delete primary-only RBD snapshots before the volume#14132weizhouapache wants to merge 1 commit into
Conversation
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## 4.22 #14132 +/- ##
=========================================
Coverage 17.93% 17.93%
- Complexity 16140 16149 +9
=========================================
Files 5928 5928
Lines 535174 535194 +20
Branches 65494 65497 +3
=========================================
+ Hits 95968 96007 +39
+ Misses 428280 428256 -24
- Partials 10926 10931 +5
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:
|
|
@weizhouapache I see.. so your changes only run this for KVM + Ceph volumes, and it sits in the volume delete path instead of the storage cleanup loop. That fills the gap I had. Mine was running on every volume expunge no matter the storage type. I guess I will go ahead and close mine: #12813 |
Fixes apache#12002. On Ceph/RBD primary storage, deleting a volume also destroys any of its remaining snapshots: LibvirtStorageAdaptor#deleteVol passes VIR_STORAGE_VOL_DELETE_WITH_SNAPSHOTS for RBD pools, so libvirt unprotects and removes them along with the image. Run that same snapshots cleanup earlier: for a KVM + RBD volume, delete its primary-only snapshots before sending the volume delete command, while they can still be found and removed cleanly. This is the choke point shared by both the standalone DeleteVolume API and VM destroy/expunge, so it covers both affected flows. The existing post-delete cleanup in deleteVolumeCallback stays in place as a no-op safety net for anything this pass didn't find. Verified live on a KVM + Ceph environment (RBD primary storage, snapshot.backup.to.secondary=false): destroying a VM with a primary-only snapshot now deletes it cleanly.
19944a4 to
f720421
Compare
|
@blueorangutan package |
|
@weizhouapache 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 ✔️ el10 ✔️ debian ✔️ suse15. SL-JID 19222 |
|
@blueorangutan test |
|
@weizhouapache a [SL] Trillian-Jenkins test job (ol8 mgmt + kvm-ol8) has been kicked to run smoke tests |
|
[SF] Trillian test result (tid-16978)
|
Description
This PR fixes #12002
On Ceph/RBD primary storage, deleting a volume also destroys any of its remaining snapshots: LibvirtStorageAdaptor#deleteVol passes VIR_STORAGE_VOL_DELETE_WITH_SNAPSHOTS for RBD pools, so libvirt unprotects and removes them along with the image.
Run that same snapshots cleanup earlier: for a KVM + RBD volume, delete its primary-only snapshots before sending the volume delete command, while they can still be found and removed cleanly. This is the choke point shared by both the standalone DeleteVolume API and VM destroy/expunge, so it covers both affected flows. The existing post-delete cleanup in deleteVolumeCallback stays in place as a no-op safety net for anything this pass didn't find.
Verified live on a KVM + Ceph environment (RBD primary storage, snapshot.backup.to.secondary=false): destroying a VM with a primary-only snapshot now deletes it cleanly.
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?