Description of problem: If a host need to be reinstalled for upgrade flow, it could be handy to know and have saved its iSCSI initiator name. It seems it is forgotten from time to time to configured iSCSI initiator name on hosts during upgrade flow and thus hosts can't access storage.
(In reply to Jiri Belka from comment #0) > Description of problem: > > If a host need to be reinstalled for upgrade flow, it could be handy to know > and have saved its iSCSI initiator name. It seems it is forgotten from time > to time to configured iSCSI initiator name on hosts during upgrade flow and > thus hosts can't access storage. Hi Jiri, Could you please provide sosreport for this one? My impression we provide such data in 'Storage Domain: Luns' session.
(In reply to Douglas Schilling Landgraf from comment #1) > (In reply to Jiri Belka from comment #0) > > Description of problem: > > > > If a host need to be reinstalled for upgrade flow, it could be handy to know > > and have saved its iSCSI initiator name. It seems it is forgotten from time > > to time to configured iSCSI initiator name on hosts during upgrade flow and > > thus hosts can't access storage. > > Hi Jiri, > > Could you please provide sosreport for this one? My impression we provide > such data in 'Storage Domain: Luns' session. just take it from engine db engine=# select vds_name,iscsi_initiator_name from vds; vds_name | iscsi_initiator_name --------------+------------------------------------- 10.37.138.31 | iqn.1994-05.com.redhat:3fa14d217a7 10.37.138.85 | iqn.1994-05.com.redhat:6d43b1499ce1
missed 4.2.1, moving to 4.2.2
Verified on version: ovirt-log-collector-4.2.4-1.el7ev.noarch ovirt-log-collector-analyzer-4.2.4-1.el7ev.noarch
This bugzilla is included in oVirt 4.2.2 release, published on March 28th 2018. Since the problem described in this bug report should be resolved in oVirt 4.2.2 release, it has been closed with a resolution of CURRENT RELEASE. If the solution does not work for you, please open a new bug report.