Bug 1256730 - Failed to enable HA option on vm, that pinned to multiple hosts
Failed to enable HA option on vm, that pinned to multiple hosts
Status: CLOSED CURRENTRELEASE
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: ovirt-engine (Show other bugs)
3.6.0
All Linux
high Severity urgent
: ovirt-3.6.0-rc3
: 3.6.0
Assigned To: Martin Sivák
Artyom
: Triaged
Depends On:
Blocks: 1107512
  Show dependency treegraph
 
Reported: 2015-08-25 06:53 EDT by Artyom
Modified: 2016-04-19 21:10 EDT (History)
12 users (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Previously, if a virtual machine was pinned to a host, you could not select the Highly Available check box for that virtual machine as high availability would not be able to operate properly. With Red Hat Enterprise Virtualization 3.6, multiple host pinning is supported and the rule has been updated to allow the Highly Available check box to be selected for virtual machines that are not pinned, pinned to any host (migration disabled, but can be started on any host), or pinned to multiple hosts. Note that in the last scenario, if all pinned hosts are down, the virtual machine won't have a host to start on.
Story Points: ---
Clone Of:
Environment:
Last Closed: 2016-04-19 21:10:12 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: SLA
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
oVirt gerrit 45383 master MERGED Enable VM high availability when multiple pinning hosts are selected Never
oVirt gerrit 47264 ovirt-engine-3.6 MERGED Enable VM high availability when multiple pinning hosts are selected Never
oVirt gerrit 47265 ovirt-engine-3.6.0 MERGED Enable VM high availability when multiple pinning hosts are selected Never

  None (edit)
Description Artyom 2015-08-25 06:53:37 EDT
Description of problem:
Failed to enable HA option on vm, that pinned to multiple hosts

Version-Release number of selected component (if applicable):
rhevm-3.6.0-0.12.master.el6.noarch

How reproducible:
Always

Steps to Reproduce:
1. Create vm and pin it to two host
2. Try to enable HA option on vm
3.

Actual results:
Engine not give to enable HA option, because vm must have "Migration Options" equal to "Allow manual and automatic migration"

Expected results:
In case if vm pinned to number of hosts, we must allow to set vm as HA vm

Additional info:
Comment 1 Doron Fediuck 2015-08-26 09:23:30 EDT
Since there are multiple hosts available, HA should be allowed.
Note that HA should still be blocked if there's only a single host the
VM is pinned to.
Comment 2 Martin Sivák 2015-08-27 09:03:06 EDT
So what will happen in a situation like this:

Host A, Host B, Host C
VM is pinned to Host A and Host B and marked as highly available
Host A goes to maintenance (or down)
VM is started (-> Host B)
Host B goes down, breaking the HA configuration even though there is a third host still available
Comment 3 Doron Fediuck 2015-08-27 09:22:14 EDT
(In reply to Martin Sivák from comment #2)
> So what will happen in a situation like this:
> 
> Host A, Host B, Host C
> VM is pinned to Host A and Host B and marked as highly available
> Host A goes to maintenance (or down)
> VM is started (-> Host B)
> Host B goes down, breaking the HA configuration even though there is a third
> host still available

B will not go down before there's an available placement to the VM.
This is what happens today when you move a host to maintenance and
there's an HA running on that host and no other hosts available.
Comment 4 Martin Sivák 2015-08-27 10:28:10 EDT
B will go down if the hw fails or the power is out. And there is no way to start the HA VM afterwards even though the cluster still has one perfectly fine host.

The current code does not allow pinning at all for HA VMs and so it will behave better in this case. We might want to warn users that pinning a HA VM is not a good idea even though we allow that now.
Comment 5 Martin Sivák 2015-09-21 06:20:37 EDT
I am not sure we want to do this as the old behaviour relied strictly on whether the VM was migratable or not. The amount of pinned hosts does not really change anything here as we use that only for VM start.

There are basically two cases with multiple pinning:

- The VM is allowed to migrate and one or multiple hosts are selected -> HA is allowed independently on the pinning, the VM will try to start on any selected host or anywhere else

- The VM is not allowed to migrate -> we do not allow any migration at all and we did (3.5) not allow HA independently of the pin to host setting even in case of 'use any host' being set (which supersedes selecting multiple hosts).


That said, I have the patch that enables the multiple hosts, no migration allowed -> HA is still allowed flow, I am just not sure it is the right behaviour.
Comment 6 Artyom 2015-09-24 05:28:35 EDT
Update failed also via REST
have vm that pinned to two hosts and try to update it via REST(PUT action):
<vm>
<high_availability>true</high_availability>
</vm>

despite that REST return status ok(200), high_availability value of vm stay false
<high_availability>
<enabled>false</enabled>
<priority>1</priority>
</high_availability>
Comment 7 Roy Golan 2015-10-07 04:53:35 EDT
It is unclear how multiple pinning host and HA Vms interact. Should we 
consider hosts outside of the set or not?
Comment 8 Roy Golan 2015-10-07 09:14:02 EDT
Martin, after speaking with Doron we should allow HA if we have more than 1 Host available, no mater what the migration options are.
Comment 9 Martin Sivák 2015-10-07 10:42:56 EDT
Then explain to me the difference between:

A) Migration disabled, two hosts are selected (new in 3.6)
B) Migration disabled, no host is selected - meaning any host is fine (already possible in 3.5)

HA should be allowed in A according to what you tell me, but HA is not allowed in B and never was. And B allows you to choose even more hosts than A.
Comment 10 Doron Fediuck 2015-10-08 05:00:53 EDT
(In reply to Martin Sivák from comment #9)
> Then explain to me the difference between:
> 
> A) Migration disabled, two hosts are selected (new in 3.6)
> B) Migration disabled, no host is selected - meaning any host is fine
> (already possible in 3.5)
> 
> HA should be allowed in A according to what you tell me, but HA is not
> allowed in B and never was. And B allows you to choose even more hosts than
> A.

Let's review the migration support for HA VMs first;

Ver | pin to host(s) | preferred (default) host | allow any |
====|================|==========================|===========|
3.5 | not allowed    | allowed                  | allowed   |
3.6 | OK if >=2 hosts| allowed                  | allowed   |
=============================================================

This should be broken into the relevant options of "Start Running On"
and "Migration Options". In your scenario (A) is fine. (B) is preventing
the HA from working, so we should not allow it (either HA or completely
disable migration).
Comment 11 Artyom 2015-10-25 08:41:22 EDT
Verified on rhevm-3.6.0.2-0.1.el6.noarch
Succeed to enable HA option to vm that pinned to multiply hosts.
Also HA works as supposed.

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