Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

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 seen two approaches to handling the presentation of shared storage to Windows Server 2008 R2 cluster VMs on VMWare vSphere. One is the traditional method of carving out a LUN on your SAN and presenting it to both hosts through the Microsoft ISCSI software initiator. The other method is to make a vmdk on an existing LUN and attach it to both hosts and made it an independent disk so that it isn't affected by snapshots.

Is one way the "correct" way, or are both viable? Is there any advantage or disadvantage to doing either?

share|improve this question
oh such a good question... I hope we get a damn good answer – SpacemanSpiff Mar 28 '12 at 14:29
While I'm not sure if one way is truly more "correct", I've always gone with a separate LUN, if only for the benefit of using the features of my SAN on the volume (snapshots, etc.) – Jim G. Mar 28 '12 at 16:01
@JimG. Wouldn't a snap of the volume that the VMDK is on work just as well? – MDMarra Mar 28 '12 at 16:15
VMware has a whitepaper here: – JakeRobinson Mar 28 '12 at 18:29
Sure it would, but you may want to snapshot on a different schedule than your normal VMFS LUN, or just have a much smaller snapshot if you need to transfer. It's how I do it, but not sure if one way is technically better than another. – Jim G. Mar 28 '12 at 19:08

The "traditional method" is supported when the cluster is across physical machines. The other method is supported when the cluster is on a single VMware host.

share|improve this answer

Both are viable, but as you say there are advantages and disadvantages.

One way to illustrate the difference is to think about vMotion-ing one of the machines in the cluster from one ESXi server to another. In the MS iSCSI initiator case, vMotion will not do anything with the disk. It's just treated as another process on the machine it is moving. However, in the VMDK case, vMotion knows it is a disk and can manage the disk migration along with the machine migration. VMDK has features that make vMotion work better that are not present in the MS iSCSI initiator case.

In the VMDK case, each ESXi server needs to have access to the VMDK if you want to vMotion between them.

I guess if we are talking traditional, the VMDK case is traditionally suited to VMware HA and no MS clustering. The MS iSCSI initiator case is traditionally suited to MS clustering and no VMware HA.

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.