Skip to content

[release-2.12] MTV-5556 | Solves the issue that warm precopy on Pure FlashArray vVol falls back to slow vmkfstools clone instead of array offload#7220

Open
github-actions[bot] wants to merge 2 commits into
release-2.12from
bp-release-2.12-2625f99-abd6027
Open

[release-2.12] MTV-5556 | Solves the issue that warm precopy on Pure FlashArray vVol falls back to slow vmkfstools clone instead of array offload#7220
github-actions[bot] wants to merge 2 commits into
release-2.12from
bp-release-2.12-2625f99-abd6027

Conversation

@github-actions

Copy link
Copy Markdown

Backport: #6477

When a precopy snapshot is active, the top-of-chain backing's filename is the child disk (foo-000001.vmdk) while forklift passes the base path (foo.vmdk). The old top-only path comparison missed this and the populator fell through to the VMDK/vmkfstools fallback. vmkfstools still produced correct bytes (it opens foo.vmdk on the host and VASA serves the snap-vVol), but at host-mediated speed.

Walk the Parent chain and return the BackingObjectId of the node whose filename matches the caller's vmdkPath. Warm precopy now matches at the parent, identifies the snap-vVol, and copies it via Pure REST.

Summary by CodeRabbit

Release Notes

  • Bug Fixes
    • Enhanced vSphere volume detection to properly traverse disk backing chains and accurately match disk paths in snapshot scenarios
    • Improved VVol identification for more reliable volume population operations

Review Change Stack

Wanru Liu and others added 2 commits June 22, 2026 11:26
… falls back to slow vmkfstools clone instead of array offload

Resolves: MTV-5556
Signed-off-by: Wanru Liu <waliu@purestorage.com>
@sonarqubecloud

Copy link
Copy Markdown

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant