LUN ID management

[sls]

We have a 16TB storage setup in HA mode. Since ESX server doesn't support a LUN is 2TB or greater, we have to create 8 different targets with image file 1.99TB each. That makes the ESX sees 8 different volume from 8 targets. There is a few problems here. StarWind management interface only allows you to create a target that assosciates with an image file and each target only presents to the initiator as LUN 0. In this case, the ESX sees 8 different LUNs with all LUN ID 0. It's very tough to manage the iSCSI LUNs if they all appear to be LUN0 in the ESX environment. The only way to identify which LUN in ESX goes to which image file in Starwind management interface is the read out the iSCSI iqn string carefully on both system.
Comparing to other iSCSI target product in the market, almost all other products allow you to create targets as well as allow you to manage the LUN ID. If you created iSCI targets with different LUN ID, you can much easier to identify each LUN in ESX and the iSCSI target environment.

[Max (staff)]

Hi,
We do not have a multilun configuration so we define the target by the alias,
You can specify a unique alias for each of your targets and differ them switching to the "path ID" using it as a primary disk identifier.

[sls]

In the VMware client interface, under the Storage Adapters screen, the Starwind target appears to be some thing like "ROCKET iSCSI Disk (eui.203c7fa5d91f7dea)". The identifier is eui.203c7fa5d91f7dea and the LUN id is 0. Because all targets are LUN0 and the only difference is the "eui" number. There is no way you can indentify which eui device maps to which target in Starwind storage. In order to indetify the difference between each target, you have to drill down deeper and go into "Manage Path" properties of the target and compare the "iqn" (very long text string) with the "iqn" in Starwind interface.

This way makes the administrator very inconvenient to manage there mission critical device. It also very easy to make mistake when working on the multiple iqn numbers since the iqn number is very long.

Most of the iSCSI products out there use LUN numbers to indentify the different LUN from the same storage. When each target presents with different LUN ID, you can very easy to tell LUN1 is the HAimage disk 1 in Storage and LUN2 is the HAimage disk 2 in storage and such. We don't have to care what eui number is or what iqn number is on the target.

We wish Starwind software developers take seriours looks on this issue and implement LUN control feature in the future software release.

[anton (staff)]

We do take this serios. And V5.4 / V5.5 we ceritfy for VMware ESX/ESXi *HAS* multi-LUN image file based storage. So you'll definitely see this feature in production one day

In the VMware client interface, under the Storage Adapters screen, the Starwind target appears to be some thing like "ROCKET iSCSI Disk (eui.203c7fa5d91f7dea)". The identifier is eui.203c7fa5d91f7dea and the LUN id is 0. Because all targets are LUN0 and the only difference is the "eui" number. There is no way you can indentify which eui device maps to which target in Starwind storage. In order to indetify the difference between each target, you have to drill down deeper and go into "Manage Path" properties of the target and compare the "iqn" (very long text string) with the "iqn" in Starwind interface.

This way makes the administrator very inconvenient to manage there mission critical device. It also very easy to make mistake when working on the multiple iqn numbers since the iqn number is very long.

Most of the iSCSI products out there use LUN numbers to indentify the different LUN from the same storage. When each target presents with different LUN ID, you can very easy to tell LUN1 is the HAimage disk 1 in Storage and LUN2 is the HAimage disk 2 in storage and such. We don't have to care what eui number is or what iqn number is on the target.

We wish Starwind software developers take seriours looks on this issue and implement LUN control feature in the future software release.

[sls]

Fantastic

[anton (staff)]

Doing our best to keep you guys happy

Fantastic