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?
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.