Bug 1712353

Summary: [downstream clone - 4.3.5] [RFE] Allow Maintenance of Host with Enforcing VM Affinity Rules (hard affinity)
Product: Red Hat Enterprise Virtualization Manager Reporter: RHV bug bot <rhv-bugzilla-bot>
Component: ovirt-engineAssignee: Andrej Krejcir <akrejcir>
Status: CLOSED ERRATA QA Contact: Polina <pagranat>
Severity: high Docs Contact:
Priority: high    
Version: 4.2.7CC: achareka, fgarciad, mavital, mgoldboi, michal.skrivanek, mkalinin, myllynen, rbarry, rbdiri, Rhev-m-bugs, sbonazzo
Target Milestone: ovirt-4.3.5Keywords: FutureFeature, ZStream
Target Release: 4.3.5Flags: lsvaty: testing_plan_complete-
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: ovirt-engine-4.3.5, ovirt-engine-ui-extensions-1.0.6-1 Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of: 1651406 Environment:
Last Closed: 2019-08-12 11:53:28 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: Virt RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 1651406    
Bug Blocks:    

Description RHV bug bot 2019-05-21 11:41:02 UTC
+++ This bug is a downstream clone. The original bug is: +++
+++   bug 1651406 +++
======================================================================

1. Proposed title of this feature request
Allow Maintenance of Host with Positive Enforcing VM Affinity Rules.

3. What is the nature and description of the request?
Currently by design it is not allowed to break a hard affinity rule to migrate VMs to place host in maintenance mode and it behaves as if 2 or more VMs were pinned to the same host. Request is to allow placing such host in maintenance mode by migrating all VMs.

4. Why does the customer need this? (List the business requirements here)
We are creating an integrated product based on RHHI/RHV which will be installed as part of several isolated networks around the world and the system is expected to work under most extreme circumstances (including, but not limited to, man and nature originating national and international disasters). As such, not all admins/users using the system will be RHV experts so the user experience should be as smooth as possible. The requirement to make affinity rule non-enforcing, then put host to maintenance, then reset the affinity rule back to enforcing has two steps too many that might cause a user to lose time during emergency or, if distracted (which is likely under extreme circumstances), may not remember reset the affinity rule back to enforcing, causing hard-to-find issues later on if the tightly-coupled VMs end up running on separate hosts.

5. How would the customer like to achieve this? (List the functional requirements here)
It must be possible to put a Host to Maintenance even if VMs with Hard Positive VM Polarity are running on it provided that there are resources on other Hosts where they can be migrated, without the admin/user/script needing to tweak Affinity Rules during this operation.

6. For each functional requirement listed, specify how Red Hat and the customer can test to confirm the requirement is successfully implemented.
Yes.

7. Is there already an existing RFE upstream or in Red Hat Bugzilla?
I am not able to find any.

8. Does the customer have any specific timeline dependencies and which release would they like to target (i.e. RHEL5, RHEL6)?
Preferably as a part an RHV 4.2 errata but if that is not feasible then as part of RHV 4.3. First half of 2019 is when we ideally would like to have this feature available.

9. Is the sales team involved in this request and do they have any additional input?
No.

10. List any affected packages or components.
ovirt-engine.

11. Would the customer be able to assist in testing this functionality if implemented?
Yes.

(Originally by Ameya Charekar)

Comment 2 RHV bug bot 2019-05-21 11:41:06 UTC
This is extremely unlikely to make a 4.2 stream. 4.3 may be possible, but has soft affinity been looked at? Soft affinity (both host to VM and VM to VM) may provide an immediate resolution. This sounds extremely similar to the requirements which produced https://bugzilla.redhat.com/show_bug.cgi?id=1392393

(Originally by Ryan Barry)

Comment 18 RHV bug bot 2019-05-21 11:41:33 UTC
Re-targeting to 4.3.1 since it is missing a patch, an acked blocker flag, or both

(Originally by Ryan Barry)

Comment 20 RHV bug bot 2019-05-21 11:41:36 UTC
This applies to both affinity and anti-affinity. anti-affinity is going to work better, but still there will be times when the rules won't be enforced. Maintenance will have priority and if there is not enough hosts the system won't be able to distribute (or keep together) VMs properly. This should fix automatically once the host is brought back as the host becomes operational and empty/available for scheduling, though we will not attempt to restore the VM distribution exactly as it was.
I propose to turn this behavior on by default in 4.3, and have an engine-config toggle to switch this off if anyone finds this new behavior problematic

(Originally by michal.skrivanek)

Comment 21 RHV bug bot 2019-05-21 11:41:38 UTC
merged to 4.3

(Originally by michal.skrivanek)

Comment 22 RHV bug bot 2019-05-21 11:41:40 UTC
more patches are coming to 4.3

(Originally by michal.skrivanek)

Comment 24 RHV bug bot 2019-05-21 11:41:43 UTC
Not blocking ovirt-4.3.0 on this. Moving to 4.3.1.

(Originally by Sandro Bonazzola)

Comment 28 RHV bug bot 2019-05-21 11:41:50 UTC
negative affinity works (fixed also in 4.2.8-1)
positive affinity needs a bit more work

(Originally by michal.skrivanek)

Comment 30 RHV bug bot 2019-05-21 11:41:54 UTC
Verified on ovirt-engine-4.3.3.6-0.0.master.20190416081415.git5975555.el7.noarch

In the following cases the host maintenance is allowed:

1. Hard VM Positive and no Host Polarity 
2. Soft VM Positive and no Host Polarity
3. Hard VM Positive and Soft Positive host
3. Soft VM Positive and Soft Positive host

(Originally by Polina Agranat)

Comment 32 Polina 2019-06-30 10:16:58 UTC
verified on ovirt-engine-4.3.5.2-0.1.el7.noarch .

Comment 34 errata-xmlrpc 2019-08-12 11:53:28 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHEA-2019:2431