Why doesn't ESXi see the LUN in my Server 2012 iSCSI target?

[Dajinn]

I don't see what I'm missing here.

In Server 2012, I installed the roles, created the virtual iSCSI disk, selected "create a new target" for this disk, named it, grabbed the IP and IQN of the ESXi host and added them both as initiators, didn't set any authentication, and clicked finished.

In ESXi, I added the software iSCSI adapter, bound it to the available network adapter(i've also tried not doing this), and tried adding both a static and dynamic discovery. However when I add the discovery targets, no attached storage appears in the list and if I go into add storage no LUNs are available..

I've seen some guys mentioning adding something to the hosts file but they weren't clear on if it was supposed to be in ESXi hosts or Windows hosts file so I only tried adding it in the Windows hosts file since ESXi already has itself present in its hosts file.

you can resolve this issue by adding the IP to the storage server host file as follows

ESXIHOSTNAME.DOMAIN.COM XXX.XXX.XXX.XXX XXX.XXX.XXX.XXX

this is cause by iSCSI trying to resolve the host on the domain

However neither Windows or Linux hosts file follows the FQDN before the IP so I wasn't sure at any rate what exactly he meant...

Is there some ridiculously easy step I overlooked that isn't mentioned in any of these tutorials? Am I supposed to do something with the .vdhx file that Server 2012 creates for the iSCSI virtual disk? I've confirmed that the ESXi host is able to ping and connect to the target on the IP/port. I've tried adding CHAP authentication as well, no go. I'm not really getting any good indication from ESXi on whether or not it actually can see the target or not aside from the networking troubleshooting I've done in the shell.

Can the iSCSI adapter NOT be bound to the Management VMKernel network adapter? Do I need to have multiple network adapters configured in fail over for this to work? Is the DISK supposed to be given a drive letter in Windows? lol

Thanks

 

[Dajinn]

In case anyone was wondering, Starwind's Virtual SAN software was causing a conflict with MSFT iSCSI. I uninstalled that and all my problems went away.

 

[pro_IT_2000]

Hey Dajinn, I have actually had the same issue and found a better solution The point is that StarWind can perfectly co-exist with MSFT on the same Windows.

So, in order to change StarWind’s TCP ports, so StarWind could co-exist on the same box with MSFT iSCSI Target, you need to:

1. Open StarWind installation folder. Default path is C:\Program Files\StarWind Software\StarWind
2. Search for StarWind.cfg file and open it (preferably using WordPad opened with administrator rights).
3. Find “<Port value=”3260″/>” and change Port value attribute to another one. Note that variable <Port value> is integer.
4. After the change is done, restart StarWind service in order to apply the change.

I have found this info here and did how StarWind guys advice.

Additionally, MSFT is slow due to having no cache. It also cannot be used in production because of the lack of replication and no certification for vSphere. At the same time, StarWind has the certification (it is on the HCL). In other words, I think that StarWind is a way better product. So, MSFT should buy StarWind and not String Bean years ago

 

[Diavuno]

Hey Dajinn, I have actually had the same issue and found a better solution The point is that StarWind can perfectly co-exist with MSFT on the same Windows.

So, in order to change StarWind’s TCP ports, so StarWind could co-exist on the same box with MSFT iSCSI Target, you need to:

1. Open StarWind installation folder. Default path is C:\Program Files\StarWind Software\StarWind
2. Search for StarWind.cfg file and open it (preferably using WordPad opened with administrator rights).
3. Find “<Port value=”3260″/>” and change Port value attribute to another one. Note that variable <Port value> is integer.
4. After the change is done, restart StarWind service in order to apply the change.

I have found this info here and did how StarWind guys advice.

Additionally, MSFT is slow due to having no cache. It also cannot be used in production because of the lack of replication and no certification for vSphere. At the same time, StarWind has the certification (it is on the HCL). In other words, I think that StarWind is a way better product. So, MSFT should buy StarWind and not String Bean years ago

I setup a couple of 2012 boxes to replicate data and then used them as ISCSI targets... seems to work just fine.