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:
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.
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.
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>
It is unclear how multiple pinning host and HA Vms interact. Should we consider hosts outside of the set or not?
Martin, after speaking with Doron we should allow HA if we have more than 1 Host available, no mater what the migration options are.
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).
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.