VMware Cloud Community
admin
Immortal
Immortal

Starwind iSCSI target with ESX 4 issue

I have been testing this as a cheap SAN solution for our development environment. We have 14 x 300gb 15k drives in an md1000 that came from our exchange server configured in raid 10 i am wanting to share between two qa/uat esx hosts. I am using version 4 of the software but am finding an issue. It seems if the san for whatever reason is restarted the esx servers will not pick it up again once its back online. I tried refreshing the storage pools as well the storage adapter. Even though the target is listed in the storage adapters I have to manually remove the iscsi target's ip, remove the static mappings and then re-add it to storage adapter and re-create the data store. This is troublesome since although the iscsi host should never need to go down you never know when you may need to restart it for something.

Anyone experienced this or have any suggestions? We are using openfiler for other projects but the two issues there, a) lack of good performance monitoring tools and b) no real way to backup and restore in case of disaster (aside from just copying the config). My novice linux skills keeps me from wanting to move something like this into a rock solid environment,. Our openfilers have done well since I set them up. We have one serving 1.2tb been up for 217 days and one serving 800gb been up for about 180 days so they are solid and stable but still have reservations of putting into an environment that requires higher uptime. Our qa and uat environments are available to external clients so i need something I am confident I can restore easily in case of troubleshooting or sudden unavailability.

Thanks

Reply
0 Kudos
5 Replies
Texiwill
Leadership
Leadership

Hello,

Moved to ESX 4 forum.


Best regards,

Edward L. Haletky VMware Communities User Moderator, VMware vExpert 2009, Virtualization Practice Analyst[/url]
Now Available: 'VMware vSphere(TM) and Virtual Infrastructure Security: Securing the Virtual Environment'[/url]
Also available 'VMWare ESX Server in the Enterprise'[/url]
[url=http://www.astroarch.com/wiki/index.php/Blog_Roll]SearchVMware Pro[/url]|Blue Gears[/url]|Top Virtualization Security Links[/url]|Virtualization Security Round Table Podcast[/url]

--
Edward L. Haletky
vExpert XIV: 2009-2023,
VMTN Community Moderator
vSphere Upgrade Saga: https://www.astroarch.com/blogs
GitHub Repo: https://github.com/Texiwill
Reply
0 Kudos
paithal
VMware Employee
VMware Employee

Could you explain little more on the 'if the san for whatever reason is restarted'?. If it is just a restart and after the re-start, if the target is reachable, it should be picked up by ESX automatically. I suspect, the target may be sending some status that is either confusing the initiator or making the initiator think that target doesn't exist anymore.Even in this case, a manual rescan from VI client should bring the target and data storare online.

Reply
0 Kudos
bboule
Contributor
Contributor

Hello,

I am an engineer over at StarWind Software, could you tell me the exact version and build you are running, also the version of Windows you are running the target software on.

I am sure I can help work through this!

Thanks,

Bob

Bob Boule

StarWind Software

bob.boule@starwindsoftware.com

Reply
0 Kudos
KrisHeath
Contributor
Contributor

Hi All,

I am 'so glad' that someone else has also been having this problem! I get exactly the same thing, albeit in my home test environment

First of all, I appreciate this isn't a 100% real life comparison given that all the components of my VSphere and ISCSI environment get shutdown when I'm not using them. However, it does seem odd that after a reboot connection to the ISCSI volumes is lost.

I have dug around and found the following;

  1. Checking the starwind logs for the connection after a reboot you do see a LOGIN_REJECT line. An exerpt from my logs as follows:
    9/25 21:04:35.842 17d8 C[18], XPT_UP: Login request: ISID 0x00023d000001, TSIH 0x0000.

    9/25 21:04:35.842 17d8 C[18], XPT_UP: Event - LOGIN.

    9/25 21:04:35.843 17d8 C[18], IN_LOGIN: T4.

    9/25 21:04:35.843 17d8 Params: <<< String param 'InitiatorName': received 'iqn.1998-01.com.vmware:esxiv4vm-152c41b3', accepted 'iqn.1998-01.com.vmware:esxiv4vm-152c41b3'

    9/25 21:04:35.843 17d8 Params: <<< String param 'TargetName': received 'iscsidisk2', accepted 'iscsidisk2'

    9/25 21:04:35.843 17d8 Params: <<< Enum param 'SessionType': received 'Normal', accepted 'Normal'

    9/25 21:04:35.843 17d8 Params: <<< Enum param 'AuthMethod': received 'None,CHAP', accepted 'None'

    9/25 21:04:35.843 17d8 T[18,1]: Reject: target 'iscsidisk2' device 'ImageFile1' is not active.

    9/25 21:04:35.843 10c0 C[18], IN_LOGIN: Event - LOGIN_REJECT.

    Checking the properties of the devices in question in Starwind, the "Status" propert shows as inactive.

  2. Rescanning the ISCSI HBA adapter in the VSphere client, just doesn't help...at all.

  3. A work around! Its clunky, but it works.
    When you lose the connection to the device, remove the device from Starwind (Right click, remove)
    Add a new device to the connection, choosing the option to remount an existing image.
    Remount the image and name it exactly as it was named previously (before you removed it)
    Rescan the adapter again in VSphere client and the ISCSI volume will show up again and the datastore will once again be accessible.

I notice that the Starwind engineers hang around these forums quite a bit so, hopefully this info will be of use.

It isn't particuarly clear though where the error lies - with ESXi/VSphere or with Starwinds...

Any help appreciated!!!

Cheers,

Kris.

Reply
0 Kudos
rippleyalien
Contributor
Contributor

I myself am running the Starwind 4.0 free san..

I would get issues with that as well.

I run 4x ESX Servers, and 1 physical Win2k3 Server w\ Starwind running (home lab-- evaluation is thy friend)

1. My workaround - as it would be in a production environment is.

2. Every ESX server has to be off, prior to starting the Starwind server.

3. Once starwind is up, then turn on every esx server.

4.... BUT when you turn off servers, 1. Every esx server - Maintinance mode first.. Then turn off. It is more a Soft iscsi issue, than a ESX or Starwind issue..

Little workaround makes the HA/DRS stop fully funcioning.. Puts the server in maintinance, and allows for safe shutdowns, without the esx server doing scsi/ISCSI scans and such.

In testing, i find the Starwind actually works VERY well.. I have used a VIrtual STARWIND server on a older esx server, and performance was o..k... Meaning, it rocked... Not all the bells and whistles,, yet for a virtual iscsi san, performance was very well.

as a stand alone server, i use a white box q9550, 3gb ram, w\14x 147gb 15k drives.. And it rocks.. the UI, is very basic.. and not a lot of thrills, but then again, main job is the deployment of storage.. i am so looking forward to 5.0.. Can easily hit 100% Nic utilization.. I/O is very decent... In testing i can at a whim reboot 23+ virtual machines, and performance is expected...Next goal will be to try 3x 128gb SSD drives via the Starwind..

Reply
0 Kudos