Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I've set up a test environment with server 2008 R2 (virtualized on xenserver) for a server that will use many iscsi volumes (>80) attached in production.

in testing, we ran across an issue where the iSCSI initiator would not attach any more volumes, giving the error "max number of sessions reached". We then added another software initiator to the server, and were able to attach all the volumes to the server. However, with two iscsi software initiators the volumes do not mount on boot. they can be reattached after the server is running with no problem, but they do not attach on startup.

I've tried manually splitting the volumes between the two initiators, using multiple network interfaces, setting everything to auto, enabling/disabling Multipath, adding and removing the volume bindings at various stages of the process, but the only thing that seems to fix this is to disable one of the iscsi initiators. If the secondary initiator is disabled, I can persist the volumes between reboots, but can't get all the volumes I need. Even uninstalling the initiator does not work, as it is recreated on a reboot.

Has anyone seen this behavior with windows iscsi initiators? If so, did you find a fix?

share|improve this question
Hello, could you please tell me: you create second iSCSI Initiator on xenserver, or create it using MS iSCSI Initiator? If you create 2 instances of MS iSCSI ininitator - please tell me how you do this. – Olympian Nov 10 '11 at 16:39
up vote 2 down vote accepted

Since you didn't identify the type of SAN you're using, I can only give a general answer. The most likely problem is that there are a finite number of Persistent Group Reservation (PGR) keys available for assignment. When you reach that limit, persisted connections can fail to reconnect. Limits of 32 or 64 concurrent sessions are common. The limit is typically set by the SAN manufacturer. This would also explain why you can reconnect the sessions, but they do not persist. It would also explain why a second initiator doesn't help.

The only thing I can recommend is contacting your SAN manufacturer to detmine the session limit and adjust accordingly.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.