On Wed, Feb 16, 2022 at 5:08 PM Gianluca Merlo <gianluca.merlo(a)gmail.com> wrote:
Il giorno mer 16 feb 2022 alle ore 13:33 Yedidyah Bar David <didi(a)redhat.com> ha
scritto:
>
> On Wed, Feb 16, 2022 at 2:09 PM Gianluca Merlo <gianluca.merlo(a)gmail.com>
wrote:
> >
> > Il giorno mer 16 feb 2022 alle ore 10:22 Yedidyah Bar David
<didi(a)redhat.com> ha scritto:
> >>
> >> On Tue, Feb 15, 2022 at 6:48 PM Gianluca Merlo
<gianluca.merlo(a)gmail.com> wrote:
> >> >
> >> > Hi Jonas,
> >> >
> >> > I would like to say that I also have a 4.4 HE (4.4.5.11-1) that I am
trying to upgrade to the latest one, and have this issue. I read through
> >> >
> >> >
https://lists.ovirt.org/archives/list/users@ovirt.org/thread/D3FEXQ5KOLN3...
> >> >
https://lists.ovirt.org/archives/list/users@ovirt.org/thread/4EBNIFJ3ANER...
> >> >
> >> > but did not manage to get out of the issue. I tried:
> >> >
> >> > - yum remove ovirt-release44
> >> > - Download and install manually (rpm -i)
https://resources.ovirt.org/pub/yum-repo/ovirt-release44.rpm
> >> >
> >> > After this I have regained a functional package manager on the engine.
However trying to go further in the update procedure
(
https://ovirt.org/documentation/upgrade_guide/#Updating_a_self-hosted_eng...)
running
> >> >
> >> > engine-upgrade-check
> >> >
> >> > fails with
> >> >
> >> > > OK: Downloaded CentOS Linux 8 - AppStream
> >> > > FAIL: Failed to download metadata for repo 'appstream':
Cannot prepare internal mirrorlist: No URLs in mirrorlist
> >> > > Error: Failed to download metadata for repo 'appstream':
Cannot prepare internal mirrorlist: No URLs in mirrorlist
> >> >
> >> > So I am stuck in wait of a comment from someone more knowledgeable
too!
> >>
> >> Did you upgrade the machine to CentOS Stream? CentOS Linux archives are
gone.
> >
> >
> > No, I did not do anything apart from trying to fix sources set up from
ovirt-release44. May I ask if you could share some guidance on the process?
>
> Sorry, I only did this on very few development machines, so do not
> have any significant "real life experience" to share.
>
> > I can see that various third parties provide their "guide" on how to
perform the migration, the most "neutral" one I could find is
> >
> >
https://unix.stackexchange.com/questions/552873/how-to-switch-from-centos...
> >
> > but I am having a hard time finding any "official" documentation from
CentOS
>
> I think the "official" doc is:
>
>
https://www.centos.org/centos-stream/ -> Press "8" -> check
> "Converting from CentOS Linux 8 to CentOS Stream 8"
I completely missed that and it was in plain view! It is brief, but gives weight to other
procedures online! Thank you.
I admit I missed it too on first glance. Not sure why... But I was
certain it should be there so looked harder :-).
>
> This is very similar to, and slightly more specific/safe, than:
>
>
https://centos.org/distro-faq/#q7-how-do-i-migrate-my-centos-linux-8-inst...
>
> The stackexchange answer above is also slightly more detailed than
> both of these, based on a specific user's experience.
>
> I definitely recommend trying first on test machines, as similar as
> possible to your production ones.
Fortunately it is not strictly a production environment, I am not in a hurry and can
afford some downtime, but I cannot afford total loss. I will consider if it is possible to
spin up a 4.4.5 setup, but I had some bad luck in the past with a similar scenario
(testing an upgrade of things that were no longer in the mirrors)
Perhaps you remember more details?
Rollback, inside engine-setup, in case it ran into some problem,
indeed relies on having the currently-installed version available for
reinstall.
Generally speaking, when we release new versions, we keep old ones
in-place. This might not be enough, though, depending on external
dependencies availability etc.
that makes me skeptical about the feasibility of the test.
Understood.
> > or oVirt.
>
> You are right - there are no oVirt-specific migration procedures I am aware of.
>
> > May I also ask if this is the way to do it on Hosted Engine (not standalone)
deployments, or may it be that there are easier ways to accomplish this in this scenario
(e.g. redeployment from newer image)?
>
> There is a way, which is to follow the general hosted-engine
> backup/restore procedure. This isn't an in-place upgrade - requires a
> new storage space for the hosted-engine domain, etc.
>
> The appliance that the oVirt project releases is based on Stream since
> 4.4.6 IIRC. Same for ovirt-node - so if you use node, the normal
> upgrade process for it will get you Stream.
>
> > It would be nice to know if there is any documentation I missed on how to best
handle the Centos 8 -> Centos 8 Stream conversion in my case (which is hosted engine on
ovirt-node hosts).
>
> See above. I don't think you'll find anything more specific or
> official. I recommend searching this list's archive - we had several
> relevant threads over the last year - and testing on copies/clones of
> your existing ones, if in production.
Thanks again. I am currently conflicted about choosing one of the following two options
Manually update the engine in-place to CentOS stream then follow the standard ovirt-node
update procedure for hosts. The engine could be kind of a snowflake after this I assume,
but unless a catastrophe happens I assume I should be able to eventually redeploy it from
scratch from a backup down the line if anything goes wrong, once I update nodes (and thus
the engine appliance image). This procedure seems easy, the risk comes from something
unforeseen happening in the CentOS stream upgrade.
Update nodes first, then take advantage of the updated engine appliance image to do a
redeployment of the engine from a backup. This seems safer than the latter, but I am also
doubtful about the possibility of restoring a 4.4.5 backup on a newer version of the
engine, which may break the deal.
This should work, although we by no means test upgrade from/to each
and every possible combination. Should be easy to test on a separate
test machine, though - just install current engine and restore from a
backup with engine-backup. Make sure this test machine does not have
access to your hosts, so that it does not accidentally start trying to
manage them.
Also, I am not sure if updating hosts before the engine is a
supported path.
Not sure it's officially supported, but should generally work, if the
versions are not too far apart.
I think I will review backup/restore procedures just in case, reflect a bit and wait if
someone from the community or the development team has suggestions on these (or
alternative) procedures, just to have further confirmation.
Good luck and best regards,
--
Didi