A hosted engine upgrade from 3.6 to 4.0 is an OS change for the Engine VM. The upgrade procedure is expected to be a UI experience to upgrade and sync the process. The VM remains the same VM in the engine DB, but its disk should be a new one with and updated OS, with all certificates and configuration copied-over and after it is all done we switch the hosted engine OVF & DB configuration to point to the new disk. Now a called reboot to the engine VM should point to the newly updated 4.0 VM disk.
*THIS IS AN EXCERPT FROM THE UP-COMMING FEATURE PAGE* *https://github.com/oVirt/ovirt-site/pull/164* # Migration path (proposal): - engine-backup all backup6to7.tar.gz - Add disk to hosted engine VM (Allow that in edit VM?) - extract the disk content from the 4.0 appliance (reuse the setup functionality) - Edit the new disk boot order to boot 1st. Make sure OVF is rewritten - Shutdown the VM using --vm-shutdown and start it --vm-start - put Hosted engine to maintenance mode - VM boots, cloud-init performs engine-setup, and engine-backup restore backup6to7.tar.gz - put hosted engine maintenance mode=none # Revert - hosted-engine --vm-start --vm-conf=vm_with_the_old_disk.conf - Edit engine VM disk boot order, set the old disk to boot 1st or remove the new disk - wait for OVF to persist - restart vm using cli # UI, REST - ?
Moving from 4.0 alpha to 4.0 beta since 4.0 alpha has been already released and bug is not ON_QA.
Simone, is any change needed at ovirt-engine level? I understood nothing required.
Not really on the main flow. Maybe something thee could help on preliminary steps: for instance one requirements is that the hosted-engine storage domain could fit a backup of the engine VM disk to allow the user to quick rollback if something goes wrong. This is almost always true for NFS and gluster but maybe on iSCSI and FC the user has to exten the LUN and resize the VG. Using the engien for that could help.
Target release should be placed once a package build is known to fix a issue. Since this bug is not modified, the target version has been reset. Please use target milestone to plan a fix for a oVirt release.
Just to clarify, verifying this issue should include: 1. Verify on both host types: RHEV-H and RHEL-H 2. Verify on the following storage types: NFS, iCSCI, FC, GlusterFS
this bz is about migration from 3.6 to 4.0, not a tracker for all HE issue like 1364034
Migration works on all storages with EL and hypervisors. Although there's issue with permission as stated in https://bugzilla.redhat.com/show_bug.cgi?id=1364034
Is there a link to the support tool mentioned in the doc text, that I can put in the completed text? Or is it referring to the Upgrade Helper[1], with the assumption that it will include a 3.6 -> 4.0 flow at GA? [1] https://access.redhat.com/labs/rhevupgradehelper/
Upstream it's documented here: https://www.ovirt.org/develop/release-management/features/hosted-engine-migration-to-4-0/
Thanks Simone. Since this will be have a procedure in the documentation, it probably doesn't need a release note. Let me know if you think it does.