Search results

The heavy customization part mostly resides within FRR. It's an ECMP routed configuration with each server connecting to two L3 switches, each connection on its own subnet, using /32 addresses on dummy interface for communication between each other and using OSPF to exchange the routing...

I have a heavily customized networking configuration and for some reason not yet apparent to me it does not survive the ifupdown2 reload. I made a change to my SDN configuration (changed one of the VXLAN VTEPs) and need to apply the change. If I do 'Apply' from GUI it will do reload on all...

I just upgraded my node to 7.2, and after the host restart one of my OSD would not start. That was the last remaining old-style (non-LVM) simple volume OSD. The following error reported 2022-05-12T15:31:02.538-0400 7fcc3f134f00 1 bdev(0x560e6221c400 /var/lib/ceph/osd/ceph-7/block) open path...

I upgraded the other two nodes of the cluster, and there were no issues. But what I did differently is that I installed ifupdown2 before the upgrade. So I compared my /etc/network/interfaces, and found that the node that did not work had 'allow-vmbr0 <interface>' commands, but the working...

Just wanted to share my experience. I also had openvswitch configuration with a bond and vlans, and it also stopped working after the upgrade. Did not know about the 'systemctl restart networking' trick, but manually creating vlan interfaces and assigning ip addresses with 'ip' command worked...

I had to use backports to install the version of ganesha that supports rados. I documented the procedure for my own reference on my site: http://mykb.mife.ca/post/ceph-ganesha/

Hi Fabian Thank you for looking into that. I decided to watch the utilization as backups were being done and I found that I had the option 'Verify New Snapshots' turned on, which caused the additional verification jobs created right after the backups. It appeared like those verification jobs...

I also hit this issue with the https upgrade request timeouts for different VMs during the backups. Running the latest 6.4 updates. My PBS target is quite and old desktop system with Celeron processor, and I have three proxmox servers with a backup job based on Pool membership. VMs are spread...

I am in Canada, and download.proxmox.com not working for me as well. It is resolving to 144.217.225.162, which is pingable but does not respond to HTTP requests. Hopefully the CDN provider is going to fix it...

I think I might hit this incompatibility issue when after the update one of my hosts suddenly stopped configuring the IP addresses from the configuration file. I had to scratch my head a lot. My solution was to ditch ifupdown2 rather than ovs...