Search results

This only affects Ceph's Manager "dashboard" and "restful" modules. The storage itself is completely fine if after disabling those modules [1] ceph -s returns HEALTH OK [1] ceph mgr module disable restful and ceph mgr module disable dashboard.

What about Reef? Currently all my PVE8 clusters with Ceph use Reef. Thanks!

@Max Carrara Any ETA for these patches to reach enterprise repo? Thanks!

This sounds similar to this issue [1] that has been around for months despite many efforts to sort it out. Try using opt-in kernel 6.8 [2] as it seems to be solved with it. [1] https://forum.proxmox.com/threads/proxmox-8-0-kernel-6-2-x-100-cpu-issue-with-windows-server-2019-vms.130727/ [2]...

You can have VM/CT in both servers. You can even put some VMs in HA and other not so critical ones without HA and will not be started if the node they are runnin on fails. Also plan to use at least two corosync links to ensure cluster stability due to fencing [1]. [1]...

1.- Don't try to reinvent the wheel: use a qdevice in that Synology NAS and don't mess with pvecm expected 1. Such command is for disaster recovery, not for typical operations and may induce configuration conflicts if misused in a split brain situation. Also, corosync "two_node:" isn't...

Ceph: no, requires 3 servers for 3 replicas. If you had 3 new servers you could add their disks as OSD with a different device class, create a crush rule with that device class and create a pool that uses just disks of that device class. Still, Ceph quorum will require mayority from all...

Datastore.backup permission does not allow backups to be deleted from PVE. The attack should get PBS root credentials (or other used with admin privileges) that allow snapshot/namespace/datastore deletion. Which event are you trying to cover by not allowing PVE to restore backups?

For VMs, mount the NFS shares from the guest OS. For LXCs, manually mount the NFS share in the Proxmox host using something like this [1] (option 3). Avoid mouting NFS inside the LXC as it may cause I/O deadlocks. [1]...

Care: iperf3 uses just one thread (i.e. one core) until v3.16 [1], so maybe your test is limited by CPU performance. [1] https://github.com/esnet/iperf/releases/tag/3.16

Why do you have 3 addresses in the same network in the same host? What does your /etc/network/interfaces look like?

All you PG's are "active+clean": all your data it's as safe as it can be (probably 3 replicas if using default configuration). I would simply destroy the damaged OSDs (be sure to tick "wipe disk") and recreate them. Do it one by one and leave time for Ceph to rebalance between deletions/recreation.

Glad you found a solution for your use case!

Post the output of cat /proc/cmdline. It should have intel_iommu=on there. Do you have secure boot enabled? Do you use zfs as boot device?

Ask someone in the datacenter to replace the ethernet cable and check the statistics for that switch port. Something not ok and the problem will happen again eventually.

I've seen this on servers with some kind of out of band access (IPMI, iLo, iDRAC, BMC, you name it...) installed using a remote media (no local usb key with the iso). That extra nic belongs to that board and is usually detected as an USB device. You can simply remove it from the configuration...

Your nic isn't able to establish physical link with the swtich. I would swap network cable and check the switch port information and configuration. Maybe it was working half duplex before the update and after the reboot it can't link any more.

You are missing the --compress gzip parameter: vzdump 154 --mode snapshot --compress gzip --pigz 1 --dumpdir /vms/data-1/dump/ Why not using ZSTD? It's way faster, uses multiple threads automatically and compression ratio is quite good.

Both options are valid, being the mount on PBS preferable due to it's better network efficiency: data will cross the network only to read from the NFS and stored locally in PBS.

Use: pct unlock 101 qm is for VMs only, pct manages LXC containers.