Dave Welch, CTO and Chief Evangelist

A few weeks ago an industry colleague asked me that question. My answer was immediate: enhancements around VMDK.

This blog entry is not about any new specific features of the code name MN release.

And no, I’m not talking about enhancements to the VMFS file system. It wouldn’t be much of an exaggeration to say that about the only evidence of VMFS’s aging is how many calendar pages have flipped since its last revision under ESX 3.5. No doubt VMFS yet has room for improvement, just as the ESX kernel scheduler had room for improvement when it was completely re-written more granularly for vSphere 4. As the GA VMFS release stands, it’s already capable of a scant 100 microseconds of latency per IO in the hypervisor, and that with linear scalability.

What I’m talking about is the absolute certainty that the list of features that require VMDK storage will continue to expand. That’s going to put all the more pressure on organizations that are worried about keeping a rapid V2P rip cord handy next to their virtual tier-1 production Oracle databases.

Direct-mounted storage and RDM both hold out the possibility of a very rapid replatform to native. Or better yet use either storage paradigm to leave production on vSphere where it belongs and hot-fork a branch to native.

As of 4.1, here’s my list of key features that are only enabled by VMDK, listed in what I would say is their descending order of importance:

• Lab Manager/vCloud Director
• Storage vMotion
• Storage IO Control
• Fault Tolerance

The odds of getting into a Sev-1 yelling match with Oracle Support over vSphere’s presence in a production stack are largely mitigated by proper system stack architecture. Our CEO Nathan Biggs wonders if it is a coincidence that in all the years we’ve been doing this, no House of Brick customer has ever needed to V2P their production Oracle system for support purposes.

VMware is hardware to Oracle. Our team’s day-to-day experience has me thinking that a major purpose of the replatforming language in Oracle’s VMware support statement may be to serve as a legal hedge in the unlikely event that anybody were to ever encounter a VMware hypervisor problem that actually induced an Oracle bug. It doesn’t surprise me that we’ve been seeing a significant up-tick in the number of enterprises determined to virtualize the entire stack.

From my view, there is no significant body of street experience to justify pre-emptively avoiding VMDK out of fear for Oracle Support. To that subset of shops that say “We’re not virtualizing production without a rapid V2P insurance policy,” I’d still say being virtual with restricted storage tooling beats the heck out of being stuck on native. Better yet, if you stick with VMDK, you’re in an expanding crowd of good company.

Side notes on the VMDK-enabled features mentioned above:

Fault Tolerance: I yawn in the Tier-1 space today anytime FT is mentioned. Precious few of our customers’ Tier-1 workloads’ can accommodate their high water marks with a single vCPU. But in some future moment when someone crosses my palm with a SMP FT announcement, in that same moment FT will hold out the prospect of high availability fail-over SLAs of just seconds. As such, SMP FT will demand to be re-evaluated against much more expensive, complex, incumbent RDBMS clustering technologies.

Lab Manager: yes, the vCloud Director source code branch allows multiple data stores under a single configuration of VMs. But I’ll keep promoting Lab Manager until its vCloud Director cousin is enhanced with linked clone capability which I consider critical for the pre-production product development lifecycle. And I’ll continue to advocate that shops pull together single highly-performant data stores underneath Lab Manager until then.

As for Storage vMotion, Storage IO Control or even SAN vendor FC/Solid State dynamic reallocation algorithms, I see great value in each of them. I’m also certain they are not a wise substitute for poor or missing storage architecture. Rather, they should be viewed as nice insurance policies on top of properly-architected storage.