Bug 1542034 - "Failed to determine the metadata devices of Storage Domain" error is shown for every storage domains in 4.1 environment with 4.0 hosts
Summary: "Failed to determine the metadata devices of Storage Domain" error is shown f...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: ovirt-engine
Version: 4.1.8
Hardware: All
OS: Linux
high
medium
Target Milestone: ovirt-4.2.2
: ---
Assignee: Tal Nisan
QA Contact: Elad
URL:
Whiteboard:
Depends On:
Blocks: 1542886
TreeView+ depends on / blocked
 
Reported: 2018-02-05 12:43 UTC by nijin ashok
Modified: 2021-06-10 14:27 UTC (History)
10 users (show)

Fixed In Version: ovirt-engine-4.2.2
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
: 1542886 (view as bug list)
Environment:
Last Closed: 2018-05-15 17:48:28 UTC
oVirt Team: Storage
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHEA-2018:1488 0 None None None 2018-05-15 17:49:44 UTC
oVirt gerrit 87231 0 'None' MERGED core: Don't attempt to parse domain's metadata device if not supported 2020-11-19 02:44:44 UTC
oVirt gerrit 87244 0 'None' MERGED core: Don't attempt to parse domain's metadata device if not supported 2020-11-19 02:44:45 UTC

Description nijin ashok 2018-02-05 12:43:48 UTC
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.

Comment 1 Yaniv Kaul 2018-02-05 12:47:08 UTC
I assume it's a regression?

Comment 4 Tal Nisan 2018-02-06 17:21:47 UTC
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.

Comment 6 Elad 2018-02-21 09:30:27 UTC
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

Comment 7 RHV bug bot 2018-03-16 15:03:15 UTC
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@redhat.com

Comment 11 errata-xmlrpc 2018-05-15 17:48:28 UTC
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

Comment 12 Franta Kust 2019-05-16 13:05:59 UTC
BZ<2>Jira Resync


Note You need to log in before you can comment on or make changes to this bug.