[ovirt-users] Re: Upgrade procedure for oVirt

On Thu, Jul 30, 2020 at 10:57 AM Yedidyah Bar David <didi(a)redhat.com&gt; wrote: > On Thu, Jul 30, 2020 at 10:47 AM Alex K <rightkicktech(a)gmail.com&gt; wrote: > > > > > > > > On Thu, Jul 30, 2020 at 10:25 AM Alex K <rightkicktech(a)gmail.com&gt; > 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 > >