Search results

Nice work guys. Looking forward to the new scheduler! I was really hoping for zfs replication to work with encrypted zfs zpool's!

Will proxmox ever be able to replicate encrypted ZFS datasets? This seems like a pretty big missing feature that isn't exactly well documented. I have been using syncoid but it has its own set of issues that keep corrupting my ZFS datasets.

I agree, this should be made very clear. I am using Syncoid successfully and it works pretty well.

Bumping this one to see if there has been any progress. This is a pretty big caveat that should be added to the wiki/documentation. Is this a issue for pve-zsync as well?

This isn't a procedure issue, its a bug in 15.2.8 from the looks of it. Currently working on compiling the pacific branch from source.

Both. The RBD can be primary or secondary and the RBD snapshots on the secondary are still bad. Snapshots on the primary always look good.

Yep I can promote the image on the secondary and the image looks good. Its just the clone of the snapshots on the secondary that I run into the issues.

Hey guys I have been doing considerably testing with Ceph Octopus on Proxmox and rbd-mirror snapshots to a remote cluster. Overall its going pretty well, but I am running into some odd issues with clones on the secondary cluster...

If I removed "--id %i" from the service config file, it starts and looks good. Snapshots are moving!

I am having some issues getting RBD-Mirror to start. Both clusters are brand new using Octopus. Jan 19 09:09:26 Bunkcephtest1 rbd-mirror[7085]: 2021-01-19T09:09:26.586-0500 7fcf6abd0700 -1 monclient(hunting): handle_auth_bad_method server allowed_methods [2] but i only support [2] Jan 19...

I can confirm it has solved my issue as well. Appreciate the assistance!

I have done a bit more digging. If I blacklist the be2iscsi module my issues are resolved. So far working on all the Gen9's I have updated.

If 5.4.65 is your 2nd kernel you would do the following. vi /etc/default/grub Change the following line from GRUB_DEFAULT=0 to GRUB_DEFAULT="1>1" Now run "update-grub" then "update-initramfs -u" Reboot and you should be good to go.

1. All the iLO and Bios related updates are recent on my one test machine. 2. I did test with the 5.4.78 kernel from testing, and it was the same issue. 5.4.65 does work.

Updated 3 other HP DL 380 Gen9's that we have inhouse, but aren't using HP MSA storage. Same exact issue. So far all my HP Gen10's aren't doing this. I have some vanilla Super Micro hardware that seems aok as well. Trying to find a HP Gen8 inhouse but I don't think we have one anymore.

Well I take that back. After mask'ing "systemd-udev-settle.service" I then noticed that "ifupdown-pre.service" was also failing. I masked "ifupdown-pre.service" and now the server is booting with networking as expected. However it is still throwing the kernel oops and its booting very slow...

Yep I have tried that as well. No change. The only thing that works so far is going back to 5.4.65.

Here it is. Keep in mind the same thing is happening for my bnx2x adapters. Networking is 100% once I get on it and run "systemctl restart networking.service"

I attached some screen shots for ethtool and the service status outputs. Also attached dmesg and journalctl outputs. Keep in mind, networking starts fine once I run systemctl restart networking.service. I am starting to wonder if its related to the SCSI HP MSA Central Storage. The below...

Service that are failing to start on these latest kernel's. root@supprox1:~# systemctl --failed UNIT LOAD ACTIVE SUB DESCRIPTION ● pvesr.service loaded failed failed Proxmox VE replication runner ● systemd-udev-settle.service loaded failed failed udev...