server: fix host anti-affinity when start batch vms

[weizhouapache]

Description

This PR fixes #5527

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)

Feature/Enhancement Scale or Bug Severity

Feature/Enhancement Scale

• Major
• Minor

Bug Severity

• BLOCKER
• Critical
• Major
• Minor
• Trivial

Screenshots (if appropriate):

How Has This Been Tested?

[weizhouapache]

@blueorangutan package

[blueorangutan]

@weizhouapache a Jenkins job has been kicked to build packages. I'll keep you posted as I make progress.

[blueorangutan]

Packaging result: ✔️ el7 ✔️ el8 ✔️ debian ✔️ suse15. SL-JID 2644

[nvazquez]

Manually tested on KVM with 2 hosts:

Success cases:

• Create anti-affinity group
• Attempt deploying 3 VMs assigning them to anti-affinity group -> RESULT: first 2 VMs running one on each host, 3rd deployment fails
• Stop the 2 running VMs
• Deploy VM without start, assigning it to the anti-affinity group
• Start 3 VMs in batch -> RESULT: 2 VMs running on different hosts (screenshot)

Failing case:

• 2 VMs running one on each host
• Attemp to start the third VM on a specific host (different form the last_host_id) -> RESULT 3 VMs running (screenshot)

[weizhouapache]

Manually tested on KVM with 2 hosts:

Success cases:

• Create anti-affinity group
• Attempt deploying 3 VMs assigning them to anti-affinity group -> RESULT: first 2 VMs running one on each host, 3rd deployment fails
• Stop the 2 running VMs
• Deploy VM without start, assigning it to the anti-affinity group
• Start 3 VMs in batch -> RESULT: 2 VMs running on different hosts (screenshot)

Failing case:

• 2 VMs running one on each host
• Attemp to start the third VM on a specific host (different form the last_host_id) -> RESULT 3 VMs running (screenshot)

@nvazquez
thanks for testing.

the case seems to be expected behaviour. see below

cloudstack/server/src/main/java/com/cloud/deploy/DeploymentPlanningManagerImpl.java

Lines 297 to 301 in 9eefc76

	if (plan.getHostId() != null && haVmTag == null) {
	Long hostIdSpecified = plan.getHostId();
	if (s_logger.isDebugEnabled()) {
	s_logger.debug("DeploymentPlan has host_id specified, choosing this host and making no checks on this host: " + hostIdSpecified);
	}

[DaanHoogland]

@nvazquez thanks for testing.

the case seems to be expected behaviour. see below

cloudstack/server/src/main/java/com/cloud/deploy/DeploymentPlanningManagerImpl.java

Lines 297 to 301 in 9eefc76

	if (plan.getHostId() != null && haVmTag == null) {
	Long hostIdSpecified = plan.getHostId();
	if (s_logger.isDebugEnabled()) {
	s_logger.debug("DeploymentPlan has host_id specified, choosing this host and making no checks on this host: " + hostIdSpecified);
	}

@weizhouapache @nvazquez , this does not seem like desired behaviour, unless we decide to allow it (for root admin only). I think a user should remove a VM from the anti-affinity group if they want it to run anyway.

code changes looks good, btw.

[weizhouapache]

@nvazquez thanks for testing.
the case seems to be expected behaviour. see below

cloudstack/server/src/main/java/com/cloud/deploy/DeploymentPlanningManagerImpl.java

Lines 297 to 301 in 9eefc76

	if (plan.getHostId() != null && haVmTag == null) {
	Long hostIdSpecified = plan.getHostId();
	if (s_logger.isDebugEnabled()) {
	s_logger.debug("DeploymentPlan has host_id specified, choosing this host and making no checks on this host: " + hostIdSpecified);
	}

@weizhouapache @nvazquez , this does not seem like desired behaviour, unless we decide to allow it (for root admin only). I think a user should remove a VM from the anti-affinity group if they want it to run anyway.

code changes looks good, btw.

@DaanHoogland
Actually only root admin can start vm with specified host.

[nvazquez]

Thanks @weizhouapache @DaanHoogland - looks good then

[nvazquez]

@blueorangutan test

[blueorangutan]

@nvazquez a Trillian-Jenkins test job (centos7 mgmt + kvm-centos7) has been kicked to run smoke tests

[blueorangutan]

Trillian test result (tid-3391)
Environment: kvm-centos7 (x2), Advanced Networking with Mgmt server 7
Total time taken: 30959 seconds
Marvin logs: https://github.com/blueorangutan/acs-prs/releases/download/trillian/pr6002-t3391-kvm-centos7.zip
Smoke tests completed. 92 look OK, 0 have errors
Only failed tests results shown below:

Test	Result	Time (s)	Test File