We have an iSCSI SAN unit connected to a cluster of ESX servers. The servers are all managed by an instance of vCenter. The vCenter instance manages a dozen Windows Server VMs.

Most of the VMs have more than one volume. Those volumes appear in the VM settings in vCenter. Drive C in Windows appears as Hard disk 1 in vCenter. Drive D appears as Hard disk 2, and so on. In other words, the SAN is obfuscated from the servers.

One server, however, is configured differently. Its C drive is handled by vCenter, but its second volume is directly connected to the SAN via Windows iSCSI Initiator. When I asked the server admin why he had configured it that way, he asked, "Why would you want a middleman handling your volumes?" I tried to explain that vCenter's HA and Snapshot features won't cover the second volume, but he remains unconvinced.

I remain unconvinced as well. Though it seems like all the VM's volumes should be handled by vCenter, I could be wrong. Have you configured your VMs in a similar manner? Something where the boot disk is presented to the VM by vCenter, but all other volumes are directly connected to the SAN?

  • I never tried this before but couldn't you configure the SAN volume to be accessible by multiple clients and therefore it could act as "Shared" storage whereas the VMDK could only be accessible to the VM it's attached to? It might not be relevant in your case, but that could definitely be a benefit. – Safado Mar 18 '14 at 20:28
  • Safado - no. You cannot safely share storage like that without using a cluster-aware filesystem. Like, for example, VMFS. – mfinni Mar 18 '14 at 20:34
  • mfinni beat me to the punch. The admin tried to explain that, if the volume is mapped from the VM, we can use the SAN to assign to any other VM if the VM goes down. I tried to explain that's what VMFS is for. – Michael Cornn Mar 18 '14 at 20:44


Sometimes people do this. Reasons may include:

  • SAN/storage performance.
  • Needing a volume whose size requirements exceed the maximums available to VMFS.
  • Clustering that takes place at a higher level than VMware.

vSphere won't be able to snapshot or really do much with these direct-attached volumes. I'm not an advocate of doing this unless absolutely necessary. It causes confusion and complicates networking design, DR and is rarely documented well.

I worked in an environment where a particular client did this on every one of their 900 virtual machines. A dreadful mix of CIFS, iSCSI, NFS presented from multiple SAN arrays directly to the VMs instead of VMDKs.

| improve this answer | |
  • Thanks. The admin gave two specific reasons. First, he said that VMWare can't create volumes larger than 2TB. I counters that the volume is for a backup-to-disk program; if we need more than 2TB of backup space, we can just create another 2TB volume and add it to the pool of backup-to-disk devices. He also said that disk access was faster when the volume is mapped straight from VM to SAN. I countered that, although it might be minimally faster, we won't see a performance difference on a volume that just handles backups. – Michael Cornn Mar 18 '14 at 20:14
  • That's justifiable. I mean, you may not want your backups to live on your primary storage... Performance at the 1GbE iSCSI (assuming) scale is weak anyway, so that may not be a factor. – ewwhite Mar 18 '14 at 20:16
  • As mentioned in my answer, with newer versions of the hypervisor, I/O is mostly limited by the connection to the storage or the storage itself. If you're on a gig network with iSCSI then you'd probably never notice a difference between iSCSI or VMWare handling the drives. No reason not to use VMWare, especially with the new configuration maximums in 5.5. – Mike Naylor Mar 18 '14 at 20:18
  • 1
    A reason not to use VMware VMFS or NFS is if there are different tiers/types of storage or if there's an application that implements its own cluster filesystem (Oracle ACFS, SQL Server cluster). – ewwhite Mar 18 '14 at 20:20
  • @ewwhite, good point. We've not had to use tiered storage so I forgot about that. – Mike Naylor Mar 18 '14 at 20:23

We currently have a file server configured in a similar manner. The boot drive and several others are through VMWare and a data drive is a direct iSCSI connection. It was previously configured this way to overcome the 2TB limits of hard drives in VMWare. And yes, the features of vCenter's snapshot and HA will not apply to that volume as it is presented directly to the server. This has worked fine for us as that 'drive' is covered by snapshots on the SAN.

As far as the middleman comment made by the admin, I'd have to say that there is no issue with performance and no reason not to take advantage of the snapshot and HA capabilities. This article in particular shows that the hypervisor's overhead for storage is minimal. When sending to centralized storage your bottleneck wouldn't be the hypervisor, but the medium connecting the hosts to your storage (fiber, ethernet, etc...) and past that the drives and controllers themselves. The only time I could see the hypervisor becoming a bottleneck is if you've overloaded the host with more virtually allocated resources than it physically has and all VMs calling for them at once. If you're absolutely convinced that the hypervisor would cause a performance issue you can use a direct device mapping. If you take some time to search for them there have been multiple case studies on performance of storage and VMWare.

Personally I've had no issues using VMWare to manage storage, especially with version 5.5 and the new limits on storage. Hope this helps.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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