Search results

Unfortunately not. I've tried to switch from journaling to snapshot replication mode but was unable to set it up with current wiki manual: https://pve.proxmox.com/wiki/Ceph_RBD_Mirroring

Thomas, thanks for clarification. Are they (user-space 2.1.1 and kernel 2.0.6 100% compatible?

Enabling rbd_cache should help a lot Ex in my setup [client] keyring = /etc/pve/priv/$cluster.$name.keyring rbd_cache_size = 134217728

Are you sure that pve-kernel 5.11 test ships with ZFS 2.0.6? On my test node I see:

Dominik, thanks for the hint I've already tried do so but was facing errors and warnings in syslog related to rbd-mirror From my perspective RBD mirroring solution fro PVE Wiki only suitable for journal mirroring and not for image one. It would be extremely useful if Proxmox team will extend...

Any ideas? Proxmox Team?

Any ideas? @dcsapak @t.lamprecht

Any plans to integrate ceph replication (RBD mirroring) functionality into GUI? (with both snapshot and journaling modes) Current wiki tutorial (https://pve.proxmox.com/wiki/Ceph_RBD_Mirroring) covers only journaling one and not fully suitable for recent Pacific ceph distro(

Did you manage to get snapshot mirroring working with PVE wiki howto? I'm facing the same issue and result: 1 starting_replay

In PVE Wiki (https://pve.proxmox.com/wiki/Ceph_RBD_Mirroring) written Could anyone advice how to extend one-way mirroring to two-ways with respect to original PVE Wiki howto? Is it enough to install rbd-mirror in master (source) ? If so is it enough to install on one node in source CEPH...

Do I understand you correctly that two way mirroring requres installing rdb-mirror deamon on both sides? (muster and backup cluster) However in PVE WIki is clearly written: rbd-mirror installed on the backup cluster ONLY (apt install rbd-mirror). With PVE 6.4 I still get health: WARNING...

Yeap, I did some progress indeed Unfortunately, I didn't manage to find out what caused "Device busy" - my assumption is that it somehow related to ZFS import (scan?) procedure that occurs on PVE (OS) start up (all the disks were a part of another ZFS pool from different storage without...

I'm facing an issue with creating ZFS pool with dm-mappers (clean 6.3 PVE) I have HP gen8 server with dual port HBA connected with two SAS cables to HP D3700 and dual port SAS SSD disks SAMSUNG 1649a I've installed multipath-tools and changed multiapth.conf accordantly ...

It's not sctually correct! If you set zfs_arc_min to zfs_arc_max it does not use zfs_arc_min as zfs_arc_max! It sets zfs_arc_min to desired value and ignores value for zfs_arc_max (so it's kept as default - half of RAM)

I can confirm that setting zfs_arc_min equal to zfs_arc_max breaks old behavior and reset upper limit to default half of RAM Very painful - this was my default setup for years(

Checked. Works as expected. Thanks

Thanks for clarifying

Seems you ignored quoted text and cut my response to your colleague from the context. I was replying him and saying that I was not able to check his suggestion and workaround at that moment

Unfortunately, all the affected VMs were from production environments and had to be fixed ASAP. Hopefully, I've managed to reproduce this issue on one of our client's test system and here the information I've collected so far: PVE host: root@pve:~# dumpe2fs $(mount | grep 'on \/ ' | awk...

This package in only available in test and non-subscription repos - so nothing to complain about)