
So, what does this picture mean?
By default, volumes are spread across three members in one pool. So if you have six arrays in a pool, a different combination of three members will be used to handle different volumes.
There is a maximum of 16 nodes in a Hyper-V cluster which means every node in the cluster will get 6 persistent rervervations on a volume (96/16 = 6).
These 6 persistent reservations per node are then spread over a maximum of 3 members in a pool. We will then get 2 connections per member. If we apply redundancy this will result in 1 connection per NIC per Hyper-V cluster node.
If the above is correct then my previous post (http://www.delltechcenter.com/thread/4007957/Microsoft+Windows+2008+R2+CSV+and+Equallogic+SAN/ or http://www.martius.nl/?p=1896) on how to calculate the persistent reservations in wrong. This is because of the spread over max 3 members which actually means no mather how many Equallogics you are using(max. 16 in a pool) only 3 will be used to locate the volume.
The new calculation would then be:
Number of Equallogics = 3 (max spread)
Number of NICs = N
Number of MPIO = M (default HIT = 2)
Number of Servers = S
3 * N * M * S = 96
The numbers will then be:
3 * 2 * 1 * 16 = 96
Obvious question then is why should you use the DSM of Equallogic above the use of the standard Microsoft Multipath capabilities? The Equallogic DSM has a default MPIO per NIC of 2 while only one is available.
Another question is if this is the way Equallogic supports a 16 node Hyper-V cluster?
What are your thoughts? Please share them in getting this Equallogic – Persistent Reservation mystery clarified.
Sometime ago I had an issue with a target on one of my customers servers (Windows Server 2008 Core) and an Equallogic PS5000XV. The issues was the error message below.
Event 7.4.3
ERROR
1-7-09 13:57:28
000-SAN002
iSCSI login to target ’192.168.199.13:3260, iqn.2001-05.com.equallogic:0-8a0906-bbb8ad503-b53d4d74e944a34d-000-srv666-hd00′ from initiator ’192.168.199.103:49913, iqn.1995-05.com.broadcom.iscsiboot’ failed for the following reason:
CHAP user ‘mpio-000-SRV123-0-8a0906-bbb8ad503-b53d4d74e944a34d-91d1a2′ authentication failed.
Obviously somewhere a something went wrong or a bit fell over. Anyhow…this error sucks because little info can be found on the Internet regarding this issue.
What to do?
First of all: Before you start make sure no active applications, services or Virtual Machines are using the iSCSI target on the specific server.
Remove the persistent tartget from the server with is giving the error. In my case ’192.168.199.103′.
- Retrieve the session list with: iSCSIcli sessionlist > C:\Temp\sessionlist.txt. Below my SessionID example:

- Look for the following info: Initiator Name, TargetName and Target Portal for the target that is reporting the issues;
- Fill in the found info in the following iSCSICLI command: iSCSIcli RemovePersistentTarget <Initiator Name> <TargetName> * TargetPortal 3260. In my case this would be: iscsicli RemovePersistentTarget Root\ISCSIPRT\0000_0 iqn.2001-05.com.equallogic:0-8a0906-bbb8ad503-b53d4d74e944a34d-000-srv666-hd00 * 192.168.199.240 3260;
- Log-out all existing sessions that the target is using with: iSCSIcli LogoutTarget <SessionId>. In my case this would be: iSCSIcli LougoutTarget fffffa8029687018-400001370000041d. Logout ALL found SessionID’s for the specific TargetName.
- Open regedit.exe and make a back-up of HKEY_LOCAL_MACHINE\SOFTWARE\EqualLogic\EHCM\MpioChap
- Search in regedit.exe on the troubled server for “‘mpio-000-SRV123-0-8a0906-bbb8ad503-b53d4d74e944a34d-91d1a2″ and delete it! Mine looked like this in an export.

- After delting the registry key rebuild the persistent target on the troubled server to the specific target. Do this with iSCSIcli PersistentLoginTarget TargetName T * * * * * * * * * * * * * * * 0. Mine looked like this iSCSIcli PersistentLoginTarget iqn.2001-05.com.equallogic:0-8a0906-bbb8ad503-b53d4d74e944a34d-000-srv666-hd00 T * * * * * * * * * * * * * * * 0.
As you can check in your Equallogic Group Manager you will find that now for each NIC in your server which is connected to the iSCSI VLAN a Session is made.

The 192.168.199.103 and 192.168.199.104 have been reconnected. Previouslu only the 192.168.199.104 session would show up!
Recent Comments