github-actions[bot] commented on issue #14030: URL: https://github.com/apache/cloudstack/issues/14030#issuecomment-5510499772
## ๐ฏ Triage report When deleting a VM snapshot on KVM for a multi-disk VM, each disk's delta is merged back into its base file sequentially, but CloudStack treats the whole merge job as a single succeed/fail unit. If an earlier disk completes its merge but a later disk's merge fails or times out, the entire operation is reported as failed and the DB `volumes.path` for the disk that actually finished is never updated โ leaving it pointing at a file that no longer exists. The VM subsequently fails to start with "Can't find volume:(uuid)". A maintainer (JoaoJandre) has already commented with design ideas (a sync/reconciliation API similar to what was done for KVM's "KBOSS", or an error state requiring explicit reconciliation). ### ๐ Assessment | Dimension | Value | Reasoning | |---|---|---| | **Type** | type:bug | Reproducible DB/storage state inconsistency with clear repro steps | | **Component** | component:kvm | Issue is specific to KVM VM-snapshot merge/delete handling | | **Severity** | Severity:Major | Can render a VM unable to start (DB pointing to a nonexistent file), but requires a partial-failure race during multi-disk merge and manual DB fix-up is a known workaround | | **Labels** | type:bug, component:kvm | | | **Coding agent** | Not suitable | Maintainer discussion indicates this needs a design decision (per-volume result tracking vs. a new sync/reconcile API vs. an error state requiring manual sync) before implementation can start | ### ๐ Similar issues - https://github.com/apache/cloudstack/issues/9538 (related) โ a different KVM snapshot-related bug where creating a volume from a volume snapshot can sometimes lose the snapshot; not the same root cause but in the same general area (KVM volume/VM-snapshot state consistency). <details><summary>๐ก Notes and suggestions</summary> - The maintainer's comment already sketches two possible directions: (1) track per-volume merge success/failure and only update `volumes.path` for volumes that actually completed, or (2) put the VM in an error state on partial failure and require an explicit reconcile/sync API call (similar to the KBOSS precedent) to reconcile ACS's DB with what's actually on storage. - Given the design trade-offs are still being discussed, this is best handled by a contributor familiar with the KVM VM-snapshot delete/merge code path (`VmSnapshotManagerImpl`, KVM agent's merge command wrapper) rather than being picked up as a self-contained coding-agent task at this time. </details> > Generated by [Daily Issue Triage](https://github.com/apache/cloudstack/actions/runs/33636271985) ยท sonnet50 135.6K ยท [โท](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: 33636271985, workflow_id: daily-issue-triage, run: https://github.com/apache/cloudstack/actions/runs/33636271985 --> <!-- 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]
