Recent content by jsterr

Theoretically apt upgrade might refuse to install, remove, or replace package dependencies that Proxmox requires to function. Yes you can reboot at a different time. You also might need to move around some vms between hosts to "refresh" clients as the docs state.

No install all updates via apt update && apt dist-upgrade (never! apt upgrade) on all nodes, no reboot needed. all nodes need to be on latest packages of complete system. Yes Yes No You do not need to reboot the nodes, and NEVER use apt upgrade -> it can break your system. use dist-upgrade...

if you ask about if you might need to move vms to make the rotation possible - yes this might be the case. If you have running vms that might also have cephfs used in hardware-definition -> isos for example, you need to move all vms to a different host and maybe even unmount cephfs umount...

Wird man denke ich aber auch merken, wenn man z.B. im Ceph alle 5-10 Minuten einen Snapshot macht und alte ggf. aufräumt? Schonmal mit Ceph kombiniert?

How can I manually rotate keys like keys for rbd-mirror? root@pve-3:~# /usr/share/pve-manager/migrations/pve-cephx-rotate-service-keys --rotate-all-storage-keys --rotate-admin-key INFO: This is a dry run. No Ceph key, cipher setting, or daemon will be changed. Session observations can update...

Edit: Just in case. This was a fresh 20.2.4 install, no migration-script was used. Nope, having all nodes on the same version (pve-no-subscription) and using ceph wizard to install ceph. it also happend on a fresh 3 node install. all nodes, same updates, same ceph version. I restarted each...

not sure if this is related, but since the change of the new keys when you do a fresh ceph install (for example when adding a new ceph node), ceph pool status (via pvestatd) (server-view storage-pool) is showing a "?" which only disappears after restarting the pvestatd on that specific node...

VirtIO Block != VirtioSCSI - afaik VirtioSCSI has better performance and is recommended choice.

According to the docs: "If the NUMA option is used, it is recommended to set the number of sockets tothe number of nodes of the host system." Have you tried that and checked how it changes your situation/problem? https://pve.proxmox.com/pve-docs/pve-admin-guide.html#_numa I cant help here but...

Fix is up and worked well on my side: https://forum.proxmox.com/threads/ceph-cves-–-keyring-rotation-strongly-advised-probably-required-in-the-future.185863/#post-867260

Hello Thomas! @t.lamprecht After applying the updates in the script its green again, had to use a couple of commands though: root@training3:~# /usr/share/pve-manager/migrations/pve-cephx-rotate-service-keys root@training3:~# /usr/share/pve-manager/migrations/pve-cephx-rotate-service-keys...

how did it help you exactly? ;-) I personally would like to make some testing about: * testing with 32 PGs vs 512 PGs (min/max) and how it affects performance * testing with erasure coded pools (fastec/non-fast-ec) * testing with krbd/non-krbd

Yeah the container has failback disabled, this seems to be the reason why the container can be moved to a different host, even though the other host has a lower priority.

Hi @dakralex is this a known bug? If not I would create a new one. (not related to dynamic crs but we had talked about other ha improvements here in the last posts) Bug: VMs cant be migrated to nodes with lower priority if priority is set in a HA Node Affinity Rule (positive) without...

20.2.4-pve2 released - seems like I need to manually remove the self-applied fix, as the dashboard still shows the errors.