Recent content by jsterr

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.

for reference. I also used the workaround by editing the file.

Isnt that what "Hibernate" does ;-) ?

Hallo Daniel! Done https://bugzilla.proxmox.com/show_bug.cgi?id=7893 https://bugzilla.proxmox.com/show_bug.cgi?id=6593 (this ones already existing but also useful) https://bugzilla.proxmox.com/show_bug.cgi?id=6960 (already existed, commented on this one)...