Others may disagree, but our experience has been that mapping raw luns is not a good choice for SQL data and log files because a raw device mapping doesn't provide the same performance as iSCSI connections.
The method that works best for us is your option 2. That's based on our real-world implementation of SQL on VM with EQ SAN arrays. We have experienced problems with the few W2k servers we tried to utilize MPIO on. The W2k servers crashed repeatedly when trying to include the MPIO portion of the iSCSI initiator. This does not occur with W2k3, however. -----Original Message----- From: N Parr [mailto:npar...@mortonwelding.com] Sent: Wednesday, April 22, 2009 8:54 AM To: NT System Admin Issues Subject: For those of you Running SQL on VM Guests with and iSCSI SAN I'm trying to figure out the best way to configure the Data and Log file locations. At least the best for me. Specifically I have an EQ ISCSI SAN but I think my question is pretty universal when it comes to the storage backend. I've asked EQ if they have any white papers that address getting the best performance out of virtualized SQL servers and they said no. I haven't found anything on the VMWare side either. I see two basic options. 1) Map raw luns to the VM Guest. Obviously this would be the way it's done with a physical server. Drawback is you only get a single path to the data because the VM isn't aware of where the Disk you just mapped is physically located. 2) Use the iSCSI initiator inside the VM Guest to map directly to the iSCSI luns. This would allow you to assign two NICS to the Guest for the SAN and use Multi-pathing. This theoretically gives you better performance assuming you have multiple physical NICS between the VM Host and SAN which I do. Can anyone give me some real world insight, is there another way? Either way I can utilize the snap-shotting features of the SAN to cleanly back up my Data. And I've already found the issue and have the fix for getting the iSCSI initiator to load before everything else on a VM so the drives are presented in time. Amazingly Vmware had no clue how to fix that, EQ did. Thanks Niles ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~
