[ovirt-users] Upgrading from Hosted Engine 3.6 to 4.X

[Yedidyah Bar David]

On Wed, Nov 22, 2017 at 2:46 PM, Cam Wright <cwright at cuttingedge.com.au> wrote:
>
> Hi there,
>
> We're looking to upgrade our hosted engine setup from 3.6 to 4.0 (or 4.1)...
>
> We built the 3.6 setup a couple of years ago with Fedora 22 (we wanted
> the newer-at-the-time kernel 4.4) on the hosts and engine, but when we
> move to 4.X we'd like to move to EL7 on the engine (as that seems to
> be the supported version) and to the oVirt Node ISO installer on the
> hypervisors.
>
> We've got only four hosts in our oVirt datacentre, configured in two clusters.
>
> Our current idea is to take a backup of the oVirt database using the
> backup-restore tool, and to take a 'dd' of the virtual disk too, for
> good measure. Then upgrade the engine to 4.X and confirm that the 3.6
> hosts will run, and then finally piecemeal upgrade the hosts to 4.X
> using the oVirt Node ISO installer.
>
> Looking at this page -
> https://www.ovirt.org/documentation/self-hosted/chap-Maintenance_and_Upgrading_Resources/
> - it seems the 'hosted-engine --upgrade-appliance' path is the best
> way to do this... but because our hosts are running Fedora instead of
> EL, I think that makes this option moot to us.

Basically yes. You might be able to somehow patch it to enforce
this, not sure it's worth it.

>
> Is what I've suggested a valid upgrade path, or is there a more sane
> way of going about this?

Sounds reasonable.

You didn't mention if you can stand downtime for your VMs or not.
If not, or if you need to minimize it, you should design and test carefully.

If you can, something like this should work:

1. Take down all VMs on all hosts that are hosted-engine hosts
2. Move all hosted-engine hosts to maintenance
3. Remove one hosted-engine host from the engine
4. Take a backup
5. Reinstall the host as el7
6. Deploy new hosted-engine on new storage on this host, tell it to
not run engine-setup
7. Inside the new engine vm, restore the backup and engine-setup
8. See that you can start the VMs on the new host
9. Remove the other host on that cluster, reinstall it with el7, add
10. Handle the other cluster

Plan well and test well. You can use VMs and nested-kvm for the testing.
Do not restore a backup of the real engine on a test vm that has access
to your hosts - it will try to manage them. Do the testing in an isolated
network.

Best regards,

>
> -C
>
> Cam Wright - Systems and Technical Resource Administrator
> CUTTINGEDGE /
> 90 Victoria St, West End, Brisbane, QLD, 4101
> T + 61 7 3013 6200    M 0420 827 007
> E cwright at cuttingedge.com.au | W www.cuttingedge.com.au
>
> /SYD /BNE /TYO
>
> --
>
>
> This email is confidential and solely for the use of the intended recipient.
>   If you have received this email in error please notify the author and
> delete it immediately. This email is not to be distributed without the
> author's written consent. Unauthorised forwarding, printing, copying or use
> is strictly prohibited and may be a breach of copyright. Any views
> expressed in this email are those of the individual sender unless
> specifically stated to be the views of Cutting Edge Post Pty Ltd (Cutting
> Edge). Although this email has been sent in the belief that it is
> virus-free, it is the responsibility of the recipient to ensure that it is
> virus free. No responsibility is accepted by Cutting Edge for any loss or
> damage arising in any way from receipt or use of this email.  This email may
> contain legally privileged information and privilege is not waived if you
> have received this email in error.
>
> _______________________________________________
> Users mailing list
> Users at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/users




-- 
Didi