Bug 1654752

Description of problem:

disconnectStorageServer command, in the iSCSI type case, disconnects the 
entire iSCSI target

If we have different iSCSI SDs served by the same iSCSI target, placing 1
SD into maintenance mode would disconnect the entire target and additional
SDs provided by the same target will be logged out.


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

RHV 4.2.7

How reproducible:

100%

Steps to Reproduce:
1. Create a DC/CL with more than 1 iSCSI SD provided by the same iSCSI 
target

2. Place 1 of the SDs into maintenance mode


Actual results:

All iSCSI SDs, under the same iSCSI target, will be disconnected because 
the target will be logged out

Expected results:

Warn or block the ability to create additional iSCSI SDs if the iSCSI 
target is already being used in DC


Additional info:

More information from Simone:

the issue come from VDSM disconnectStorageServer command
https://github.com/oVirt/vdsm/blob/master/lib/vdsm/api/vdsm-api.yml#L9549

that requires a ConnectionRefParameters parameter.
ConnectionRefParameters is a union of different storage specific 
parameters, in the iSCSI case we have:
https://github.com/oVirt/vdsm/blob/master/lib/vdsm/api/vdsm-api.yml#L9549

The issue is that IscsiConnectionParameters contains
portal IP, portal port, tgpt for target portal group, target IQN, username 
and password BUT NOT the LUN guid.

So the disconnectStorageServer command (sent by the engine when we set  a 
storage domain in maintenance mode), in the iSCSI case, can only disconnect 
the whole iSCSI target and not just the single SD on a specific LUN.

That's why having two iSCSI SD created on two LUNs exposed by the same 
iSCSI target is considered a bad design.

In the hosted-engine scenario is even worst because that implicit 
disconnectStorageServer on the HE storage domain is also going to pause 
the engine VM in the middle of an operation and this could also potentially 
result in data corruption in the engine VM.