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.

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:

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

(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.

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.

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.

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.

(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).