Original URL: https://www.theregister.com/2011/09/09/vmware_lun_war/

VMware 'to work with just five storage companies'

Is EMC's stepchild golden, or red-headed?

By Chris Mellor

Posted in Channel, 9th September 2011 12:25 GMT

VMware is planning logical storage containers that do away with Logical UNits (LUNs) and NFS mount points - and could stifle storage developments outside a group of five suppliers.

VMware's plans were disclosed at a VMworld 2011 presentation (VSP3205) and described by Wikibon analyst David Floyer. They have also been discussed by VMware's Scott Lowe in a blog about the VSP3205 session.

Lowe is chief technical officer for EMC's vSpecialist team. His overall view of the presentation is that it explains that VMware wants VM and storage admins to talk the same language and do away with file and block access differences in favour of a unified VMware storage interface.

Traditionally applications request disk or tape storage resources based on Logical UNits, which are storage devices accessed via SCSI, iSCSI, Fibre Channel or similar protocols. A LUN can refer to a logical disk or volume on a SAN, which the SAN drive array controllers convert to real physical disks. There is more on the subject here.

Virtualised app's also use networked file access services via NFS mount points, and the storage container idea gets rid of them as well as LUNs. However, Floyer concentrates on the LUN aspect of things

Storage containers

According to Floyer, what VMware is proposing is that an app, running in a virtual machine, would address a logical storage container, or VM volume, containing the app's data, metadata about it, and any policies referring to that data. The storage container would have logical channels, an I/O Demultiplexer, that is connected to the host server's external storage ports and thence to external arrays.

An app would talk to its storage container and not to a LUN. There would be API access to the storage container constructs so that external arrays, VM-aware arrays storing VM volumes, could do things like spread a storage container across one or more storage drives, one or more storage tiers, one or more storage arrays, and cache infrastructures, all designed to minimise storage I/O latencies, provide protection against device failures, maximise bandwidth delivered to apps, and provide the best storage cost effectiveness.

In effect, the storage container is an external storage controller which abstracts physical storage controllers and connects with them via an extended set of vStorage APIs. Suppliers of such controllers will have to enable them to work with Microsoft and other hypervisors, as well as continuing normal file and block access for non-virtualised applications.

VMware partners

Who is going to get API access to the storage containers? Floyer says VMware is going to work with EMC (which owns 80 per cent of VMware), Dell, Hitachi, IBM and NetApp, and provide the APIs "to help these traditional storage vendors add value, for example by optimising the placement of storage on the disks." There's an obvious missing major storage supplier from that list – HP – plus a whole host of less established players and start-ups.

EMC blogger Scott Lowe leaves Hitachi Data Systems out of the supplier group he mentions, but includes HP.

Floyer uses the term "cartel" for the group of EMC and other suppliers, saying: "The inclusion of the other members of the cartel (and specific exclusion of all others) is justified by reducing the engineering overhead of considering other ideas."

He wants VMware customers, and its shareholders, to tell the company they expect it to help them use the best storage technologies and not baked-in legacy technologies that will benefit the five partner companies more than their customers.

A VMware spokesperson did not agree with the cartel idea, saying: "In terms of the partners we’ve been working with on these APIs, they are Dell, EMC, HP, IBM and NetApp ... – we generally work with this group of storage vendors as “design partners” for these types of initiatives as they represent a diverse set of customers, deployment situations and other technical and logistical factors that greatly help with the vSphere Storage API design process.

"Note that we’re still in early days on this and none of the partners above have yet committed to support the APIs – and while it is our intent to make the APIs open, currently that is not the case given that what was demo’d during this VMworld session is still preview technology." ®

Bootnote

Storage commentator Jon Toigo criticised VMware for arbitrarily changing SCSI commands and for this:-

Their engineers proudly proclaimed at VMworld that they are planning essentially to move array controller functionality, including RAID and other functions that need to be done close to disk, into their software stack. Customers should just deploy JBODs and let the hypervisor do the rest. I wonder what EMC thinks of that bit of wisdom from its golden stepchild.