Skip to content

server: double check host capacity when start/migrate a vm#3728

Merged
yadvr merged 2 commits into
apache:4.13from
ustcweizhou:4.13-double-check-host-capacity
Jan 28, 2020
Merged

server: double check host capacity when start/migrate a vm#3728
yadvr merged 2 commits into
apache:4.13from
ustcweizhou:4.13-double-check-host-capacity

Conversation

@ustcweizhou
Copy link
Copy Markdown
Contributor

Description

When start a vm or migrate a vm (away from a host in host maintenance), cloudstack will check capacity of all hosts and choose one. If there are hundreds of hosts on the platform, it will take some seconds. When cloudstack choose a host and start/migrate vm to it, the resource consumption of the host might have been changed. This normally happens when we start/migrate multiple vms.
It would be better to double check the host capacity when start vm on a host.

This PR includes the fix for cpucore capacity when start/migrate a vm.

Types of changes

  • Breaking change (fix or feature that would cause existing functionality to change)
  • New feature (non-breaking change which adds functionality)
  • Bug fix (non-breaking change which fixes an issue)
  • Enhancement (improves an existing feature and functionality)
  • Cleanup (Code refactoring and cleanup, that may add test cases)

Screenshots (if appropriate):

How Has This Been Tested?

start multiple vms on a host
put a host to maintenance so multiple vms will be migrated at same time
check the resource count of cpucore, all looks good.

Copy link
Copy Markdown
Contributor

@DaanHoogland DaanHoogland left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am usually very picky on the subject of logging and stacktraces, and I made one remark on it, but looking at the whole change I think the logging will be enough for maintainer and?or operator. A little comment in this respect wouldn't hurt.

} catch (final NoTransitionException e3) {
s_logger.warn(e3.getMessage());
}
throw new CloudRuntimeException("Migration cancelled because " + e2.getMessage());
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

can we add the cause or log its stack-trace before abandoning it here?

@apache apache deleted a comment from blueorangutan Jan 3, 2020
@apache apache deleted a comment from blueorangutan Jan 3, 2020
@apache apache deleted a comment from blueorangutan Jan 3, 2020
@apache apache deleted a comment from blueorangutan Jan 3, 2020
@andrijapanicsb
Copy link
Copy Markdown
Contributor

build failed, wiped the env.

@blueorangutan
Copy link
Copy Markdown

Trillian test result (tid-697)
Environment: kvm-centos7 (x2), Advanced Networking with Mgmt server 7
Total time taken: 41133 seconds
Marvin logs: https://github.com/blueorangutan/acs-prs/releases/download/trillian/pr3728-t697-kvm-centos7.zip
Intermittent failure detected: /marvin/tests/smoke/test_internal_lb.py
Intermittent failure detected: /marvin/tests/smoke/test_outofbandmanagement.py
Intermittent failure detected: /marvin/tests/smoke/test_privategw_acl.py
Smoke tests completed. 77 look OK, 0 have error(s)
Only failed tests results shown below:

Test Result Time (s) Test File

@DaanHoogland
Copy link
Copy Markdown
Contributor

@andrijapanicsb this one looks good. Want to have a look? (cc @borisstoyanov )

@apache apache deleted a comment from blueorangutan Jan 21, 2020
@apache apache deleted a comment from blueorangutan Jan 21, 2020
@apache apache deleted a comment from blueorangutan Jan 21, 2020
@apache apache deleted a comment from blueorangutan Jan 21, 2020
@DaanHoogland
Copy link
Copy Markdown
Contributor

@rhtyd @nvazquez @wido @GabrielBrascher is this alright?

@yadvr yadvr merged commit 136505b into apache:4.13 Jan 28, 2020
ustcweizhou added a commit to ustcweizhou/cloudstack that referenced this pull request Feb 28, 2020
When start a vm or migrate a vm (away from a host in host maintenance), cloudstack will check capacity of all hosts and choose one. If there are hundreds of hosts on the platform, it will take some seconds. When cloudstack choose a host and start/migrate vm to it, the resource consumption of the host might have been changed. This normally happens when we start/migrate multiple vms.
It would be better to double check the host capacity when start vm on a host.

This PR includes the fix for cpucore capacity when start/migrate a vm.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

6 participants