On Thu, Jul 30, 2020 at 11:08 AM Alex K <rightkickt...@gmail.com> wrote:
> > > On Thu, Jul 30, 2020 at 10:57 AM Yedidyah Bar David <d...@redhat.com> > wrote: > >> On Thu, Jul 30, 2020 at 10:47 AM Alex K <rightkickt...@gmail.com> wrote: >> > >> > >> > >> > On Thu, Jul 30, 2020 at 10:25 AM Alex K <rightkickt...@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. > I find out the following notification email about 4.2 last release: Q+++ The oVirt Project is pleased to announce the general availability of oVirt 4.2.8, as of January 22nd, 2019. This update is the eighth and last in a series of stabilization updates to the 4.2 series. Please note that no further updates will be issued for the 4.2 series. We encourage users to upgrade to 4.3 series when generally available to receive new features and updates. This release is available now for: * Red Hat Enterprise Linux 7.6 or later * CentOS Linux (or similar) 7.6 or later This release supports Hypervisor Hosts running: * Red Hat Enterprise Linux 7.6 or later * CentOS Linux (or similar) 7.6 or later * oVirt Node 4.2 +++Q So I will try locking to latest 7.6 version and fingers crossed! >> 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 >> >>
_______________________________________________ Users mailing list -- users@ovirt.org To unsubscribe send an email to users-le...@ovirt.org Privacy Statement: https://www.ovirt.org/privacy-policy.html oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/message/GINBJEIDV3GONDON4LEHS67TULRUMRNI/
