Resolve blockers for SMAPIv3 snapshot-aware migration - #7216
Open
LunfanZhang wants to merge 4 commits into
Open
Conversation
When reverting a snapshot, XAPI clones the snapshot disk via VDI.clone to create a new active VDI. The vdi_clone_impl in xapi-storage-script called Volume_client.clone but forgot to write the vdi-type key into the new volume's key store. vdi_create_impl does write this key, but vdi_clone_impl never did. After the revert, the next SR.scan reads back the volume metadata and gets ty = "" for the new active VDI because the key is missing. This empty type ends up in the XAPI database and breaks any logic that checks VDI type, including the snapshot migration flow. The fix adds the missing update_keys step to vdi_clone_impl. Signed-off-by: Lunfan Zhang[Lunfan.Zhang] <Lunfan.Zhang@cloud.com>
…ation When migrating from SMAPIv1 to SMAPIv3, the snapshot relationship fields (snapshot_of, snapshot_time, is_a_snapshot) were only updated in the XAPI database, not on the destination backend storage. A subsequent SR.scan then read the stale custom keys back from the volume metadata and overwrote the XAPI database, which removed the relation between the snapshots and their leaf VDI (observed on GFS2 SRs). This adds a new VDI.set_snapshot_metadata SMAPIv2 operation that writes these fields into the volume key store. It is declared in storage_interface, defaulted in storage_skeleton, implemented in xapi-storage-script (SMAPIv3), and wired through storage_mux. SMAPIv1 implements it as a no-op since its snapshot metadata is managed by the XAPI database only. SR.update_snapshot_info_dest now calls it best-effort after updating the database (errors are logged and swallowed, the XAPI DB remains authoritative) so the backend metadata stays consistent across an SR.scan. Signed-off-by: Lunfan Zhang[Lunfan.Zhang] <Lunfan.Zhang@cloud.com>
During SXM mirroring the DATA.stat polling loop repeatedly calls VDI.stat, which issues a Volume.stat RPC to the storage script on every poll. This adds unnecessary load and latency while waiting for a mirror to complete. Introduce a lightweight per-(SR, VDI) cache in DATAImpl: [mirror] populates it at mirror start, [stat] serves from it on a cache hit instead of calling Volume.stat, and the entry is evicted when the mirror completes or fails. The cache needs no mutex because the module runs in a cooperative Lwt async context. Signed-off-by: Lunfan Zhang[Lunfan.Zhang] <Lunfan.Zhang@cloud.com>
Collaborator
Author
|
This PR is not new work — it is the first slice of #7137, for saving your time, Nothing was added, removed or amended in the split. |
Contributor
|
can you rebase on master to be able to build it? I still have: |
Collaborator
Author
I once hit this issue, and I have sync the master to feature branch to resolve this, so I think you can take try to build on feature branch after it get merged. |
Contributor
|
In fact I rebased it on master and I was able to build it. But there were minors conflicts when rebasing so that is why I asked to rebase it, to have something clean. But it is ok for me for reviewing no worries ;) |
gthvn1
reviewed
Aug 11, 2026
| ) | ||
| |> wrap | ||
|
|
||
| let vdi_clone_impl dbg sr vdi_info = |
Contributor
There was a problem hiding this comment.
shouldn't we also add the update_keys logic in "vdi_snapshot_impl" ?
Collaborator
Author
There was a problem hiding this comment.
we should set the keys in vdi_snapshot_impl, and it already set in current impl.
gthvn1
reviewed
Aug 11, 2026
…1->SMAPIv3 SXM receive_finalize_common destroys the "dummy" VDI that receive_start_common snapshotted for VDI.compose. On SMAPIv1 that drops the backend volume and the dest DB row together; on SMAPIv3 Volume.compose has already consumed the volume, so the destroy fails (swallowed by log_and_ignore_exn) and the row survives as an orphan snapshot of the active disk, breaking any later SXM v3 migration of that disk. Add forget_orphan_dest_vdi in storage_migrate_helper, called from receive_finalize_common and receive_cancel2. It forgets the row through the XenAPI session embedded in the SXM url - going via the dest session rather than the local DB is what makes it correct cross-pool. Best-effort, only for is_a_snapshot rows, and a no-op on SMAPIv1 where the row is already gone. Signed-off-by: Lunfan Zhang[Lunfan.Zhang] <Lunfan.Zhang@cloud.com>
LunfanZhang
force-pushed
the
private/luzhan/sxm-v3-p1-blockers
branch
from
August 12, 2026 02:05
165ae40 to
3bad06b
Compare
Collaborator
Author
Yep, matching |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This PR does not contain the SXM v3 snapshot-migration itself. It lands the prerequisite fixes (and one optimization) that currently block it, so they can be reviewed independently. The SXM v3 and its wiring follow in two subsequent PRs.
Design refer: https://github.com/xapi-project/xen-api/blob/feature/sxm-v3/doc/content/xapi/storage/sxm/sxm-v3-with-snapshot.md