Search results

Works when disabling persistent cache on the rbd images. Curiously only effects virtio-blk not virtio-scsi.

Ceph is healthy. CephRBD is Replica 3 on 3x nodes with 7x Samsung sm863 OSD per node (21 total). WAL/DB is Optane 900p. RBD persistent write-back cache is also on Optane. This only happens on virtio block. It does not happen on virtio-scsi. I am using librbd because krbd does not support...

I receive the following error when starting a VM. task started by HA resource agent kvm: rbd request failed: cmd 0 offset 0 bytes 540672 flags 0 task.ret -2 (No such file or directory) kvm: can't read block backend: No such file or directory TASK ERROR: start failed: QEMU exited with code 1

I have a problem that just started with the updates pushed to the no-subscription repo overnight. QEMU won't start. task started by HA resource agent terminate called after throwing an instance of 'ceph::buffer::v15_2_0::end_of_buffer' what(): End of buffer TASK ERROR: start failed: QEMU...

Gen 2 isn't effected anyways, so I am of no help. Ignore me and carry on...

Does your Gen10 have Scalable Gen 1 or Gen 2 chips? Retbleed was patched in 5.19.

Through extensive testing with Optane cache drives, I have been able to increase Queue 1, IO-Depth 1, 4K writes by over 4X using RBD Persistent Write Log Cache. However, krbd does not support pwl, only librbd. In addition, librbd allows tuning such as "rbd_read_from_replica_policy = localize"...

6.2 is RC1. Wayyyyyy too early to be asking for it.

Without knowing if this node is also a Ceph MDS, Manager, and how many OSD’s it has it is impossible to say how much memory Ceph should be consuming. However, Ceph like all SDS takes heavy advantage of memory caching.

Testing on three nodes. Nothing has blown up (yet).

Any plans to enable MG-LRU in 6.1 builds?

Smooth sailing so far.

They still can’t execute an x86_64 instruction set, so what do you plan to run at scale on an ARM server?

Correct. vTPM won't utilize a physical TPM. The only purpose for a "real" TPM would be secure boot on the host, which I do not believe PVE (yet) supports.

Proxmox does not (to my knowledge) bundle and deploy cephadm.

Roughly the avg. I discounted major outlier values and adjusted to the most consistent results across the drive type. It has performed well using such a method. I have all types (NVMe, SSD, HDD).

I benchmark all of my drives multiple times and then set a consistent value for all of the same type across the cluster. The variance between each is easily explained by differences at the time of benchmarking (which occurs automatically when you upgraded or installed Ceph)

Here is the Ceph Manual. To set a custom mclock iops value, use the following command: ceph config set osd.N osd_mclock_max_capacity_iops_[hdd,ssd] <value> What type of drives are these?

When QEMU and LXC packages change, you have to either migrate or restart the VM / Container to have them running on the newest package.

Do vGPU drivers allow host access to the gpu, ie retain ability to use the GPU in LXC containers? I have gpu that are used in multiple LXC containers and it would be nice to also leverage vGPU in VM, but I’m not sure if the drivers permit both.