-
Notifications
You must be signed in to change notification settings - Fork 31
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
vsphere: virt-v2v transfers disks sequentially #926
Conversation
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #926 +/- ##
==========================================
- Coverage 15.94% 15.89% -0.05%
==========================================
Files 106 106
Lines 19767 19772 +5
==========================================
- Hits 3152 3143 -9
- Misses 16335 16351 +16
+ Partials 280 278 -2
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. |
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.
I think you should also consider it in buildInFlight()
when scheduling migrations to accommodate the controller_max_vm_inflight setting for vSphere, we didn't take into account that disks are transferred sequentially by virt-v2v (as opposed to CDI that transfers them in parallel by different pods). This lead to performance degregeration since could have triggered more migrations, in case of migrations of multi-disk VMs, simultaneously without exceeding the value of controller_max_vm_inflight. This is fixed by setting the cost of each VM for which the disks are transferred by virt-v2v to 1. Signed-off-by: Arik Hadas <[email protected]>
correct, changed |
Quality Gate passedIssues Measures |
when scheduling migrations to accommodate the controller_max_vm_inflight setting for vSphere, we didn't take into account that disks are transferred sequentially by virt-v2v (as opposed to CDI that transfers them in parallel by different pods). This lead to performance degregeration since could have triggered more migrations, in case of migrations of multi-disk VMs, simultaneously without exceeding the value of controller_max_vm_inflight. This is fixed by setting the cost of each VM for which the disks are transferred by virt-v2v to 1.