Description of problem: While running refresh LUN from the RHV-M UI, it is using the host from the different data center to rescan the LUN. Since the LUN is not available in that host, it is getting an empty output and new changes are not reflected for this LUN. From the logs, we can see that the GetDeviceListVDSCommand is getting executed on a different DC's SPM host and VM with this direct LUN is configured in a completely different DC. Version-Release number of selected component (if applicable): rhvm-4.3.9.4-11.el7.noarch How reproducible: 100% Steps to Reproduce: 1. Create 2 DC in an RHV-M and create 2 VMs in each of this DC. 2. Attach a direct LUN for both the VMs. 3. Use "refresh LUN" from the RHV-M portal and check in the engine logs where the GetDeviceListVDSCommand is getting executed. We will be able to see that for both the LUNs, it will use same host to scan the LUN although they are attached to VMs in two different DC. Actual results: Refresh LUN is using host from different Data Center to scan the LUN Expected results: Refresh LUN should use the host from the DC where the direct LUN attached VM is configured. Additional info:
*** Bug 1838100 has been marked as a duplicate of this bug. ***
The issue was fixed, steps to reproduce: 1. Create 2 different DC on two diffrent hosts and create one VM in each of these DC. 2. Attach a direct LUN for both the VMs. 3. Power up the VM's. 4. From the disks section under storage chose both of the direct luns and use the refresh Luns option. the operation should be successful(no error messages) and under the engine, logs should be seen for each of the Luns (the hostname in the info should be different for each lun): EVENT_ID: SYNC_DIRECT_LUNS_STARTED(1,054), Direct LUN synchronization started. INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.GetDeviceListVDSCommand] (default task-23) [b7a4c388-91d4-4f52-9b9c-c8e1559414a2] START, GetDeviceListVDSCommand(HostName = pina-colada, GetDeviceListVDSCommandParameters:{hostId='45ad3219-0ca5-4da8-b4c8-d2ca7165cb84', storageType='UNKNOWN', checkStatus='false', lunIds='[3600140550066b7df32e416dbdf2bd3bb]'}), log id: 66201588 2020-07-22 12:23:21,124+03 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.GetDeviceListVDSCommand] (default task-23) [b7a4c388-91d4-4f52-9b9c-c8e1559414a2] FINISH, GetDeviceListVDSCommand, return: [LUNs:{id='3600140550066b7df32e416dbdf2bd3bb', physicalVolumeId='', volumeGroupId='', serial='SLIO-ORG_bella1_50066b7d-f32e-416d-bdf2-bd3bb421b52b', lunMapping='1', vendorId='LIO-ORG', productId='bella1', lunConnections='[StorageServerConnections:{id='null', connection='10.35.0.31', iqn='iqn.2015-01.bella.lostsoulsdomain.com:666', vfsType='null', mountOptions='null', nfsVersion='null', nfsRetrans='null', nfsTimeo='null', iface='null', netIfaceName='null'}]', deviceSize='50', pvSize='0', peCount='null', peAllocatedCount='null', vendorName='LIO-ORG', pathsDictionary='[sdb=true]', pathsCapacity='[sdb=50]', lunType='ISCSI', status='Unknown', diskId='null', diskAlias='null', storageDomainId='null', storageDomainName='null', discardMaxSize='0'}], log id: 66201588 LUNs with IDs: [3600140550066b7df32e416dbdf2bd3bb] were updated in the DB. EVENT_ID: SYNC_DIRECT_LUNS_FINISHED(1,055), Direct LUN synchronization finished.
Verified on engine-4.4.2.1-0.15.
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 (Moderate: Red Hat Virtualization security, bug fix, and enhancement update), 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-2020:3807
Due to QE capacity, we are not going to cover this issue in our automation