Search results

From my vague recollection, once you have set up the additional network interface in Proxmox (IP/Subnet), you can set the corosync network in one of the config files (edit: /etc/pve/corosync) to that particular IP for each host. There's a few other settings too. Probably some restart of...

We had this problem on and off for a little over a year. We then moved the corosync to its own network and it went away forever. Until you make an isolated corosync network you'll always be in danger of having this problem.

Oh man, install your OS on a single mirror (2 disks). Don't go down your current path. It won't be smooth for your whole system nor for your sanity.

I did forget to mention that I properly removed the OSD as in the instructions on that link: Then I deleted the partitions. That did not work. What did eventually work is to write zeroes to the disk: sudo dd if=/dev/zero of=/dev/sdX bs=1M Thank you so much for your replies, as it gave me a...

PVE Versions: proxmox-ve: 5.2-2 (running kernel: 4.15.18-1-pve) pve-manager: 5.2-5 (running version: 5.2-5/eb24855a) pve-kernel-4.15: 5.2-4 pve-kernel-4.13: 5.2-2 pve-kernel-4.15.18-1-pve: 4.15.18-15 pve-kernel-4.15.17-1-pve: 4.15.17-9 pve-kernel-4.15.15-1-pve: 4.15.15-6...

Ok I figured out my problem. The correct command is: ceph osd crush set-device-class ssd osd.12 I switched the class "ssd" and osd name "osd.12"

Ok, on this other post, I see that sometimes the devices do not get automatically added to the correct class, but unsuccessfully, as in that post.

I tried to use the ceph osd crush set-device class ssd osd.12, but I am getting the following error: no valid command found; 10 closest matches: osd crush rule list osd crush rename-bucket <srcname> <dstname> osd crush weight-set ls osd crush weight-set dump osd crush weight-set create-compat...

We have a number of Dell Hosts with PERC H700 raid controllers. We just installed some SSDs so we can use the ssd class ceph replicated rule, but the disks show a class of hdd instead of ssd. Anyone run into this problem?

We have a 3 node CEPH hyperconverged cluster at my work, and the one thing that kept biting us in the ass from time to time, seemingly at random, was corosync toten re-transmissions. The best thing we did was to separate the corosync network. To save on costs and since we won't ever need to...

You don't have to do anything. Go to the VM -> Hardware Click on the Hard Disk. Then in the buttons above click Move Disk. You can Delete Source.

We also ran fine with the corosync network on the same network as the Proxmox for a while. Then, as load moderately increased, we started getting totem re-transmit errors. Once we separated corosync network we haven't had any issues whatsoever.

Same here, thank you!

Thanks to your diagnosis tips, I found out I was running into this issue. Since I am running without cephx I just made the keyring inaccessible: root@VMHost4:/etc/pve/priv/ceph# sudo mv ceph_vm.keyring ceph_vm.keyring_OLD

I just upgraded to the latest packages as of today and the host can boot again. Thank you for the assistance!

I just upgraded everything to the latest packages, including libpve-storage-perl: 5.0-20 and I am getting the same backup error. proxmox-ve: 5.1-43 (running kernel: 4.15.17-1-pve) pve-manager: 5.1-52 (running version: 5.1-52/ba597a64) pve-kernel-4.13: 5.1-44 pve-kernel-4.15: 5.1-4...

Yes, I have to use the older kernel 4.13.16 to boot. With kernel 4.15.15 it will not boot.

Hi Alwin, I added the rootdelay but I'm still getting the same boot error.

We just updated to the versions below and now our backups have stopped working. proxmox-ve: 5.1-43 (running kernel: 4.15.15-1-pve) pve-manager: 5.1-52 (running version: 5.1-52/ba597a64) pve-kernel-4.13: 5.1-44 pve-kernel-4.15: 5.1-3 pve-kernel-4.15.15-1-pve: 4.15.15-6 pve-kernel-4.13.16-2-pve...

I'm not sure when or why this error started appearing but it never prevented a boot, so I figured I could safely ignore it. Kernel version: proxmox-ve: 5.1-43 (running kernel: 4.13.16-2-pve) pve-manager: 5.1-52 (running version: 5.1-52/ba597a64) For the sake of search engines I'll write...