Bug 1421713 - VM pinned to host is started on another host
Summary: VM pinned to host is started on another host
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: ovirt-engine
Classification: oVirt
Component: BLL.Virt
Version: 4.1.1
Hardware: Unspecified
OS: Unspecified
high
high
Target Milestone: ovirt-4.1.1
: 4.1.1.3
Assignee: Martin Sivák
QA Contact: Artyom
URL:
Whiteboard:
: 1426740 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-02-13 13:58 UTC by Petr Matyáš
Modified: 2017-04-21 09:47 UTC (History)
5 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2017-04-21 09:47:08 UTC
oVirt Team: SLA
Embargoed:
rule-engine: ovirt-4.1+
rule-engine: blocker+
msivak: devel_ack+


Attachments (Terms of Use)
Host assign (147.03 KB, image/png)
2017-03-01 13:44 UTC, Andrei Stepanov
no flags Details


Links
System ID Private Priority Status Summary Last Updated
oVirt gerrit 72277 0 master MERGED scheduling: Honor the Start Running On option 2017-02-15 12:31:35 UTC
oVirt gerrit 72353 0 ovirt-engine-4.1 MERGED scheduling: Honor the Start Running On option 2017-02-15 22:27:00 UTC

Description Petr Matyáš 2017-02-13 13:58:40 UTC
Description of problem:
I have a VM that should start on host_1, but is started on host_2 instead. In log I could find that it was started there because host_1 was not accessible, but I can migrate the VM there afterwards with no problem.

Version-Release number of selected component (if applicable):
4.1.1-1

How reproducible:
always

Steps to Reproduce:
1. set a VM to run on host-1
2. have other VMs running on host-1, but leave enough resources for the VM that is pinned there
3. start the VM

Actual results:
VM is started on different host

Expected results:
VM should be started on host it's pinned to if there are enough resources for it

Additional info:

Comment 2 Martin Sivák 2017-02-13 16:23:42 UTC
> Steps to Reproduce:
> 1. set a VM to run on host-1
Can you elaborate? What exactly did you do?

Comment 3 Petr Matyáš 2017-02-13 16:53:17 UTC
This happens when you set host in 'start on host' in host edit dialogue and have 'migration possible' or 'only manual migration possible' set in migration policy and start the VM.

You can fix this by setting higher weight in scheduling policy or by setting the the host in run once dialogue or choose 'no migration possible' in migration policy.

Comment 4 Red Hat Bugzilla Rules Engine 2017-02-14 15:07:12 UTC
This bug report has Keywords: Regression or TestBlocker.
Since no regressions or test blockers are allowed between releases, it is also being identified as a blocker for this release. Please resolve ASAP.

Comment 5 Martin Sivák 2017-03-01 11:46:39 UTC
*** Bug 1426740 has been marked as a duplicate of this bug. ***

Comment 6 Andrei Stepanov 2017-03-01 11:49:40 UTC
Fails for ovirt-engine-4.1.1.2-0.1.el7.noarch

Comment 7 Martin Sivák 2017-03-01 11:54:29 UTC
(In reply to Andrei Stepanov from comment #6)
> Fails for ovirt-engine-4.1.1.2-0.1.el7.noarch

- Can you check whether the cluster policy shows 99 next to the PreferredHosts cluster policy?
- Does the VM start on your host when you use Run Once and select the host?
- Can you attach the log with DEBUG enabled according to the testing section of: http://www.ovirt.org/develop/release-management/features/sla/scheduling-weight-normalization/

Comment 8 Andrei Stepanov 2017-03-01 13:44:19 UTC
Created attachment 1258683 [details]
Host assign

Comment 9 Martin Sivák 2017-03-01 14:56:00 UTC
The status of this bug is supposed to be MODIFIED only. The patch was merged and bug moved to modified after tagging for 4.1.1.2 but before the CI moved all modified bugs to ON_QA (including this one).

The fix will be part of the build tomorrow.

Comment 10 Artyom 2017-03-13 08:40:00 UTC
Verified on rhevm-4.1.1.4-0.1.el7.noarch

"Preferred Hosts" - weight module now has the factor equals to 99 for all default policies.


Note You need to log in before you can comment on or make changes to this bug.