See this document – starting on page 91 to page 102. The most important thing to do is make sure you select the correct adapter (page 101). Most documentation is going to show you that you need to select “Microsoft iSCSI Initiator” in the iscsicpl (discovery and targets tabs). This is not correct if you want to use the iSCSI offload functionality of the Broadcom NICs.You need to chose the “Broadcom NetXtreme” device(s) listed in the drop downs. If you select the Microsoft iSCSI Initiator you will still get decent performance – but the iSCSI Offload performance is a decent boost (albeit with a slight impact to CPU performance).
Here’s the difference I saw using iometer — (note – this was done against a iSCSI boot C: drive with a CSV in the cluster volumes directory. I know that’s not good to test against, but its what I had available.)
Without iSCSI Offload:
And with iSCSI Offload
So here’s the basic steps in server core:
- Open BACS and expand the NIC you’re planning to use for iSCSI. There will be a NIC icon and iSCSI icon:
- Highlight the iSCSI Adpapter in the left panel. In the right hand panel select the configuration tab. Default will be IPv4 DHCP. Disable that and manually enter an address (this is easier than figuring out which adapter is which in the next steps). Click Apply at the bottom. Wash, rinse and repeat for your remaining iSCSI adapters.
- Launch the iSCSI Initiator (iscsicpl)
- In the discover portal tab, click Discover Portal –> Enter your SAN IP and port # –> click Advanced –> In the local adapter drop down select your ISCSI adapter (Broadcom) –> in the initator IP make sure you select the IP you assigned in step 2.
- In the targets tab (refresh your targets if its empty) –> highlight your target –> click connect –>Enable mulitpath if needed –> click advanced –> repeat the selections you made in step 4
- You should now see the connections being offloaded in BACS
Cluster Disk 0 does not support Persistent Reservations. Some storage devices require specific firmware versions or settings to function properly with failover clusters. Please contact your storage administrator or storage vendor to check the configuration of the storage to allow it to function properly with failover clusters.
Well that’s just great. Another stepping stone into my hair turning grey and being yanked out at the roots. The above is what I get when I try to validate the cluster I’m building for Hyper-V. Connected are 3 hosts, each with MPIO iSCSI connections to a pair of EqualLogic PS6000 arrays hosting a 2TB LUN for data. I thought I had followed all the correct steps to get this to work… until this happened.
A little searching brought me to this thread
on Technet which basically describes my issue to a T.
The root cause of the problem is the iqn name that is passed to the Equallogic. If you boot diskless and the first 34 characters of your IQN names are identical then you will have this problem with Windows 2008 R2 Datacentre Edition, for clustering.
Somewhere between the Microsoft ISCSI Initiator and the Broadcom driver/Boot ROM the iqn name is being concatenated to 34 characters. So when you attempt to do a Cluster Validation the requests for PR going to the Storage are essentially seen to be coming from the same host by the Equallogic, as the first 34 characters of the iqn names are identical.
So, the workaround is to make sure your IQNs are unique within the first 34 characters. I have adjusted mine to reflect the server names.
The IQN name field is supposed to accept 255 characters. It is unclear at the moment if the problem is a bug in Microsoft or Broadcom. But given the time taken to prove to Dell there actually was a problem….I am happy to go with the workaround.
I’m not going to blame Microsoft at this point… I am beginning to get the suspicion that these Broadcom NICs and drivers/firmware are nothing but complete crap and need to killed with fire.
Following those hints above and setting the IQN for each server to the hostname worked perfectly.