-
Notifications
You must be signed in to change notification settings - Fork 308
Support import of VM/template for Managed block storage #1138
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Open
slavkap
wants to merge
5
commits into
oVirt:master
Choose a base branch
from
slavkap:import-ova-mbs
base: master
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Open
Changes from all commits
Commits
Show all changes
5 commits
Select commit
Hold shift + click to select a range
561dc49
Support import VM/template for Managed block storage
slavkap c813cfc
core: pass tar member name as direct join key for OVA extract
ryan-ronnander fc3a11f
fix failing build
slavkap f46936d
refactor OVA import for managed block storage
slavkap e28e475
fix OVA import: disk-id tar mapping and mixed template disk profiles
slavkap File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
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
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
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
Oops, something went wrong.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This method pairs
ovaTarNamesByIndexwith diskPaths/diskList by index. These two lists come from different places and are not guaranteed to share the same order:ovaTarNamesByIndexis built in the parent (ImportVmFromOvaCommand.buildOvaTarNamesByIndex,ImportVmTemplateFromOvaCommandequivalent) fromimageMappings, aMap<diskId, tarName>that is already keyed by disk id.diskListin the child is reloaded viaupdateDisksFromDb() -> diskDao.getAllForVm -> GetDisksVmGuid, which has no ORDER BY and joins a multi-table view. Order is not guaranteed.When the two orders diverge, disk i's tar name gets paired with disk j's path, so the wrong OVA member is extracted into the wrong volume. Silent, no error. Single-disk imports can't hit this (index 0 to index 0 always matches),
which is likely why the 1/2/3-disk LINSTOR test passed but real-world multi-disk still risks corruption depending on plan/heap order.
Compounding issue: extract_ova.py has no coverage check. If a tar name the engine hands over never matches a member in the OVA, that disk is silently skipped and the playbook returns rc 0 with an empty volume.
Suggested fix: stop pairing by index.
ConvertOvaParameters, replaceList<String> ovaTarNamesByIndexwithMap<Guid, String> diskIdToTarName. The parent already has the disk-id keyed map (imageMappings), just pass it through instead of flattening to a list.prepareDisksJson, look up the tar name viadiskIdToTarName.get(diskList.get(i).getId())instead oftarNames.get(i). Throw if a lookup misses or a tar name is duplicated, don't silently drop a disk.extract_ova.py, track a remaining = set(disks) and discard on match,sys.exit(1)if anything is left after the loop.This removes the ordering dependency entirely, no ORDER BY/sort needed anywhere, and adds loud-failure behavior for a mismatch instead of a silent bad import.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for catching both issues @peter-boden! For extract, we now pass
diskIdToTarName(Map<Guid, String>) instead of pairing by index, fail on miss/duplicate inprepareDisksJson, andextract_ova.pyexits 1 if any tar name is unmatched. For mixed template import,MbsImportVmTemplateFromOvaCommandno longer overridessetAndValidateDiskProfiles()with return true; it supplies a per-disk skip predicate so only MBS-destined disks skip profiles, using destination-based lookup invalidate()(beforeadjustDisk/copyFrom). Destination resolution goes throughgetDestinationDomainIdForDisk()keyed by original OVF disk id so non-MBS disks in a mixed template still get profiles and the correct storage domain. Tested with mixed MBS (with StorPool) + NFS template OVA import.