Description of problem: Running 'hosted-engine --deploy --restore-from-file' on a host, where the host's UUID does not match the UUID saved in the database but the host's name does match a name saved in the database, fails the deployment. Was already reported twice: In the first case, the result was creation of doc bug 1921048 (already fixed and published), second case is [1]. [1] https://lists.ovirt.org/archives/list/users@ovirt.org/thread/QGSBC2P4NVXVZ4C62NXHFEM3ZNTKOR6X/ Version-Release number of selected component (if applicable): Probably "forever" (since very first version supporting restore-from-file, 4.2.7), reported on recent 4.4. How reproducible: Always, I think Steps to Reproduce: 1. Deploy HE on host1 2. Take a backup with engine-backup 3. Restore HE on a host which has a name host1 but a UUID different from original host1's UUID Actual results: 'Remove host used to redeploy' does not remove it, 'Add host' does not add it, and the engine fails to connect to it. Expected results: Not sure. Perhaps try to remove it from the engine database also based on matching host name, perhaps after notifying the user Additional info: Workaround: Prior to starting the deploy/restore, create a file /etc/vdsm/vdsm.id with a copy of the UUID of the host we want to reuse its name. This file can simply be copied from the old host if possible, otherwise the UUID can be found in the database. Thanks to Gianluca Cecchi for verifying and reporting (in above [1]) that this workaround works.
The verification of this type is not feasible for our environment, we don't have the ability to deploy on real hardware on one UUID pinned to specific FQDN and then to change it to another physical host with different UUID with the same FQDN, which we'll have to move from the previous pinning. Base on low PM score this bug will be closed. Please reopen this bug if you still experience any issues related to it. BTW, at the moment QA has ovirt-ansible-collection-2.2.2-1.el8ev.noarch instead of ovirt-ansible-collection-2.2.3-1.
This bug has low overall severity and passed an automated regression suite, and is not going to be further verified by QE. If you believe special care is required, feel free to re-open to ON_QA status.
This bugzilla is included in oVirt 4.5.2 release, published on August 10th 2022. Since the problem described in this bug report should be resolved in oVirt 4.5.2 release, it has been closed with a resolution of CURRENT RELEASE. If the solution does not work for you, please open a new bug report.