- iSNS clients (initiators and targets) need to have an IQN address
before they register with the iSNS server.
- Most pre-OS iSCSI initiators available today are not iSNS clients i.e.
they don't register with and/or query iSNS server.
Given this, it seems better to have a DHCP based standardized mechanism
for acquiring the initiator IQN. Based on initial email from Michael,
most pre-OS iSCSI Initiators available today have the capability to be a
Technology Strategist, Network Storage Architecture | Office of the CTO,
Phone: 512.724.4064 (work)
> My 2cents on the issue. Please correct me if I am wrong.
Thank you for participating in this discussion.
> Shouldn't it be possible to configure the isns server with a set of
> possibly regex rules for the control path. If this not possible today,
> then it could possibly be the root to take towards standardizing.
I am not familiar enough with iSNS to comment.
I have been exposed to about about a dozen commercial environments with
some level of iSCSI use/experimentation. I am not aware that any of them
were running iSNS servers.
> This can solve the problem of provisioning for dynamic boot
> with minimum changes to legacy iqn implementations, many of which
> need to relearn to the new iqn mechanism that might end up as a result
> of this discussion.
Frankly, my concern is that Broadcom/IBM already have a non-standard
DHCP Vendor Option work-around for this problem.
Adding a new/standardized InitiatorName DHCP option would not break
existing initiator implementations. Vendors would integrate support for
this new InitiatorName option into their code/firmware releases over
> Instead of changing numerous configurations we could
> simply change the isns server control mechanism.
I need to do some homework regarding iSNS.
iSCSI is still a very small part of the market.
I advocate addressing this deficiency sooner rather than later.