Red Hat Bugzilla – Bug 1497522
Deleted VM is moved to status Orphan, though it should move to Archived.
Last modified: 2017-12-18 15:30:12 EST
Description of problem: When deleting a VM in RHV, it turn into Orphan, and not Archived, as expected. Version-Release number of selected component (if applicable): CFME-5.7.4/RHV-4.1.7 How reproducible: Easily, manually as well. Steps to Reproduce: 1.Provision from CFME side a VM from template. 2.Retire this VM from CFME side. 3.Refresh the VMs view show the VM status was updated to Orphan. Additional info: * This is a new test, so there is no statistics, that can indicate if this is a regression or not. * On CFME-5.8.2.1, the VM status does move into Archived status, as expected. This problem seem to be CFME-5.7 specific.
Created attachment 1332901 [details] evm.log
Created attachment 1332902 [details] automation.log
Created attachment 1332903 [details] rhevm.log
It looks like this is the issue: [----] E, [2017-10-01T06:24:28.799516 #1198:87d138] ERROR -- : MIQ(ManageIQ::Providers::Redhat::InfraManager::Refresher#refresh) EMS: [rhv_cfme_integration], id: [10] Refresh failed [----] E, [2017-10-01T06:24:28.801149 #1198:87d138] ERROR -- : [NoMethodError]: undefined method `detect' for nil:NilClass Method:[rescue in block in refresh] [----] E, [2017-10-01T06:24:28.801427 #1198:87d138] ERROR -- : /var/www/miq/vmdb/app/models/manageiq/providers/redhat/infra_manager/refresh_parser.rb:236:in `block in host_inv_to_switch_hashes' /var/www/miq/vmdb/app/models/manageiq/providers/redhat/infra_manager/refresh_parser.rb:233:in `each' /var/www/miq/vmdb/app/models/manageiq/providers/redhat/infra_manager/refresh_parser.rb:233:in `host_inv_to_switch_hashes' /var/www/miq/vmdb/app/models/manageiq/providers/redhat/infra_manager/refresh_parser.rb:110:in `block in host_inv_to_hashes' /var/www/miq/vmdb/app/models/manageiq/providers/redhat/infra_manager/refresh_parser.rb:85:in `each' /var/www/miq/vmdb/app/models/manageiq/providers/redhat/infra_manager/refresh_parser.rb:85:in `host_inv_to_hashes'
I tested the latest 57 upstream based on e303bdb8345b8c47f87651f359bcee4a6ab5468f and I was not able to reproduce the issue. I performed following steps: 1. imported cirros template 2. used imported template to create a vm only by providing email and vm name (required info) 3. waited for vm to be provisioned and started 4. stopped the vm 5. retired the vm The vm was properly marked as archived. Are there any specific steps that I need to perform to reproduce the issue?
The steps you mention seem to be similar to mine. Not sure why this is occurring on my env. I suggest to connect your latest 57 upstream to my RHV env, and try to reproduce. I shall send you my RHV details by email.
It was reproduced manually on CFME-5.7.4/RHV-4.1.3, by the steps in the description, using a RHEL7.3 template to create the VM.
Piotr - should it move to POST?
Correct
Verified on CFME-5.7.4.1.20171114202358_de8178a/RHV-4.1.6
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/RHSA-2017:3484