Recent content by dakralex

Yes, there currently is no option to bulk add them to the HA stack, but feel free to add a feature request in our Bugzilla [0] such that we can track it there with some description what it should do. [0] https://bugzilla.proxmox.com/enter_bug.cgi?product=pve&component=HA

Good question! But yes, in the proposed 2-node cluster setup with a QDevice, the HA Manager will only move one of the HA resources to another node and keep the other one as-is, because it is known that there aren't any other viable nodes to migrate to. In fact, it is the same behavior as...

Hi! Yes, currently, this is the expected behavior as the HA Manager will detect that each HA resource is on the same node as a HA resource it must not be together with and schedules both to move to other nodes. Negative HA resource affinity rules are relatively strict at the moment, as in...

Hi! There should be no specific reason why the fencing status is either on the top or the bottom. I couldn't yet reproduce the order of the first screenshot, does it happen randomly on reloading or move while staying on the page where it automatically updates?

Great that the details helped you! The recommended way to put an LRM service into an idle state would be to either move all of the HA resources placed on that node to another node or put all the HA resources placed on that node into the 'ignored' state and then wait the ~10 minutes until it...

After all the HA resources were set to 'ignored', it takes roughly 10 minutes for the LRM and 15 minutes for the CRM to release their watchdogs and become idle. Maybe the network interruption for both the production and test setup were done while some of the LRM services and/or the CRM Manager...

To mitigate this for now, zfs2/vm-101-cloudinit can be removed on the failed node to be able to migrate it back there.

Hi! Thanks for the report! I suppose there is a HA node affinity rule which makes the HA resource failback to the old node. As the node fails, the HA Manager will move the HA resource but not clean up the cloudinit image from the failed node as it would happen in normal circumstances... I...

Hi! Could you try force refreshing the web interface with Ctrl+F5 or Ctrl+Shift+R? Which version of pve-manager is running on the node?

Hm, then it could be a kernel panic inside the VM that is causing it and isn't written to the disk anymore if it doesn't show up in the syslog, e.g. journalctl -b -1... Maybe you can setup netconsole [0] [1] or some other log-persisting setup to capture the log when the freeze happens. [0]...

Hi! There is no simple way to move VMs and CTs under a single root cgroup as for VMs the code already depends on the VM's cgroups to be under the /qemu.slice cgroup and the /lxc cgroup is given by LXC itself, which has many intricacies that make this a requirement. So it can only be limited for...

I've proposed a patch for this on the mailing list [0]. [0] https://lore.proxmox.com/pve-devel/20260225143514.368884-1-d.kral@proxmox.com/

Hi! It seems like the initramfs is missing at boot, are there any other kernel versions installed on the system and bootable by selecting them in the bootloader menu? Booting another version and then reinstalling the one that panics should resolve this issue.

I don't know IPfire itself, but are there any logs within the VMs themselves? As their website states that they are based on Linux, the VMs own syslog or other logs could give some hint what the reason for the freezes are. 4 GiB seems good enough for such a use case, but might that be something...

I'm sorry, the pve-container package in version 6.1.2 is still in the trixie/pve-test repo as of now, if you want to try the new version to fix the issue.