Unsolved
This post is more than 5 years old
2 Intern
•
294 Posts
0
40575
January 16th, 2012 08:00
Windows Server 2008 R2 Lost A Volume...
Hi,
I was testing out some SQL scripts on the DR site when I got an error in SSMS stating that the Windows OS could not access the TempDB files. I went on Server Manager - Disk Management and rescanned the disks, but the TempDB volume never showed up. I then looked on Group Manager for the SAN and didn't see that volume offline or anything nor did the SAN have any errors. On iSCSI Initiator, the volume was connected so I'm wondering how Windows could "lose" a volume just like that?
I finally got it working by disconnecting to the volume on iSCSI Initiator and reconnecting, then rescanned the disks. The TempDB volume showed up, but SSMS still could not access that volume so I restarted the SQL service. It worked and everything is fine.
I'm just curious if anyone ran into this problem before? Does anyone know why this occurred?
Thank you.
0 events found
dajonx
2 Intern
•
294 Posts
0
January 16th, 2012 09:00
Hi Kenny,
This occurred shortly after my initial post (around 11:20 AM). The volume access is via IP with a wildcard in the 4th octet. All of our volumes (primary SAN and DR SAN) are using IPs with a wildcard in the 4th octet. We have also checked the check box stating "Allow simultaneous connections from initiators with different IQN names"
This is the first time I have encountered this after about a year of purchasing the EqualLogics.
Thank you.
DELL-Kenny K
685 Posts
0
January 16th, 2012 09:00
Hello Dajonx
After reading your post the first thing I would like you to check is the access list for the volume that you were having problem seeing. Is it set up using the IQN, IP or are you using CHAP? If you are using it via IP, are you using a wildcard in the 4th octet? Also can I get a timeline for when the issue started happening?
Thanks
dajonx
2 Intern
•
294 Posts
0
January 16th, 2012 11:00
Even though the SANs are on different subnets (primary and DR)? For example, the DR site has a subnet of 10.1.1.* and the primary site has a subnet of 10.10.10.* which is the value we put in their respective SAN access control list.
And is this the reason why that volume just disappeared on the Windows File System?
dajonx
2 Intern
•
294 Posts
0
January 16th, 2012 13:00
Understood. Is there a document(s) that explains this and the steps to fix it?
dajonx
2 Intern
•
294 Posts
0
January 17th, 2012 11:00
Ok, thank you.
Can you please tell me if this is considered to be safe?
Example: ServerA has an IP of 10.1.1.1 and ServerB has an IP of 10.2.1.1. The SAN has an IP of 10.1.100.1 and the IP Access is 10.1.100.*. Nothing else has the IP range of 10.1.100.* except the SAN. Isn't that the same as using IQNs?
I have created a few volumes with IQN Access and "Allow simultaneous connections from initiators with different IQN names" unchecked. When I look at the connections tab on Group Manager, it is the same as if I used IP Access of 10.1.100.*. (There are four connections with IP addresses of 10.1.100.101 - 10.1.100.104)
dajonx
2 Intern
•
294 Posts
0
January 17th, 2012 12:00
Thank you, Don.
What is the best way to convert the existing volumes to IQN Access as well as removing the "Allow simultaneous connections from initiators with different IQN names"?
Just to clarify, the IQN names that I will be inserting in the Access tab are their respective "iSCSI Target" in Group Manager -> Modify Settings -> Advanced Tab. Is that correct?
dajonx
2 Intern
•
294 Posts
0
January 17th, 2012 13:00
From my test when I had changed the IP Access to IQN as well as uncheck the simultaneous connection box, I received a TON of error messages.
Severity Date and Time Member Message
-------- ------------------ ------ ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
ERROR 1/17/12 4:09:15 PM SAN1 iSCSI login to target '10.1.222.26:3260, iqn.2001-05.com.equallogic:0-8a0906-bd2802609-5bf0019d05d4e9d8-xxxdata' from initiator '10.1.222.103:51653, iqn.1991-05.com.microsoft:serverA.xxx.xx' failed for the following reason: Initiator tried to bypass the security phase but we cannot.