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):
Steps to Reproduce:
1. Create a DC/CL with more than 1 iSCSI SD provided by the same iSCSI
2. Place 1 of the SDs into maintenance mode
All iSCSI SDs, under the same iSCSI target, will be disconnected because
the target will be logged out
Warn or block the ability to create additional iSCSI SDs if the iSCSI
target is already being used in DC
More information from Simone:
the issue come from VDSM disconnectStorageServer command
that requires a ConnectionRefParameters parameter.
ConnectionRefParameters is a union of different storage specific
parameters, in the iSCSI case we have:
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.
This bug has not been marked as blocker for oVirt 4.3.0.
Since we are releasing it tomorrow, January 29th, this bug has been re-targeted to 4.3.1.
I couldn't find anything related in the current documentation: