Description of problem: Following a storage issue all esxi hosts had to undergo a hard reboot and since then cloudforms has listed 200+ vms as oprhan. they were rediscovered but the metadata isn't associated with the rediscovered vms. Version-Release number of selected component (if applicable): 5.9.5 How reproducible: too specific Steps to Reproduce: 1.hard reboot all esix hosts following a storage issue 2. 3. Actual results: vms previously discovered are marked as orphaned, new vms and old vms that got rediscovered are not associated with previous metadata for the vms Expected results: Additional info: the customer recalls having ran into that issue in the past years ago and a script having been provided to fix the entries and fix the association.
Please assess the impact of this issue and update the severity accordingly. Please refer to https://bugzilla.redhat.com/page.cgi?id=fields.html#bug_severity for a reminder on each severity's definition. If it's something like a tracker bug where it doesn't matter, please set the severity to Low.
https://github.com/ManageIQ/manageiq/pull/18616
https://github.com/ManageIQ/manageiq/pull/18615
New commit detected on ManageIQ/manageiq/master: https://github.com/ManageIQ/manageiq/commit/ae7a083391db158df8e487586688133a48e0d335 commit ae7a083391db158df8e487586688133a48e0d335 Author: Adam Grare <agrare> AuthorDate: Wed Apr 3 16:13:19 2019 -0400 Commit: Adam Grare <agrare> CommitDate: Wed Apr 3 16:13:19 2019 -0400 Return vm records with the same ems_ref first If there is a vm record with the same ems_ref then update that even if it has a different uid_ems. https://bugzilla.redhat.com/show_bug.cgi?id=1695008 app/models/ems_refresh/save_inventory.rb | 6 +- spec/models/ems_refresh/save_inventory_spec.rb | 88 +- 2 files changed, 28 insertions(+), 66 deletions(-)
Okay now we will first select VMs which have the same ems_ref even if they have a different uid_ems so this won't happen again in the future.
Thanks to Adam, I was able to simulate a host reboot using following rails commands. I observed that VM was not orphaned/archived after performing following steps. ems = ManageIQ::Providers::Vmware::InfraManager.find_by(:name => "name of your vc") vm = ems.vms.last puts "ID [#{vm.id}] ems_ref [#{vm.ems_ref}]" vm.update_attributes(:uid_ems => SecureRandom.uuid) Then after a full refresh make sure that VM is active and not archived Verified on 5.11.0.1
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2019:4199