Soon to be published in Storage Magazine in the Netherlands…
WHEN A CHILD MISBEHAVES
To paraphrase a popular comedian of the late 1990s: of all the things I’ve sacrificed in the course of parenting six children, I miss my mind the most. I know, raising kids is portrayed as a joyous and life fulfilling experience. But those who have been there know that it is not without its challenges , especially when the child begins his or her journey into adulthood – a time marked by two things: extraordinary perception of basic realities, even if these are cast simplistically in black and white, and rebellion against all authority.
The former characteristic, the ability to perceive basic realities, leads to condemnation of the way things are and absolutist clarity about how they should be. The latter, rebellion, often engenders rejection of any nuanced explanations for the status quo and condemnation of authorities that have allowed an imperfect status quo to persist.
I think about these things as I read reports of VMware’s planned initiatives around storage. Like the teenager, they have become a handful for their parent company/majority stockholder, EMC. Many in the industry are wondering when Hopkinton will exert its parental control over the server hypervisor company. Others are simply delighting in the audacity of a technology company with a big bull horn to tell it like it is.
VMware has already made some storage-related moves that many observers (including myself) consider to be cynical, self-serving and misguided. For example, they arbitrarily added commands to the SCSI command set without going through the proper channels for vetting their new primitives in VAAI. The ANSI vetting process, for as slow moving and flawed as it may be, is what keeps SCSI a standard – something that works across all platforms and in the majority of use cases.
VAAI was essentially a play by VMware to try to alleviate the log jam that its hypervisor was creating in funneling guest machine I/O to storage infrastructure. Offloading certain storage activities to “smart” array controllers could, they said, would reduce workload processing requirements shouldered by VMware’s hypervisor by 20% — a good, if self-serving, outcome given the increasing noise level from customers who are complaining about slow performance of their guest machines.
Breaking with the tradition of seeking formal approval for modifying a standards-based protocol, SCSI, was just the beginning. VMware’s implementation also left something to be desired. According to reports I have received, VMware sprung the new SCSI primitives on the storage vendors without warning (even parent company EMC), then they again changed their quasi-standard primitives without a heads up to the storage industry. This had the effect of driving a lot of engineers and array makers nuts.
As a parent, I know that kids are like that: ignoring the “lame” protocols of their elders while seeking to fix things through immediate actions that, while providing instant gratification, are often poorly thought through in terms of broader or longer term consequences. What happens if a VMware customer also has Microsoft Hyper-V or Citrix Xenserver deployed? Are we now required to build separate infrastructure to handle non-standard SCSI commands just for the VMware servers and guested apps, to segregate these data from other workload from non-VMware machines? Kids don’t consider such things, but adults must.
The latest move by VMware is a shot across the bow of all storage array architectures. 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.
Truth be told, VMware, like a teen, sees the messy reality of storage, which is today a costly morasse of different architectures and topologies, services joined at the hip to proprietary controllers that isolate data and functionality on island arrays. This must be addressed if we are ever going to get to a sensible resource allocation model with financial sustainability.
They are also rebellious enough to believe that (1) “VMware is not a product, but a movement” and (2) the corruption of the storage industry needs to be rooted out by bold, sweeping change.
The question that should be asked is whether a VMware world would be any different from a Microsoft world in the end. Remember, for VMware’s initiatives to work to fix what ails storage, all workload must be guested in their hypervisor – a childish dream at best.
Some readers may be confused that I am not embracing the whole “desconstruct the array” thing that VMware is not intending to pursue, since I have long ranted about proprietary array controllers and the isolated islands of data and storage services that it creates. My beef with VMware on this score comes down to two things.
For one, while I am all in favor of array deconstruction, I see moving this functionality into a virtual controller that only works with one application — vSphere in this case — is just as proprietary as leaving this functionality in a proprietary EMC or NetApp head. I have heard this criticism leveled against other storage hypervisors, like my personal fave DataCore SANsymphony-V, but the parallel is not exact. First, for a DataCore to survive, the technologists have learned that they must support all application and OS (and hypervisor) environments and workloads and not a subset of them. Closely related to this is the recognition that the consumer must make the decisions about what services they wish to keep on the storage rig and what features they want to place in the abstracted uber-controller (dare I call it a “storage hypervisor”). VMware used to say it was open and supportive of the infrastructure that the customer had deployed: they just sought to make it more efficient. Now, that is changing as the company articulates a vision for the future that will force consumers to deploy only their product and to use only their meme for LAN/SAN connectivity. (Kind of like the Paul Ryan budget, those who like Social Security and Medicare aren’t going to like it even if they see the costs for storage as out-of-control.)
The other fundamental problem I have with the VMware proposal is that they haven’t proven that they have the chops to do much of anything right — to execute as Gartner says. Their hypervisor is a bunch of microkernels held together with proverbial spit and bailing wire. I am guessing that their smart engineers are thinking that they will just add a few more microkernels and — voila! — storage will be fixed for all. I kind of doubt that — if only because the hardware guys in the industry aren’t about to let it happen.
Moreover, I have been talking with many storage insiders lately who are bitching about the fact that, to get their rigs certified with VMware’s storage APIs, you need to get in line and wait for a VMware engineer to be assigned to your case. That line is very long – some have been waiting for nearly a year.
It is one thing to share my vision of a world in which a storage hypervisor is used to wreck product lock-in with no sacrifice of functionality or performance, but it is entirely another thing to think that you can just layer on some microkernels to the existing flawed and proprietary hypervisor stack and produce an outcome that will serve consumers better than what is available today. If VMware was really so interested in fixing its storage issues, why didn’t they reach out to existing third party storage virtualization engine providers and partner for a solution that would meet the diverse needs of their customers? Are they the victims of not-invented-here or just too immature to understand what a revolution must be to become the new status quo?