VMware Cloud Community
w3nd377
Contributor
Contributor
Jump to solution

VMDK does not show when adding drive but shows on browse of datastore

This may be a simple fix but my forehead hurts from banging my head against the wall and want your expert help.

Environment: Running ESX 4.0 with 4 nodes in the cluster. Each node in the cluster has a single HBA card with dual fiber connections which connect to both sides of the FC SAN. There is not a Fiber Switch between Nodes and SAN, thus direct connect. Built two systems to support Exchange 2007 using SCC. Using a FC SAN for shared drive space and iSCSI for non-shared drive space.

Problem: Have added 5 shard drive spaces onto System #1 using RDM and they show up. Trying to load the same drives into System #2. I am able to load 4 of the drives into System #2 but the 5th drive (which is actually the 3rd drive in the series) refuses to show up when I added the drive. Did the Edit Settings -> Add Hard Drive -> Use existing -> Opened the datastore and folder where the VM files of the system reside and folder where the LUN Mapping are located as they are being stored with the system. But upon opening this folder the LUN mapping in question is absent. All the others show up. However when I right click to browse the datastore outside of editing the settings and go into the folder where the LUN mapping for the virtual drive are located and it shows up.

Attempts to solve:

1) Have removed the drive and delete it from datastore of System #1 and readded it to the system => nothing.

2) Have removed the drive without delete from datastore of System #1 and added it back (thus creating two virtual disks in the folder for the system to the same LUN...xxx_3.vmdk and xxx_7.vmdk) => no success. (xxx_3.vmdk nor xxx_7.vmdk show up when attempting to add a drive)

3) Tried using a system not intended for use within the Exchange SCC cluster, attemtped to add the xxx_3.vmdk or xxx_7.vmdk and both show up as an option.

I am at a total lose. Do I need to trash the System #2 and rebuild? Is there a possible misconfiguration of System #2 that does not allow it to see the two virtual disks? Is the config of System #2 corrupt? Do I need to power System #2 on and off and try again to add the drives? Do I need to power cycle the virtual vCenter system? Or am I that much of a noob that the answer is staring me in the face and I am unable to see it? Any assistance would be welcome.

Reply
0 Kudos
1 Solution

Accepted Solutions
binoche
VMware Employee
VMware Employee
Jump to solution

when you want to use RDM across hosts, please make sure lun number the same across hosts,

for example you have assigned lun 3 from the storage to host A, make sure it is also lun 3 to host B

let me know if it does not fix

binoche, VMware VCP, Cisco CCNA

View solution in original post

Reply
0 Kudos
4 Replies
w3nd377
Contributor
Contributor
Jump to solution

Evidently there is either a glitch in my environment, a "feature" within ESX, or my "n :smileysilly: :smileysilly: b"-ism comes shining through. As an after experiment, I moved the System #2 VM onto the same cluster node as System #1 and now the vmdk #3 and vmdk #7 show up. Makes zero sense to me. Going to make a point from now on of keeping any systems that have to have shard drive space on the same system for building.

If upon getting all drives shard, powered on, and VMotion the System #2 on to a different cluster node and it loses drives, I will be calling Support for some kind of solution.

:smileymischief:

Reply
0 Kudos
binoche
VMware Employee
VMware Employee
Jump to solution

when you want to use RDM across hosts, please make sure lun number the same across hosts,

for example you have assigned lun 3 from the storage to host A, make sure it is also lun 3 to host B

let me know if it does not fix

binoche, VMware VCP, Cisco CCNA

Reply
0 Kudos
w3nd377
Contributor
Contributor
Jump to solution

LUN numbers are the same on each VM on the pair that share the drives. Just checked the Node#2 and it does have dissimilar LUN numbers for the actual drives on the FC SAN. Running "refresh" now on the FC SAN storage connection on Node #2 to determine if it will take the correct LUN numbers to offer to the VM hosts.

Reply
0 Kudos
w3nd377
Contributor
Contributor
Jump to solution

LUN numbers on Node #2 were incorrect, had to re run "rescan" on the HBA connection for the FC SAN twice for the correct LUN number association to be taken for the cluster node. Thought it had taken the correct LUN association, good catch on having me review it again. This issue is resolved.

Reply
0 Kudos