Skip to content
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

Merged
merged 1 commit into from
Jun 10, 2024

Conversation

ahadas
Copy link
Member

@ahadas ahadas commented Jun 9, 2024

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.

Copy link

codecov bot commented Jun 9, 2024

Codecov Report

Attention: Patch coverage is 0% with 8 lines in your changes missing coverage. Please review.

Project coverage is 15.89%. Comparing base (4b425e4) to head (62d9b09).

Files Patch % Lines
pkg/controller/plan/scheduler/vsphere/scheduler.go 0.00% 8 Missing ⚠️
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     
Flag Coverage Δ
unittests 15.89% <0.00%> (-0.05%) ⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

liranr23
liranr23 previously approved these changes Jun 9, 2024
@liranr23 liranr23 self-requested a review June 9, 2024 15:09
@liranr23 liranr23 dismissed their stale review June 9, 2024 15:09

missing inflight

Copy link
Member

@liranr23 liranr23 left a 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]>
@ahadas
Copy link
Member Author

ahadas commented Jun 9, 2024

I think you should also consider it in buildInFlight()

correct, changed

Copy link

sonarcloud bot commented Jun 9, 2024

Quality Gate Passed Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
No data about Coverage
0.0% Duplication on New Code

See analysis details on SonarCloud

@ahadas ahadas merged commit 524f970 into kubev2v:main Jun 10, 2024
11 of 13 checks passed
@ahadas ahadas deleted the vsphere_cost branch June 10, 2024 08:44
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.

3 participants