Repository navigation
Fix instance snapshots with KvmFileBasedStorageVmSnapshotStrategy - #14515
sureshanaparti wants to merge 2 commits into
Conversation
There was a problem hiding this comment.
Warning
Copilot couldn't run its full agentic review because it didn't start before the timeout. Make sure your repository has a runner available, or add a copilot-code-review.yml file specifying one with the runs-on attribute. See the docs for more details.
Copilot review overview
6 open issues
The new metadata-only deletion path is selected solely based on the absence of… · New The new metadata-only deletion path is selected solely based on the absence of… · New Given the new branching around ‘volume snapshot details’ vs ‘strategy marker’, it would be valuable… · New The tests introduced several string literals for snapshot detail keys… · New The tests introduced several string literals for snapshot detail keys… · New The tests introduced several string literals for snapshot detail keys… · New
What changed in this PR
Fixes KVM file-based VM snapshot lifecycle issues where failed snapshot creates could leave unclaimed Error rows and block instance deletion, by tagging snapshots early and adjusting handling/deletion behavior.
Changes:
- Persist a strategy marker detail early during snapshot creation so later
Errorrows are still recognized by this strategy. - Relax
canHandle()logic to claim snapshots based on either volume-snapshot details or the new strategy marker, with an eligibility fallback for legacyErrorrows. - Add a “metadata-only” deletion path for snapshots that never recorded volume snapshot details.
| File | Description |
|---|---|
| engine/storage/snapshot/src/main/java/org/apache/cloudstack/storage/vmsnapshot/KvmFileBasedStorageVmSnapshotStrategy.java | Adds strategy marker persistence, updates canHandle(), and introduces metadata-only deletion for detail-less snapshots. |
| engine/storage/snapshot/src/test/java/org/apache/cloudstack/storage/vmsnapshot/KvmFileBasedStorageVmSnapshotStrategyTest.java | Adds unit tests for strategy marker persistence, updated canHandle() behavior, and metadata-only deletion behavior. |
Review effort: Lite
| public boolean deleteVMSnapshot(VMSnapshot vmSnapshot) { | ||
| logger.info("Starting VM snapshot delete process for snapshot [{}].", vmSnapshot.getUuid()); | ||
| UserVmVO userVm = userVmDao.findById(vmSnapshot.getVmId()); | ||
| VMSnapshotVO vmSnapshotBeingDeleted = (VMSnapshotVO) vmSnapshot; | ||
| if (!hasVolumeSnapshotDetails(vmSnapshotBeingDeleted)) { | ||
| return deleteVMSnapshotWithoutVolumeSnapshots(vmSnapshotBeingDeleted); | ||
| } | ||
|
|
||
| UserVmVO userVm = userVmDao.findById(vmSnapshot.getVmId()); | ||
| Long hostId = pickHostForNvramSidecarCleanup(vmSnapshotBeingDeleted, userVm, "delete"); | ||
| validateHostSupportsNvramSidecarCleanup(vmSnapshotBeingDeleted, hostId, "delete"); |
| protected boolean hasVolumeSnapshotDetails(VMSnapshot vmSnapshot) { | ||
| return CollectionUtils.isNotEmpty(vmSnapshotDetailsDao.findDetails(vmSnapshot.getId(), KVM_FILE_BASED_STORAGE_SNAPSHOT)); | ||
| } |
| public StrategyPriority canHandle(VMSnapshot vmSnapshot) { | ||
| if (!VMSnapshot.State.Allocated.equals(vmSnapshot.getState())) { | ||
| List<VMSnapshotDetailsVO> vmSnapshotDetails = vmSnapshotDetailsDao.findDetails(vmSnapshot.getId(), KVM_FILE_BASED_STORAGE_SNAPSHOT); | ||
| if (CollectionUtils.isEmpty(vmSnapshotDetails)) { | ||
| VMSnapshot.State state = vmSnapshot.getState(); | ||
| if (!VMSnapshot.State.Allocated.equals(state)) { | ||
| if (hasVolumeSnapshotDetails(vmSnapshot) || isCreatedByThisStrategy(vmSnapshot)) { | ||
| return StrategyPriority.HIGHEST; | ||
| } | ||
| if (!VMSnapshot.State.Error.equals(state)) { | ||
| logger.debug("KVM file based storage VM snapshot strategy cannot handle [{}] as it is not a KVM file based storage VM snapshot.", | ||
| vmSnapshot.getUuid()); | ||
| return StrategyPriority.CANT_HANDLE; | ||
| } | ||
| return StrategyPriority.HIGHEST; | ||
| // Error rows created before the strategy marker existed carry no detail at all; fall back to the creation eligibility check. | ||
| logger.debug("VM snapshot [{}] is in Error state without any KVM file based storage details; checking whether this strategy would have created it.", | ||
| vmSnapshot.getUuid()); | ||
| } |
|
|
||
| InOrder inOrder = inOrder(vmSnapshotHelper, vmSnapshotDetailsDao); | ||
| inOrder.verify(vmSnapshotHelper).vmSnapshotStateTransitTo(vmSnapshot, VMSnapshot.Event.CreateRequested); | ||
| inOrder.verify(vmSnapshotDetailsDao).addDetail(vmSnapshotId, "kvmFileBasedStorageSnapshotStrategy", Boolean.TRUE.toString(), false); |
| when(vmSnapshotDetailsDao.findDetails(20L, "kvmFileBasedStorageSnapshot")) | ||
| .thenReturn(List.of(new VMSnapshotDetailsVO(20L, "kvmFileBasedStorageSnapshot", "30", true))); |
| when(vmSnapshotDetailsDao.findDetail(20L, "kvmFileBasedStorageSnapshotStrategy")) | ||
| .thenReturn(new VMSnapshotDetailsVO(20L, "kvmFileBasedStorageSnapshotStrategy", Boolean.TRUE.toString(), false)); |
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## 4.22 #14515 +/- ##
============================================
+ Coverage 18.31% 18.32% +0.01%
- Complexity 16633 16652 +19
============================================
Files 5939 5939
Lines 537748 537772 +24
Branches 65924 65927 +3
============================================
+ Hits 98472 98558 +86
+ Misses 428070 428003 -67
- Partials 11206 11211 +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:
|
|
@blueorangutan package |
|
@sureshanaparti 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 19803 |
| if (!VMSnapshot.State.Error.equals(state)) { | ||
| logger.debug("KVM file based storage VM snapshot strategy cannot handle [{}] as it is not a KVM file based storage VM snapshot.", | ||
| vmSnapshot.getUuid()); | ||
| return StrategyPriority.CANT_HANDLE; | ||
| } | ||
| return StrategyPriority.HIGHEST; | ||
| // Error rows created before the strategy marker existed carry no detail at all; fall back to the creation eligibility check. | ||
| logger.debug("VM snapshot [{}] is in Error state without any KVM file based storage details; checking whether this strategy would have created it.", | ||
| vmSnapshot.getUuid()); |
There was a problem hiding this comment.
I'm not sure this fallback is good approach. Aren't the other changes enough?
My fear is that we eventually try to operate a VM snapshot which is not from this strategy.



Description
This PR fixes the instance snapshots with KvmFileBasedStorageVmSnapshotStrategy.
KvmFileBasedStorageVmSnapshotStrategy.canHandle() rejected any snapshot past Allocated that lacked the kvmFileBasedStorageSnapshot detail, but that detail is only persisted after a successful create. A failed create (e.g. quiescevm=true on a guest without a running agent) therefore left an Error row no strategy would claim once DefaultVMSnapshotStrategy was excluded. deleteVMSnapshot then failed, and deleteAllVMSnapshots made destroyVirtualMachine fail too, leaving the instance undeletable.
The strategy now tags every snapshot it starts creating with a kvmFileBasedStorageSnapshotStrategy detail, so it recognises its own rows in any later state regardless of whether the VM is still eligible for disk-only snapshots. Error rows that predate the marker fall back to the creation eligibility check.
Deleting a row that never recorded volume snapshots only removes its metadata: nothing reached primary storage and no create usage events were published, so no host command or delete usage events are issued.
Fixes #14481
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?