Bug 1086310

Summary:	iSCSI portal saved as IP and not FQDN in DB
Product:	Red Hat Enterprise Virtualization Manager	Reporter:	Jake Hunsaker <jhunsaker>
Component:	ovirt-engine	Assignee:	Idan Shaby <ishaby>
Status:	CLOSED WONTFIX	QA Contact:	Ori Gofen <ogofen>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	3.3.0	CC:	acanan, amureini, gklein, lpeer, nsoffer, rbalakri, Rhev-m-bugs, scohen, tnisan, yeylon, ylavi
Target Milestone:	---
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:	storage
Fixed In Version:	org.ovirt.engine-root-3.5.0-20	Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2015-08-19 07:36:02 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	Storage	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Jake Hunsaker 2014-04-10 15:14:41 UTC

Description of problem:

The portal for iSCSI targets is saved in the DB as an IP address, rather than FQDN if the FQDN if used to discover the targets

Version-Release number of selected component (if applicable):

rhevm-3.3.0

How reproducible:
Always


Steps to Reproduce:
1. Add an iscsi target as a storage domain using the FQDN to discover the targets
2. Check the storage_server_connections table in the DB (connection column)
3.

Actual results:

'connection' column is entered as the IP address of the FQDN at the time it is added.

Expected results:
The FQDN should be entered

Additional info:

I realize 99% of deployments will be, and our recommendation is to be, a static IP on the targets but this (the FQDN -> IP entry in the DB) seems a bit of an oversight. In instances where a non-static IP is being used and the IP changes, or if infrastructure changes cause a change of IP for the targets, the storage domains to become inactive and all VMs using those targets to pause.

Comment 1 Idan Shaby 2014-11-18 16:04:43 UTC

I added a patch that reverts the first one.
The idea of working with the original address we get from the user instead of the IP address we get from VDSM works fine in case that the iscsi server has only one NIC. When it has more than one (Multipath, for example) the VDSM sends all the addresses it discovered, and we override all of them with the original address we got from the user. This makes the login to all of the other targets fail (except for the first one).
Thus, working with the original address is not possible.

Comment 2 Allon Mureinik 2014-11-18 17:29:45 UTC

Removing doctext, as the proposed patch was reverted.

Comment 4 Idan Shaby 2015-08-19 07:36:02 UTC

Since a storage server should always be stable, I see no reason for a customer to use a non static ip for it. Thus, the whole idea of the ip changing and the storage server not functioning because of it unless using a DSN name is irrelevant.