• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 716
  • Last Modified:

Vmware 4.1 cannot connect to ISCSI SAN

Hi All

I hope someone can help me here, we have bought a new QNAP SAN I want to connect to my VMware cluster but unfortunately my VMware servers cannot see the SAN. I have tested this QNAP on a standalone VMware server and it works no problem. The only difference is between the standalone server and the VMware cluster is we had a ISCSI MD3000 attached to the cluster which we had decommissioned. We followed this link http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1029786 to remove the MD3000. The VMware cluster is running our production servers and none of the servers in the cluster can be restarted any time soon.

If anyone can help me here that would be great!

Thanks
0
TazzEE
Asked:
TazzEE
  • 6
  • 5
  • 2
  • +1
1 Solution
 
vmdudeCommented:
Hi,

Just so I understand, what storage are the production servers running on at the moment?

Having one or more iSCSI sans attached to a cluster will cause no problems at all.

Are you using software or hardware initiatiators? Have you added the SANs IP address to the Dynamic discovery on the initiator?
0
 
IanThCommented:
you will need to shut down the cluster to remove the san imho
0
 
TazzEEAuthor Commented:
Thanks for the quick reply,

My production servers are running on a fibre SAN separate from the ISCSI bit. I have added the SAN's IP in the dynamic discovery on the initiator but when I click on "Rescan All" nothing comes up.

I can vmkping the SAN's IP from all the servers but when I run mc -z xxx.xxx.xxx.xxx 3260 it does not return anything.

Just for a test I tried changing the ISCSI IP's range and 2 of the server can see the new SAN but the 3rd server cannot.
0
Cyber Threats to Small Businesses (Part 1)

This past May, Webroot surveyed more than 600 IT decision-makers at medium-sized companies to see how these small businesses perceived new threats facing their organizations.  Read what Webroot CISO, Gary Hayslip, has to say about the survey in part 1 of this 2-part blog series.

 
IanThCommented:
can the host (3) ping the san ip address ?
0
 
vmdudeCommented:
So changing the ISCSI IP has resolved the issue on 2 of the 3 servers in the cluster?
Can you see the storage paths for the iSCSi initiator for the 2 servers?
Have you got an iSCSI vmkernel port on the 3rd server assuming you are using software initiators? If so is the iSCSI kernel port on the correct VLAN if VLANS are used?
0
 
Andrew Hancock (VMware vExpert / EE MVE^2)VMware and Virtualization ConsultantCommented:
okay if you can ping and vmkping your QNAP SAN, you possibly have connectivity.

can you telnet to the IP Address of your QNAP SAN on port 3260

e.g. telnet <ip address> 3260.

Is the QNAP SAN enabled for iSCSI?
0
 
TazzEEAuthor Commented:
Hi VMDude

Yes I can see the paths and create a datacentre on the 2 servers but the 3rd server does not recognise anything but here is the part that I really done under stand in the 3rd server when I look at the "Static Discovery"  the server has detected all the ISCSI paths?

Yes I'm running software initiator. We aren't using any VLAN's and the setup is exactly the same as the other 2 server.
0
 
Andrew Hancock (VMware vExpert / EE MVE^2)VMware and Virtualization ConsultantCommented:
make sure if the QNAP has the option allow multiple connections to LUNs, this is ticked, also make sure the QNAP has all the IQNs from all your servers added.
0
 
vmdudeCommented:
Hi,

Maybe an obvious one but always worth checking :) Are the volumes presented to the 3rd server from the QNAP?
0
 
TazzEEAuthor Commented:
Yes the QNAP can be presented and it allows multiple connections. Ok I've now changes the ISCSI network to a subnet I've never used before and all the servers can see the QNAP. This make no sense and I've done nothing different? Anyone have an idea why changing the ISCSI IP/subnet would let the servers see the QNAP?
0
 
vmdudeCommented:
You should be able to use the same subnet providing noting else is using any of the iSCSI IP addresses?

Best practice would be to use a different network and VLANs for you iSCSI connection. You don't want the possibility of another admin accidently using one of the iSCSI IP address for another purpose. Also this would stop the storage being presented to any thing you don't want it to be!
0
 
TazzEEAuthor Commented:
My ISCSI network has its own network/switch so its completely separate from any of my other networks. Its just strange when I set my ISCSI network up on 192.168.12.0/24 none of the server can see the QNAP but when I changes it to 192.168.13.0/24 only 2 of the servers could see the QNAP but when I changes it for the 3rd time to 192.168.14.0/24 (I've never used this IP range before on the ISCSI network) all 3 of the servers could see the QNAP

As I said the ISCSI network is completely isolated network.
0
 
vmdudeCommented:
Very strange. If it is on a completed isolated switch then you should have no problems with the range you are using. I'm not too familiar with the iSCSI SAN but from a VMware POV as long as you have the VMkernal ports for iSCSI and the correct ports are configured it will be fine. If it is working on the 192.168.14.0 network range then leave it there.
Without knowing more about the switches and any without reviewing any logs etc, I think this is as far as we are going to get with it.
No reason I know of changing the IP range would make any difference unless there are VLANs involved but if you have never used the 192.168.14.x network before then I doubt that is anything to do with it either!
0
 
TazzEEAuthor Commented:
Yes strange is the word that has been thrown around in my team a few times. I think I'm going to have to leave it on the 14 range for now.

Thanks for your help on this
0
 
TazzEEAuthor Commented:
Not a full resolution
0

Featured Post

2017 Webroot Threat Report

MSPs: Get the facts you need to protect your clients.
The 2017 Webroot Threat Report provides a uniquely insightful global view into the analysis and discoveries made by the Webroot® Threat Intelligence Platform to provide insights on key trends and risks as seen by our users.

  • 6
  • 5
  • 2
  • +1
Tackle projects and never again get stuck behind a technical roadblock.
Join Now