Description of problem: When specifying portal (portal target group tag) of an iSCSI Storage Connection via REST API, the engine seems to ignore it and always sets to 1, both on creation and update of existing connection. https://access.redhat.com/documentation/en-us/red_hat_virtualization/4.3/html-single/rest_api_guide/index#types-storage_connection Version-Release number of selected component (if applicable): ovirt-engine-4.3.6.6-1.el7.noarch How reproducible: Always Steps to Reproduce: 1. Define a connection, specifying portal: # cat connection1.xml <storage_connection> <address>192.168.153.252</address> <port>3260</port> <target>iqn.2003-01.org.linux-iscsi.storage.x8664:sn.f39f33014c8b</target> <type>iscsi</type> <portal>2460</portal> </storage_connection> 2. Create the connection, the output returned is already missing it: $ curl -X POST -H "Accept: application/xml" -H "Content-type: application/xml" -u admin@internal:redhat --cacert /etc/pki/ovirt-engine/ca.pem -T connection1.xml https://engine.kvm/ovirt-engine/api/storageconnections <?xml version="1.0" encoding="UTF-8" standalone="yes"?> <storage_connection href="/ovirt-engine/api/storageconnections/fa3a9818-cdf0-46f4-b61c-1a7c5f49fc4f" id="fa3a9818-cdf0-46f4-b61c-1a7c5f49fc4f"> <address>192.168.153.252</address> <port>3260</port> <target>iqn.2003-01.org.linux-iscsi.storage.x8664:sn.f39f33014c8b</target> <type>iscsi</type> </storage_connection> 3. Portal is set to 1. Check the DB: # /usr/share/ovirt-engine/dbscripts/engine-psql.sh -c "select id,portal from storage_server_connections" id | portal --------------------------------------+-------- 132f9a8f-d062-4d02-b6a2-706dccd6d6be | 2460 b0aaac7f-3ad2-47cf-ae56-ebcc3afff849 | 1 f823f38b-1612-4bd1-bc07-35573c67d73d | 1 fa3a9818-cdf0-46f4-b61c-1a7c5f49fc4f | 1 <----------- 620e097d-63d7-45be-8be2-2baa5462abf0 | 1 (5 rows) Actual results: tag always set to 1? Expected results: tag set as specified
What is portal group tag? https://library.netapp.com/ecmdocs/ECMP1196995/html/GUID-1F88AA34-5C39-495A-88FB-0ACAB3CB7EB3.html https://library.netapp.com/ecmdocs/ECMP1196995/html/GUID-E12CCC64-FD0A-4A02-8C21-8958DC9E0AFC.html It identifies a portal group within an iSCSI node. All network portals with the same portal group tag in the context of a given iSCSI node are in the same portal group.
I was trying to understand if the portal group matters at all for the connection. For my understanding, it is not required to specify it during connection, so RHV does not specify it. But if the customer does specify it on setup, maybe it matters to them/their storage to have it in future connects as well. IMO, we should test this and see how it works on connect, if we have different than 1 portal group tag set on the storage side. If it can connect without a problem without specifying it, probably this bug does not matter. Otherwise we should fix it.
WARN: Bug status (ON_QA) wasn't changed but the folowing should be fixed: [Found non-acked flags: '{}', ] For more info please contact: rhv-devops: Bug status (ON_QA) wasn't changed but the folowing should be fixed: [Found non-acked flags: '{}', ] For more info please contact: rhv-devops
Verified on engine-4.4.0-0.13.master.el7
WARN: Bug status (VERIFIED) wasn't changed but the folowing should be fixed: [Found non-acked flags: '{}', ] For more info please contact: rhv-devops: Bug status (VERIFIED) wasn't changed but the folowing should be fixed: [Found non-acked flags: '{}', ] 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 (Important: RHV Manager (ovirt-engine) 4.4 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:3247