Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 1512583

Summary:	Restore 3.6 backup (HE VM in custom cluster) to 4.0 (HE VM in Default cluster), results in cluster conflict (HE VM indicates running in custom cluster with 0 hosts)
Product:	Red Hat Enterprise Virtualization Manager	Reporter:	amashah
Component:	ovirt-engine	Assignee:	Simone Tiraboschi <stirabos>
Status:	CLOSED DUPLICATE	QA Contact:	meital avital <mavital>
Severity:	high	Docs Contact:
Priority:	high
Version:	4.0.7	CC:	lsurette, michal.skrivanek, mkalinin, rbalakri, Rhev-m-bugs, srevivo, ykaul, ylavi
Target Milestone:	ovirt-4.1.8	Flags:	lsvaty: testing_plan_complete-
Target Release:	---
Hardware:	x86_64
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2017-11-20 13:45:39 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	Integration	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description amashah 2017-11-13 15:16:04 UTC

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.

Comment 5 Michal Skrivanek 2017-11-14 05:59:48 UTC

I do not think we support moving the HE VM anywhere else during upgrade

Comment 6 Simone Tiraboschi 2017-11-20 13:45:39 UTC

--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 ***