Adam, try to see if this is a WebUI problem or not. Not sure what kind of filtering the UI is doing to select the number of datastores to store.
Hi Jan, where in the UI are you looking? If I go to Infrastructure/Datastores I see 15 on both appliances which matches the count in the database.
OK so it doesn't look like just a UI issue, if you go to Infrastructure/Datastores you can see all of the storages, but if you go to the Provider/Datastores you will see less than the full number. This is due to some datastores not being linked back to the ExtManagementSystem. The first issue where you have 15 but only show 14, it looks like you have 1 datastore which is not connected to any hosts. (Storage.all - ExtManagementSystem.first.storages).collect { |s| s.name } => ["do-not-use-datastore"] HostStorage.all.collect { |hs| hs.storage_id }.uniq.count => 14 I'll need to dig into how we associate datastores with the EMS but I'm guessing its through the host which is why that one doesn't show up. Do you know if this is a regression from 5.4? The second issue looks like when a full inventory refresh runs all 14 storages are linked to the EMS, but when targeted refresh runs some of those links are cleared. The datastores are still in the database and the link to the host is still there, but the link to the EMS is removed.
Your second issue is caused during VM targeted refresh, the problem is only the datastores that the VM is on are returned in inventory which causes save_inventory_multi to delete the link between the host and all other datastores on that host. We can change targeted refresh to return all datastores on the host when doing a targeted vm refresh so those links aren't cleared.
Ok, I have it reproduced on my local setup using dev-vc60.cloudforms.lab.eng.rdu2.redhat.com
PR created https://github.com/ManageIQ/manageiq/pull/8675
This shouldn't be a blocker. The workaround is to perform a provider level refresh.
New commit detected on ManageIQ/manageiq/master: https://github.com/ManageIQ/manageiq/commit/3c3db40ccd94a18bf9f95e153a6a88e9c9a6c1db commit 3c3db40ccd94a18bf9f95e153a6a88e9c9a6c1db Author: James Wong <jwong> AuthorDate: Thu May 12 18:05:39 2016 -0400 Commit: James Wong <jwong> CommitDate: Tue May 17 10:22:21 2016 -0400 Fixing VM target refresh loses host's storages https://bugzilla.redhat.com/show_bug.cgi?id=1335462 The original storage_inv_by_vm_inv will pull in storage(s) that the targeted VM is using. The refresh hash will show that host is only related to that VM's storage(s). The save inventory logic will then remove the other host-storage relationships. This is the fix. .../vmware/infra_manager/refresh_parser/filter.rb | 17 +---------- .../vmware/infra_manager/refresher_spec.rb | 35 ++++++++++++++++++++++ 2 files changed, 36 insertions(+), 16 deletions(-)
Verified fixed in 5.6.0.8-rc1 - 5.6.0.8-rc1.20160524155303_f2a5a50. I wasn't able to reproduce the weird behavior anymore.
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-2016:1348