Description of problem: A backup of the HE on 3.6 was taken (HE running in cluster 'upgrade'). Per upgradehelper, a fresh install of RHV-H 4 was made (same hardware), when HE was recreated it was in the 'Default' cluster. The 3.6 backup was restored and the HE appeared in the 'upgrade' cluster (which now has 0 hosts but indicates HE is running in it), the HE also appears in the Default cluster when viewing the Hosts tab on manager. Will attach screen shots for clarity. Version-Release number of selected component (if applicable): Currently running 4.1.6, however issue presented during upgrade/restore of 3.6 to 4. How reproducible: Steps to Reproduce: 1. Backup RHV-H 3.6 HE while HE running in a custom cluster. 2. Fresh install RHV-H 4 on same hosts a 3.6 backup was made with (note: HE is now in Default cluster due to fresh install, hosts previously in custom cluster are also now in Default cluster) 3. Restore 3.6 backup Actual results: HE ends up running in a cluster that no longer has any hosts associated with it and cannot be moved. Tried putting these HE hosts in local maintenance and powering down engine, but the HE powered back up in the custom/0 host cluster. Expected results: HE should be running in cluster that the HE hosts are in now (in this case, Default cluster) Additional info: This may cause issues with high availability, as the HE appears to be in a cluster with no hosts, however there are HE hosts that are running in a different cluster (or appear that way at least). No additional flags were used when backup was restored (e.g. --he-remove-hosts and --he-remove-storage-vm flags - added note per question from Simone Tiraboschi.
I do not think we support moving the HE VM anywhere else during upgrade
--he-remove-storage-vm at restore time should avoid it. We have to better document the restore flow but no other code patch is needed. *** This bug has been marked as a duplicate of bug 1482710 ***