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.
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.
Removing doctext, as the proposed patch was reverted.
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.