Description of problem: "Failed to determine the metadata devices of Storage Domain" is shown for every storage domain in the event panel in a 4.1 environment which is having hosts with vdsm version less than 4.19.x. The "StorageDomain.getInfo" will return "vgMetadataDevice" and "metadataDevice" only from vdsm 4.19.x. The 4.18.x will not report these values as seen below. === jsonrpc.Executor/5::DEBUG::2018-02-05 17:56:42,685::__init__::555::jsonrpc.JsonRpcServer::(_handle_request) Return 'StorageDomain.getInfo' in bridge with {'uuid': 'ad063d42-ba9e-4515-929d-3f6dd0c12628', 'vguuid': 'X7CUCg-yFp6-juim-4WUZ-ROFV-3sRd-GKsAWz', 'state': 'OK', 'version': '3', 'role': 'Master', 'type': 'ISCSI', 'class': 'Data', 'pool': ['dae2555d-f30e-4660-8581-63cc16474d5d'], 'name': 'test_storage'} === As per the https://gerrit.ovirt.org/#/c/77085/, the engine will give error mentioned above if either vgMetadataDevice or metadataDevice are null. Since vdsm doesn't return any values for these variables, we will get the error below in the engine log and the events panel. === 2018-02-05 07:26:42,333-05 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.HSMGetStorageDomainInfoVDSCommand] (org.ovirt.thread.pool-6-thread-11) [2c9783ac] START, HSMGetStorageDomainInfoVDSCommand(HostName = 10.74.130.111, HSMGetStorageDomainInfoVDSCommandParameters:{runAsync='true', hostId='dba8d52f-1524-4f6c-8e30-0115de2990a4', storageDomainId='92227e03-01c8-4f41-999e-032175f20116'}), log id: 7c3b7ca1 2018-02-05 07:26:42,336-05 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.HSMGetStorageDomainInfoVDSCommand] (org.ovirt.thread.pool-6-thread-10) [22fc14b7] FINISH, HSMGetStorageDomainInfoVDSCommand, return: <StorageDomainStatic:{name='test_storage', id='ad063d42-ba9e-4515-929d-3f6dd0c12628'}, dae2555d-f30e-4660-8581-63cc16474d5d>, log id: 79e9e79f 2018-02-05 07:26:42,366-05 ERROR [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] (org.ovirt.thread.pool-6-thread-10) [22fc14b7] EVENT_ID: FAILED_DETERMINE_STORAGE_DOMAIN_METADATA_DEVICES(1,219), Correlation ID: null, Call Stack: null, Custom ID: null, Custom Event ID: -1, Message: Failed to determine the metadata devices of Storage Domain test_storage. === However, the storage domain is having the correct metadata. === pvs -o +pv_mda_free,pv_mda_count,pv_mda_used_count PV VG Fmt Attr PSize PFree PMdaFree #PMda #PMdaUse /dev/mapper/360014053f404fa44d844d9198cfee437 92227e03-01c8-4f41-999e-032175f20116 lvm2 a-- 48.62g 42.38g 0 2 2 === Version-Release number of selected component (if applicable): vdsm 4.18.x rhevm-4.1.8.2-0.1.el7.noarch How reproducible: 100% Steps to Reproduce: 1. Add 4.0 hosts in a 4.1 environment. The error will be shown every time when you activate the storage domain or restart the ovirt-engine service. Actual results: Incorrect error in the events panel of RHV-M with older vdsm version.
I assume it's a regression?
This error is in fact bogus and should be removed: The reduce VG command was introduced in 4.1 and as a requisite there was a need to check what is the metadata device, this info was refreshed every sync of the storage domain LUNs. In an engine that support reduce and a cluster version lower than 4.1 the hosts will not report the metadata device but engine will still try to parse this data and will issue an error since the data is not there For that reason I'm reducing the severity to medium.
Added a 3.6 host to a 3.6 cluster in a 4.2 setup with storage domains in the DC. "Failed to determine the metadata devices of Storage Domain" message is not shown in engine.log. Used: rhvm-4.2.2-0.1.el7.noarch vdsm-4.17.44-2.el7ev.noarch
INFO: Bug status (VERIFIED) wasn't changed but the folowing should be fixed: [Tag 'ovirt-engine-4.2.2.4' doesn't contain patch 'https://gerrit.ovirt.org/87244'] gitweb: https://gerrit.ovirt.org/gitweb?p=ovirt-engine.git;a=shortlog;h=refs/tags/ovirt-engine-4.2.2.4 For more info please contact: rhv-devops
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/RHEA-2018:1488
BZ<2>Jira Resync