Vladislav Bolkhovitin wrote:
> Vladislav Bolkhovitin, on 03/06/2009 04:19 PM wrote:
>> Vu Pham, on 03/06/2009 02:53 AM wrote:
>>> Vladislav Bolkhovitin wrote:
>>>> Vu Pham, on 03/04/2009 10:53 PM wrote:
>>>>>>> Why is it impossible to identify initiator without wildcard
>>>>>>> matching of the first 16 hex digits of its name?
>>>>>> <TARGET PORT GUID> + <INITIATOR NODE GUID> means that if an
>>>>>> initiator connects via different target port,
>>>>> It is <TARGET PORT GUID + instance#> + <INITIATOR NODE GUID>
>>>>>
>>>>>> it will be considered as another initiator. So, in this case all,
>>>>>> for instance, persistent reservations it had connected to another
>>>>>> target port will not be considered is its. In case of multipath
>>>>>> it will make persistent reservations useless.
>>>>> You can say that it is another initiator; however, multi-path on
>>>>> initiator side will see it as another path to the same target by
>>>>> LUN ID
>>>>>
>>>>> I don't understand why it make persistent reservations useless.
>>> Thanks for your explanation below
>>>
>>>> For instance, consider an initiator and a target with 2 paths each
>>>> configured in failover mode, i.e. if one path failed, another one
>>>> is started being used. If target port participated in the
>>>> initiator's identification, as it is currently, the target sees 2
>>>> different initiators. Call them i1 and i2. The target exports 1
>>>> device.
>>>>
>>>> Now consider that the initiator using path 1 makes a persistent
>>>> reservation of the exported device. Then path 1 failed. Now the
>>>> initiator starts using path 2. But the target will not allow access
>>>> to the device over path 2, because the device is already reserved
>>>> by i1 and i2 isn't allowed to access it. So, now to access the
>>>> device the initiator must reset the reservation. For PRs a simple
>>>> device RESET isn't sufficient.
>>> Correctly the initiator (multipath driver) has to release the PR in
>>> path 1 and re-issue the PR for path 2. I think that vmware esx
>>> multipath driver does that
>>
>> For what? Can you name a spec or describe a usage case, which
>> required that?
>>
>>>> Thus, to correctly identify initiators in MPIO configurations
>>>> target port ID must not participate in the identification.
>>>>
>>>>>>> Its usage is very usual for virtualization. Each VM can have
>>>>>>> different initiator_id and all go thru same physical port.
>>>>>> Can you describe this usage case in more details, please?
>>>>> Out of one physical HBA, I can create multiple virtual VMHBAs and
>>>>> assign each vmhba to different virtual machine.
>>>>> Now different VM can have its own luns
>>>>> Each vmhba will have different initiator ID, we need to derive
>>>>> this ID from <TARGET_PORT_GUID + instance of VM> +
>>>>> <INITIATOR_PORT_GUID>
>>>> Why <instance of VM> + <INITIATOR_PORT_GUID> can't be sufficient?
>>>>
>>> It can not distinguish targets
>>> It can be <instance of VM + TARGET unique ID > +
>>> <INITIATOR_PORT_GUID>; however, it would complicate the srp
>>> initiator driver to identify and manage multiple paths (from
>>> multiple target ports) of the same target with TARGET unique ID. It
>>> also duplicates some of the functionalities of multipath driver
>>
>> Hmm, we are discussing the target part, correct? So, why do you
>> mention the initiator part?
>>
>> Vu, I think, you misunderstand I_T nexus SCSI concept. See SAM/SPC.
>> Each I_T nexus consist from initiator part "I" and target part "T".
>> Each target and initiator keeps necessary internal states,
>> associated with either part. Particularly, reservations on target are
>> associated with particular initiator, i.e. "I". Initiator can also
>> have some information associated with target, i.e. "T". I_T nexus is
>> identified using transport dependent way. E.g., for FC it is
>> initiator port WWN for "I" part and target port WWN for "T" part. For
>> iSCSI it is (InitiatorName, ISID) for "I" and (TargetName, portal
>> group tag) for "T".
>>
>> But for SRP you added target port ID in the "I" part identification.
>> I.e. what you made is IT_T nexus, not I_T as required. To have
>> required I_T nexus SRP initiator must supply to the target SCSI
>> engine, i.e. SCST core, only <instance of VM> +
>> <INITIATOR_PORT_GUID>, not <instance of VM + TARGET unique ID> +
>> <INITIATOR_PORT_GUID>. SRP initiator can keep inside and communicate
>> with SRP target any internal target ID, but SCSI side on the target
>> (SCST core) must not see it. That's simply required by SCSI specs.
>
> Actually, we can argue this way indefinitely. It would be better if
> you simply look in the SRP/IB spec and find out there what should be
> used to identify the "I" part of I_T nexus.
>
SRP/IB spec says initiator_id on I_T nexus is 128-bit:
{initiator_extension, GUID (e.g, IB channel adapter GUID)}
For Linux srp initiator implementation:
initiator_extension: user defined passing as parameter or zero as default
GUID: port guid
For Vmware srp initiator implementation:
initiator_extension: target port guid + VM instance
GUID: port guid
For Windows srp initiator implementation - I don't know. I'll check
-vu
|