This is also a checkbox used to prevent the group from automatic failback when a new node joins the cluster. This is not enabled by default. Unless there is a strict requirement, this option should not be enabled. One scenario of using this is when an administrator is trying to diagnose a node or network failure. By enabling this option, we can prevent recovered VMs or services from moving back into the original node. 

The following screenshot shows the Groups submenu interface with our example group created:

At first glance, using groups may seem like just another layer of complexity, but proper use of groups really can help us create a highly complex automated administrator. Groups allow us to create multiple layers of failover, bind certain services to specific nodes, and distribute VMs to specific nodes to name a few. Let's look at the following scenario to better understand how groups can be used in a complex environment.

For this scenario, let's assume that this is a three-node Proxmox cluster where node #1 is powerful enough to run all VMs, whereas node #2 is powerful enough to run half and node #3 only a handful of VMs. In this scenario, creating just one group will try to move all VMs to one of the nodes, resulting in half of the VMs remaining powered off due to shortage of resources. But if we create two groups, one to move half of the VMs to node #2 and another group to move the remaining VMs to node #3, we can easily create an HA strategy to handle node failure automatically. 

Another scenario is to use groups to create different HAs for different VM groups. For example, we can have an HA group only to handle SQL database cluster VMs whereas another group will handle all VMs functioning as file servers. Due to the differing workloads of database and file servers, it may be more efficient to run them on specific groups of Proxmox nodes.