Recent content by dakralex

IOW, the browser-local settings are stored in the browser's local storage. That is, if you clear the particular node's site data in the browser, the setting will be restored to the default value "auto". There is no configuration file on the Proxmox VE node itself, which does change this setting...

Hi! The noVNC Settings Scaling Mode is a browser-local setting. FWIW, all settings in the "My Settings" panel are browser-local settings and aren't shared across different cluster nodes or browsers, so these are settings only for the current browser for a Proxmox VE node. Hope this helps!

This should be the same for VMs and CTs as the HA Manager handles affinity rules the same for both. In a quick test, the migration blocker with the same node affinity rule as above was shown to me for both VMs and CTs, so I couldn't move either the VM nor the CT to another node. Otherwise, I'd...

This comment in BZ 7260 [0] does state how HA resources can be added by adding items to the existing HA resources list of the node affinity rule. However, is there a specific use case why this is done in the pre-start hook-script instead of the HA resources being permanently HA-enabled and in...

Hi! This would be the expected behavior if there are no and have never been any active HA resource present (i.e. running) in the cluster. The CRM will only transition into an active state as soon as there are any active HA resource present, the same for the LRM but only if there are any active...

Yes, to be exact rebalance-on-start will only be relevant if the HA resource goes through the request_start state, which can only happen if the HA resource was previously in the stopped state and e.g. a user requests the guest to be started through the web interface, or if the HA resource is...

Hi! In case of a fenced node, the HA resources on the fenced node are put in recovery state and the HA Manager will select a recovery node for each HA resource individually. This will always try to spread the HA resources on the remaining cluster nodes with respect to the HA affinity rules of...

Generally, these sound like good ideas! Feel free to create separate Bugzilla entries for the separate issues: automatically add new guests as HA resources by enabling some cluster-wide check (Though new guests can be automatically added one-by-one by enabling the "Add to HA" in the web...

Hi Jonas! Good catch! There is a patch for this already on the mailing list [0], I will send a new revision soon so this gets resolved! This does only happen with the "migrate" shutdown policy and is documented in the documentation for the HA Manager [1]. It might be plausible to make the...

If a system needs high availability, there must be enough redundant hardware to compensate such node failures across the cluster. How many cluster node failures should be compensated is a question of cluster size (i.e. what is possible with respect to storage, corosync, redundant hardware...

To clarify this here, this is the expected behavior for the given HA affinity rule set. Essentially, if the HA resource has failback enabled (which it has by default) and is part of a node affinity rule with node priority classes, the HA resource can only be placed on nodes from the highest...

Sorry for the late reply, missed this thread in the new posts section. This was already stated some of the other answers, but this is the expected behavior: HA resources are by default configured with "failback" enabled. Failback in that sense means that whenever a higher priority node...

Hi! If I understand your description correctly, this is expected behavior. As HA resources are "failback" by default and the HA resource is in a non-strict node affinity rule, the HA Manager does not allow the migration. This is because the HA resource would be moved immediately back to the...

Hi, sorry for the late reply! At least for two rooms this is already possible with non-strict node affinity rules as these will fallback to the other available cluster nodes if none of the specified nodes are available anymore. However, an HA resource cannot be specified in a...

The SIGSEGV is a very different cause to end a process here, so that seems quite unrelated to the previous SIGABRT signals. Could you specify the hardware these cluster nodes are running on? Does a longer-running memtest or a stresstest with e.g. stress-ng show any signs of hardware failure?