Search results

I know, but you would have more performance on frr setup which is also full meshed without switch

I upgraded all 3 nodes one after another without using sdn in between.

Are you sure the gateways correct?

Thanks we changed nic1 to fit the mac, rebootet and also changed frr. This is how my /etc/frr/daemons file looks like, should all the lines with "yes" be switched to "no" and then systemctl restart frr? root@PMX7:~# cat /etc/frr/daemons # This file tells the frr package which daemons to start...

root@PMX8:~# cat /usr/local/lib/systemd/network/50-pve-nic0.link [Match] MACAddress=14:23:f2:e6:86:f0 Type=ether [Link] Name=nic0 root@PMX8:~# cat /usr/local/lib/systemd/network/50-pve-nic1.link [Match] MACAddress=14:23:f2:e6:86:f0 Type=ether [Link] Name=nic1 root@PMX8:~# cat...

1. We do not have ip-communication on all vms and ct since upgrading to pve9 (cant reach 10.26.0.1) -- untouched pve8.4.5 clusters work well on the same subnet including their vms/ct 2. the same lan works well on the pve-hosts itself (they can reach the gw 10.26.0.1) 2. I did use the...

Possible issue: after using nic-naming-tool no ip-communication inside vms and ct via vmbr0 since upgrade to pve9 (test-cluster) I did made a new post, because it seems to be a lot to post here: https://forum.proxmox.com/threads/pve-9-beta-different-network-errors-since-upgrade.168729/ Edit...

proxmox does generate a whitelist, you can check it via "pve-firewall localnet". Host on that Subnet are automatically allowed for 22/8006 and some other ports aswell.

Hard to tell, I cant remember If I had set that option before. Might be the case, so I overwrote the LVM.conf by confirming it with "yes" on upgrade-question.

On setups with modified chrony.conf it also brings a question on upgrade from 8to9. Maybe add this to the list on the wiki, otherwise manually set timeserver gets lost -> errors could happen in corosync or ceph.

Your device is full! No space left on device That is the reason!

No i mean the ring-IP-Adresses. its not allowed to change the ips in here. you need to first add a ring1, reload config. then remove ring0. You cant just simply switch the ip-adresses here.

You could have also set # of pgs to 128 and minimum # of pgs to 128 as well.

Did you just try to replace the ips in corosync.conf without removing the interfaces before? You will now need: https://forum.proxmox.com/threads/made-mistake-in-corosync-conf-now-cannot-edit.77173/#post-716686 you are having a split-brain-scenario now. It is not allowed to edit active links and...

Thanks! Good point, but this was not the solution for me. I noticed that the containers will start exactly after 5 minutes. Seems like a different problem. So waiting 5 minutes is ok for me atm. In case someone wants to update the debian containers to trixie to make the workaround actually work...

No unfortunately not. Thanks! On my side it only worked when doing the proxmox-boot-tool init /dev/sda2 && proxmox-boot-tool init /dev/sdb2 && proxmox-boot-tool refresh before rebooting.

Yes those vms are using 2 disks in a zfs mirror. Manually booting does not work it just goes back to bios again. This is how it looks like. I also only see one proxmox-entry.

Thanks I also needed to restart docker via systemctl restart docker on every boot. If I dont, docker does not work on my side.

* On Details: only use Web-Sockets-Support * Custom-Location: / then https then IP then 8006 * SSL all options enabled Thats how it works on my nginx reverse proxy.

on HA setups, using the maintenance-mode is a lot easier. On disabling: It even puts them back to the host the vms/ct were before enabling it.