On Thu, Jul 30, 2020 at 10:57 AM Yedidyah Bar David <didi@redhat.com> wrote:
On Thu, Jul 30, 2020 at 10:47 AM Alex K <rightkicktech@gmail.com> wrote:
On Thu, Jul 30, 2020 at 10:25 AM Alex K <rightkicktech@gmail.com> wrote:
Hi all!
I am going though an upgrade from ovirt 4.2 (4.2.8.2-1.el7) to 4.3 for
a two node cluster with self hosted engine. I have done previously upgrades from 4.1 to 4.2 successfully with minor issues which where fixed.
I wanted to confirm with you, in case I am missing anything that may
have changed in the mean time, on the steps for minor and major upgrade:
# Ovirt procedure for minor upgrade: (4.x.y -> 4.x.z) • enable global maintenance mode • at engine: engine-upgrade-check • at engine: yum update "ovirt-*-setup*" • at engine: engine-setup • at engine: yum update
stop global maintenance
• at each host from GUI: host -> installation -> upgrade • at each host: yum update, reboot, activate
# Ovirt procedure for major upgrade (4.x -> 4.y) • update DC to latest minor version (engine + nodes) • enable global maintenance • at engine: install major version repo: yum install https://resources.ovirt.org/pub/yum-repo/ovirt-release4x.rpm • at engine: engine-upgrade-check • at engine: yum update "ovirt-*-setup*" • at engine: engine-setup • at engine: remove the old ovirt release from /etc/yum.repos.d • at engine: yum update • after completion of engine upgrade disable global maintenance • verify engine version • update each host/node: update to minor, then install new repo, remove old repo, yum update, reboot, activate • after completion of updates: set DC and cluster compatibility level to latest version 4.x. • shutdown guest VMs and confirm they start up again. (you may need to disable guest disk leases or re-activate guest disks) • check events for any issues and fix accordingly
Am I missing anything? I am planning the upgrade hoping to have no issues since the cluster is hosting production VMs.
Also I am concerned about the minor release upgrade for any package conflicts due to CentOS repos (I have not managed yet to simulate this in a virtual environment). The hosts/nodes are CentOS Linux release 7.6.1810 (Core). Do I have to lock the repos to a specific centos version to avoid possible issues (I am afraid CentOS upgrading to latest 7 and causing dependency issues with 4.2 - I was not able to find out the latest CentOS 7 versino compatible with 4.2).
You are right in that this can be a problem. Generally speaking, your best bet is to find out which CentOS 7 was latest when 4.3 was released (or shortly before that) - that's likely the most reliable version for 4.2. Shortly after 4.3 was released, we stopped checking 4.2 with newer CentOS, so things indeed might have broken without anyone noticing.
OK. I will try to figure this out.
What do you mean in "I have not managed yet to simulate this in a virtual environment"? That it fails? Passes? Didn't try yet?
Did not manage to yet test it and find out. In the process of doing so. I recall several dependency issues when going from 4.1 to 4.2. Unfortunately I am not able to keep up with the ovirt upgrades in a timely manner (currently managing around 20 such clusters) hence have to face the issues when I manage to do the upgrades... :) I will have to further streamline the process perhaps through ansible and see if I can at least keep a local repo for such delayed upgrades.
I'd definitely first simulate this in a test (can be virtual) env, before production. If possible, I'd start with a copy of production - and make sure it's an isolated network, so that the tested engine can't mess with your production hosts.
Good luck and best regards,
Thank you Didi
-- Didi