I completed an job a few weeks ago of a 400 seat View implementation at a school district.  This was slightly unusual for me because of the network setup. The equipment is setup in two separate rows of racks.  There are 4 vSphere servers, one Cisco 4948 and a core switch in each row.  The NS-120 is in one of the rows. The two core Cisco switches route to each other.  My task was to get the NS-120 to be the iSCSI target for all the hosts.

Because I couldn’t etherchannel across the core switches I had to connect two ports to each 4948.  Each of these connections was setup as an etherchannel device of two ports each.  I created two interfaces, one on each device with two ip addresses.  Because iSCSI targets do not have the ip address imbedded in their iqn I didn’t see any issues with this.  I set both target ip addresses on each host and masked two LUNs to every host.  All seemed to go well at this point.  Because of the way this View implementation needed to work, I created the datastore from two 1.5TB LUNs.  Again everything went well.  I created the VDMs and VMs needed and tested the whole setup.  It all worked great, with some great i/o throughput.

Two weeks later…………  For a reason I do not know, all the vSphere hosts can no longer see the datastore.  All the hosts can see both LUNs but the DS is gone.  If I wanted to create a new datastore the LUNs are available.  Now I don’t want to do that for obvious reasons.

A ticket has been opened with VMware.  They are pointing towards the NS-120.  I’ve asked the client to open a ticket with EMC.

Visio and jpg attached.

The disks directory looks liike this:

[root@tc-esxvs02 disks]# ls

naa.600508e0000000001d4039277be5c801

naa.600508e0000000001d4039277be5c801:1

naa.600508e0000000001d4039277be5c801:2

naa.600508e0000000001d4039277be5c801:3

naa.600508e0000000001d4039277be5c801:5

naa.6006048c4a6f4d339ec336b5508a0cba

naa.6006048c678c98d1f865294f2e89d77e

naa.6006048c678c98d1f865294f2e89d77e:1

vml.0200000000600508e0000000001d4039277be5c8014c6f67696361

vml.0200000000600508e0000000001d4039277be5c8014c6f67696361:1

vml.0200000000600508e0000000001d4039277be5c8014c6f67696361:2

vml.0200000000600508e0000000001d4039277be5c8014c6f67696361:3

vml.0200000000600508e0000000001d4039277be5c8014c6f67696361:5

vml.02000000006006048c4a6f4d339ec336b5508a0cba43656c657272

vml.02000100006006048c678c98d1f865294f2e89d77e43656c657272

vml.02000100006006048c678c98d1f865294f2e89d77e43656c657272:1

There is only onle one local datastore and one SAN datastore.

SO, my questions are…How do I get the datastore back?. Did I configure this solution in correctly?    I could see no other way to make it work with the setup of the core switches.

It is possible that I will now have to re-implement this whole solution if VMware/EMC cannot retrieve the Datastore.