in place upgrade 4.4 to 5.x

[stefws]

Thinking it time to consider doing an upgrade from jessie 4.4 to latest 5.1 by following this 'in place upgrade' procedure and wondering if it could be an issue that we're using two corosync rings, HA clustering and shared storage from iSCSI array only?

If anything were to go wrong, could we then remove a failed node from cluster (as if was dead) and the reinstall it from scratch w/5.1 and add it as a new node to the running 4.4 HA cluster?

 

[wolfgang]

Hi,

wondering if it could be an issue

In any upgrade process is a small change an issue occurs.
This is the reason why it is recommended to move any guest away from the upgraded node.

AFIK the are no problem in corosync and HA-manager.
But iSCSI I can't tell because there are multiple implementation of servers out there.

If anything were to go wrong, could we then remove a failed node from cluster (as if was dead) and the reinstall it from scratch w/5.1 and add it as a new node to the running 4.4 HA cluster?

Yes this is working without problems.

PS I would test the iSCSI box on a test installation before you upgrade or new install.

 

[stefws]

Hi,
In any upgrade process is a small change an issue occurs.
This is the reason why it is recommended to move any guest away from the upgraded node.

Of course

AFIK the are no problem in corosync and HA-manager.
But iSCSI I can't tell because there are multiple implementation of servers out there.

Yes this is working without problems.

Thanks good to know!

PS I would test the iSCSI box on a test installation before you upgrade or new install.

Good idea, only haven't got other host to connect to the physical network, worst case we would just have to fall back to recover it as a reinstalled 4.4 node I guess.

What about our present paid support/licenses will they work on 5.x as well, ie. no need to update auth.keys?

 

[wolfgang]

work on 5.x as well, ie. no need to update auth.keys?

Nothing to do in case of an inplace upgrade.

 

[stefws]

Nothing to do in case of an inplace upgrade.

Ok as long as it the same nodes/HW. Great thanks

 

[stefws]

Also what about openvswitch usage, all our single teant VMs are connected to one OVS switch and vlan tagged differently. Would OVS from Strech connect fine to version in 4.4?

 

[wolfgang]

Would OVS from Strech connect fine to version in 4.4?

I never Test this and OVS is always a bit special. I would test this before.

 

[stefws]

It worked fine to do in place upgrade from 4.4 to 5.2, only properly due to the SW watchdog server suddenly rebooted during the pve-cluster upgrade, but dpkg --configure -a continued successfully the upgrade.
After reboot one service fails on 1. boot (maybe due to networking.service failing during boot, though it worked fine after finishing the boot) and repeating with intervals since:

# systemctl status pvesr.service
â pvesr.service - Proxmox VE replication runner
Loaded: loaded (/lib/systemd/system/pvesr.service; static; vendor preset: ena
Active: inactive (dead) since Thu 2018-05-31 08:54:01 CEST; 55s ago
Process: 37128 ExecStart=/usr/bin/pvesr run --mail 1 (code=exited, status=0/SU
Main PID: 37128 (code=exited, status=0/SUCCESS)
CPU: 462ms

May 31 08:54:00 n7 systemd[1]: Starting Proxmox VE replication runner...
May 31 08:54:01 n7 systemd[1]: Started Proxmox VE replication runner.

might this be because currently this is the only pve5 node in our cluster?

Live migration to and from such a pve5 and other pve4.4 nodes works fine.

 

[stefws]

Yes stopping pve-ha-lr.service before upgrading seems to prevent the reboot during upgrade of pve-cluster