Yes, indeed, during the upgrade nothing changes. Unfortunately, we will have to migrate over several days, and above all, there is still a huge unknown that we would have liked to be able to control: how the switch to the new configuration will happen.
What we would have liked (and I don’t think I’m the only one in this case) is to be able to apply the configuration on the new nodes running v9, without it affecting those still in v8. Because if I have to migrate all my nodes and then press the button afterwards thinking everything will work fine… No, that’s not ideal. Unfortunately, with network interactions — and even more so interactions with routing protocols deeply embedded in the infrastructure — you want to have control over how the switchover will occur. For now, I don’t see how to migrate to v9 without risking major downtime (a lab will not show the exact behavior we can expect in this type of SDN infrastructure). > Le 9 oct. 2025 à 14:17, Stefan Hanreich <[email protected]> a écrit : > > On 10/8/25 12:47 PM, Julien OHAYON wrote: >> My concern is during the migration: if I configure OSPF on a node running >> v9, will this have an impact on the nodes still running v8? > > This one is a bit tricky to answer because of a change in the reload > endpoint between 8 and 9. The behavior depends on certain factors (which > node initiates the reload, how your SDN configuration looks like, ...). > > This is due to the introduction of an additional API parameter that is > incompatible with PVE 8.x instances. For that reason, we recommend only > mixing major versions in a cluster while performing an upgrade, not for > prolonged periods of time. We do *not* recommend doing any configuration > changes while your cluster is on mixed major versions. Problems like > this can occur due to changes between major versions and we cannot > guarantee correct behavior while your cluster is running on mixed major > versions. > > > That being said, upgrading from 8 to 9 alone should not cause your > custom /etc/frr/daemons file to get overwritten - since the SDN stack > only writes to it when re-generating the configuration (= applying the > SDN configuration). > > If you upgrade from an earlier FRR version (8), then you would get a > prompt that the daemons file changed, asking you to review you the > changes - like so: > > Configuration file '/etc/frr/daemons' > ==> Modified (by you or by a script) since installation. > ==> Package distributor has shipped an updated version. > What would you like to do about it ? Your options are: > Y or I : install the package maintainer's version > N or O : keep your currently-installed version > D : show the differences between the versions > Z : start a shell to examine the situation > The default action is to keep your current version. > *** daemons (Y/I/N/O/D/Z) [default=N] ? > > Upgrading from 10.2 (with ospfd=yes) does not cause a prompt to appear > and the daemons file stays untouched. > > > I've also verified this right now by upgrading a PVE 8 instance with > ospfd=yes in its daemon file. Upgrading itself did not overwrite the > directive in the daemons file - only reapplying the SDN configuration > does set it to ospfd=no. > > So, as long as you do not re-apply the SDN configuration in any way, > your OSPF directive in the daemons file stays untouched. On PVE9, when > applying a SDN configuration that contains either a fabric or an EVPN > controller will overwrite the FRR configuration (including the daemons > file). > > _______________________________________________ pve-user mailing list [email protected] https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-user
