Circling storage in the vSphere

Comment VMware is encroaching on storage array controller functions with vSphere 4. Who knows where it will stop?

VMware has updated its Virtual Infrastructure 3 to vSphere 4 and added new storage functionality to it so that the ESX hypervisor can thinly provision storage to virtual machines (VMs). This means that when an application in a VM is assigned a chunk of storage, a Logical Unit Number (LUN) or volume, it only gets actually delivered a portion of that LUN's capacity; its storage is not fully provisioned, but doled out over time in sections as its initial allotment becomes filled with data.

The idea behind this is that an empty amount of storage capacity is set aside for applications when they are first provisioned and it is wasteful to have a fully provisioned LUN be mostly empty for a long period of time. If the space can be reclaimed through thin provisioning then it can be allocated to other applications, so driving up storage resource utilisation. When the array does need additional capacity then more drives can be bought, at a time in the future when they will probably be cheaper on a per GB basis.

The interesting thing here is that some storage arrays thinly provision applications when a LUN is requested from them, and some don't. What vSphere is doing is thinly provisioning all arrays that are connected to the VMware hypervisor. So it is doing what thinly provisioning array controllers do.

The vSphere 4 product includes data recovery through replication. Some array controllers provide replication, some do not. VMware is providing it irrespective of the storage array controller functionality.

VMware's vSphere 4 partners include 3PAR, EMC, HDS and Netapp, who all ship thin provisioning array controllers and also include replication functions on many of their array products. If vSphere 4 customers want thin provisioning or replication they can now buy a non-thin provisioning and non-replicating array, and get the functionality from VMware. Why pay extra to an array manufacturer for functionality that's included with VMware?

It appears that VMware is commoditising the storage array. How far down the storage array controller application stack will VMware go? Réza Malekzadeh, the company's senior director in EMEA for product marketing and alliances, was asked this at the vSphere 4 briefing and said: "We can't comment on that today."

He was also asked if vSphere will VMware include a vStorage array controller like the Ciscvo virtual switch for networking? "We're not announcing this today."

What? Let's think about this a second. Cisco went ahead and produced its virtual networking switch. No storage array controller has gone ahead and produced a virtual array controller switch, a vStorage Controller, for VMware, although the HP-acquired LeftHand Networks has a Virtual Storage Appliance, an iSCSI SAN controller implemented as a pre-packed VMware virtual machine. Fat chance of VMware OEM'ing that from HP. It could use an EMC equivalent though ...

Other storage array controllers may be thinking about producing storage array controller packaged as a VM.

The logic of VMware is, I think, to provide a front end for accessing and managing virtualised server, networking and storage functions. It is most advanced with server management, some way down the road with networking management, and has now started down the road of storage management. How far down the storage array controller application stack will it go? To the point that all you need is a virtual storage array controller in ESX looking after just a bunch of disks (JBOD) in an enclosure?

What does converging the provisioning of, access to, use of, and management of virtualised storage resources mean, and where does it lead in a data centre where a data centre O/S looks after the provisioning, access, use and management of virtualised server, networking and storage resources?

One view is that VMware ultimately becomes Lord of all the data centre virtualised resource Rings; one ring to bind them all. Is that Maritz' end game? ®