Option for "group" gone in edit ct/vm machine HA setting in Prox 9

As far as i can tell now if i want to move a vm to another HA group i need to delete existing vm in resources migrate the vm to the host associated with the new group and then re-add the vm again in resources?

Is this correct?
 
Please, is there any way to bring groups back either in conjunction with ha rules or as an option to replace them. We have so many vms and so many different combos of node types that manually making affinity rules for each vm ruins the HA ease. it would be so much better to include ha rules with node affinity but be able to configure that on a group and throw vms into a group with said affinity than to do it per vm. Please say theres a roadmap to giving groups back, as this alone is enough to make me consider going back to VE 8.

Thanks,
cody.
 
Hi,
you don't need to manually make rules for each VM. Just make one node affinity rule with the same node priorities you had for the HA group previously and then add all VMs that should follow those priorities to that single rule.
 
  • Like
Reactions: Sp00nman
While this is a way to achieve the functionality of groups in the short term the ability to control what group a vm goes into is still way more steps than before.

In the VM > more > manage HA theres no longer an option to associate the vm with a group (or affinity rule in this case) so you now need to go into datacenter after adding the vm as an HA resource, go to affinity rules, and open all of the affinity rules to find the one that has the right nodes at the right priority to keep them where you want them (because theres no way to name them, just comments for them). then youve gotta add the vm and hope its not under another one (say an admin needs to move groups after resource is already created) which is just not as optimized as it could be.

Before(if my memory serves me) you could define a group with a couple nodes (cant remember if there was priority or not) and when you added a new vm you could then manage the HA right from within the VM.

Another nice thing about the old groups is that it would dumbly spread your vms out across all nodes in the group but if I create affinity with 4 nodes a, b, c, d at prio 1 and all the vms are on node a theyll just sit there because technically they are in the correct place. Maybe I'm wrong but it feels worse.

Thanks,
Cody
 
Last edited:
In the VM > more > manage HA theres no longer an option to associate the vm with a group (or affinity rule in this case) so you now need to go into datacenter after adding the vm as an HA resource, go to affinity rules, and open all of the affinity rules to find the one that has the right nodes at the right priority to keep them where you want them (because theres no way to name them, just comments for them). then youve gotta add the vm and hope its not under another one (say an admin needs to move groups after resource is already created) which is just not as optimized as it could be.
Fair point. It might be sensible to allow choosing a rule name (possible via API, but not UI) and to allow selecting which rule(s) a VM should belong to upon creation. Feel free to open a feature request for these: https://bugzilla.proxmox.com/ For now, you can put a name into the comment field.

Before(if my memory serves me) you could define a group with a couple nodes (cant remember if there was priority or not) and when you added a new vm you could then manage the HA right from within the VM.
What do you mean with "manage the HA from within the VM"? I only know about the possibility to choose the group when doing Manage HA like you mentioned before.

Another nice thing about the old groups is that it would dumbly spread your vms out across all nodes in the group but if I create affinity with 4 nodes a, b, c, d at prio 1 and all the vms are on node a theyll just sit there because technically they are in the correct place. Maybe I'm wrong but it feels worse.
Are you using the rebalance-on-start feature? It should still happen with that. But what might be different now is that you add the VM to the rule only after setting its state to started? If you do manage HA, with state stopped, then add it to the rule and then start it, do you get the behavior you expect?

CC @dakralex @mkoeppl to keep them in the loop :)
 
Fair point. It might be sensible to allow choosing a rule name (possible via API, but not UI) and to allow selecting which rule(s) a VM should belong to upon creation. Feel free to open a feature request for these: https://bugzilla.proxmox.com/ For now, you can put a name into the comment field.
Will do, however it will be after any additional information gained in replies to this.


What do you mean with "manage the HA from within the VM"? I only know about the possibility to choose the group when doing Manage HA like you mentioned before.
Well in my use of VE 7.x and 8.x I made it part of the workflow to create compute groups based on many factors like groups of 2, all compute, prio compute, etc. These would be named accordingly. If ever I needed to manage a VMs ha config after that I would only have to interact with the form in the top drop down of each vm (unless deleting its ha config, but thats different).

Now, the vm dropdown version of that form serves essentially no purpose as you can only create an ha config but you can also just do that in datacenter where the massive annoying list of others is so might as well just do everything from there now which is objectively worse.

To "add insult to injury" theres still the text "ha-group: none" in the summary of the vm so its like our groups were hastily ripped away and replaced with a completely different idea

Are you using the rebalance-on-start feature? It should still happen with that. But what might be different now is that you add the VM to the rule only after setting its state to started? If you do manage HA, with state stopped, then add it to the rule and then start it, do you get the behavior you expect?
Not quite, In older versions you could make a group with lets say 8 nodes as members. you could assign 16 vms to said group (on or off) and they would either live migrate if on to wherever proxmox decided, or move if shut down.

The process actively constantly kept vm counts in balance across nodes (mostly, its had issues with putting too many on one) even while they were on and if you tried to move it manually say from node e to node b pve would just move it back to node E because thats where it thought was best. Now if I have a cluster of 3 nodes for instance, and an affinity group with node a b and c all at priority 1 then nothing happens even if all vms are on node a (cant really test this scenario while vms are off or starting because of almost everything on my proxmox needing to remain on at all times).

if in the theoretical cluster of 3 we have node b at priority 2 while the rest are priority 1 then all vms (on or off) will migrate to node b. This part works as expected and gives fine control over what happens, however I still appreciate the automatic non config intensive nature of the old groups system. a mixture of both feature sets would be better than either one in my opinion.

Final remarks: If node affinity (or maybe resource affinity, don't know never used it) were in the vm>more>manage ha, AND if able to randomly distribute vms across nodes in said group if a set of nodes are the same priority it would be the ultimate combo of automatically efficiently using all the available hardware. Bonus points if theres a check box that has proxmox auto redistribute based on node cpu or memory exhaustion. Live migrate is great in this case with HA because its all transparent to the VM or service.

CC'ing @dakralex @mkoeppl to keep them in the loop :)

Thanks,
Cody
 
  • Like
Reactions: fiona