github-actions[bot] commented on issue #13972:
URL: https://github.com/apache/cloudstack/issues/13972#issuecomment-5426767520

   ## ๐ŸŽฏ Triage report
   
   Failed disk-only Instance Snapshots on stopped KVM VMs using RAW/RBD (Ceph) 
primary storage cannot be deleted, because deletion falls back to 
`DefaultVMSnapshotStrategy` and the KVM agent's 
`LibvirtDeleteVMSnapshotCommandWrapper` requires a live libvirt domain โ€” which 
doesn't exist for a stopped VM. This also blocks VM destruction 
(`orchestrateDeleteAllVMSnapshots()` fails). A well-documented workaround 
(start VM, delete snapshot, stop/destroy VM) exists but shouldn't be necessary.
   
   ### ๐Ÿ“Š Assessment
   
   | Dimension | Value | Reasoning |
   |---|---|---|
   | **Type** | `type:bug` | Clear defect: failed snapshot cleanup is blocked 
under specific conditions. |
   | **Component** | `component:kvm`, `component:ceph` | Explicitly KVM 
hypervisor + Ceph RBD primary storage; RAW volume format. |
   | **Severity** | `Severity:Major` | Blocks VM snapshot cleanup and can block 
VM destruction, but a workaround exists (start VM first), so not a full 
blocker. |
   | **Labels** | type:bug, component:kvm, component:ceph, Severity:Major | See 
above. |
   | **Coding agent** | Suitable | Well-defined scope: handle the case where a 
storage-based Instance Snapshot is in Error state with no underlying storage 
snapshot/kvmStorageSnapshot details, allowing metadata cleanup without 
requiring a libvirt domain. Clear reproduction steps and expected behavior 
provided. |
   
   ### ๐Ÿ”— Similar issues
   
   - Reporter explicitly references **#11673** and **PR #11687** as a 
related/precedent case (same class of bug for QCOW2/stopped VMs; PR #11687's 
fallback only covers QCOW2, not RAW/RBD). No other duplicate or related open 
issues were found via search.
   
   <details><summary>๐Ÿ’ก Notes and suggestions</summary>
   
   - Root cause: `KvmFileBasedStorageVmSnapshotStrategy` cannot handle RBD/RAW 
volumes, so deletion falls through to `DefaultVMSnapshotStrategy`, which 
dispatches `DeleteVMSnapshotCommand` to the KVM agent and requires a live 
libvirt domain.
   - Suggested fix direction (per reporter): extend the check in the delete 
path so that when an Instance Snapshot is in `Error` state, was created via the 
storage-based (RBD) strategy, and has no associated storage snapshot / 
`kvmStorageSnapshot` details, the deletion short-circuits to a metadata-only 
cleanup (similar to the existing QCOW2 offline fallback added in #11687), 
without invoking `DeleteVMSnapshotCommand` against a non-existent libvirt 
domain.
   - Also verify `orchestrateDeleteAllVMSnapshots()` (used during VM destroy) 
benefits from the same fix so VM destruction isn't blocked by such failed 
snapshots.
   - Reproduction requires: KVM + Ceph RBD primary storage, 
`kvm.vmstoragesnapshot.enabled=true`, a VM without a functioning QEMU guest 
agent, and a disk-only Instance Snapshot with quiescing enabled to force a 
freeze failure.
   
   </details>
   
   
   
   > Generated by [Daily Issue 
Triage](https://github.com/apache/cloudstack/actions/runs/32975834178) ยท 
sonnet50 98.8K ยท 
[โ—ท](https://github.com/search?q=repo%3Aapache%2Fcloudstack+%22gh-aw-workflow-call-id%3A+apache%2Fcloudstack%2Fdaily-issue-triage%22&type=issues)
   >
   <details>
   <summary>Add this agentic workflows to your repo</summary>
   
   To install this agentic workflow, run
   
   ```
   gh aw add 
githubnext/agentics/workflows/daily-issue-triage.md@d7c1dc4b72b00607a67caaffdcc216cb64379cf9
   ```
   </details>
   
   
   <!-- gh-aw-agentic-workflow: Daily Issue Triage, engine: copilot, version: 
1.0.52, model: claude-sonnet-5, id: 32975834178, workflow_id: 
daily-issue-triage, run: 
https://github.com/apache/cloudstack/actions/runs/32975834178 -->
   <!-- gh-aw-workflow-call-id: apache/cloudstack/daily-issue-triage -->


-- 
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]

Reply via email to