2:56 p.m.
On Wed, Nov 22, 2017 at 2:46 PM, Cam Wright <cwright(a)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_Upgr...
- 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(a)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(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/users
--
Didi