Experimental? What Does That Really Mean?
Virtualization? What The Heck Is That? - Chapter 06
VMware does an interesting thing. It mixes alpha and beta code with general release code. Alpha? Yes, alpha because what VMware calls beta code at times is not what I would call beta code. However, the definitions come later, so bare with me. This inclusion of experimental code, cough beta, cough sometimes alpha code, has been around for years in VMware products, and from my perspective is both good and bad. Good in the sense that we get to see features and methods that will become core to the VMware products, one such feature that comes to mind the quickest is VirtualCenter not integrating support for experimental features that are on VMware ESX today, for example thin-disking use. You can create thin-disks today for virtual instances via the ESX service console CLI using vmkfstools, however, the VirtualCenter/Virtual Infrastructure client does not allow this within the virtual machine (instance) wizard, nor does VC/VI report the delta between what the guest OS understands and what is actually thin-disked allocation, so operational teams can thin-disk allocate themselves into a nasty situation that they can not see coming. Why does this difference exist? In short, thin-disking is experimental.
Experimental code in a general release is bad, because it violates a number of best practices rules. There are firms, corporations, out there that will decline a solution or product if it has any alpha or beta code that can end up in a production context. Even if the alpha/beta code is not leveraged, it very existence disqualifies the complete general release code base. This is fact not fiction. Check with our organization, ask your vendor product management team, or service vendor support team, I think you be surprised that in the small print this issue is well noted, and more to the point, enforced.
Now I am sure some of you are saying, experimental is not beta, well, it is. Per VMware documentation…VMware includes certain ‘experimental features’ in some of our product releases. These features are there for you to test and experiment with. We do not expect these features to be used in a production environment….I call that beta by definition, by intent, and by meaning, and since what VMware calls beta, I at times see as alpha? Well? I did tell you definitions would come later, here they are, but I digress. To be fair, VMware does offer some support for experimental features, but it is limited, and it is really us providing bug report feedback, more than it is VMware resolving issues realtime. If a known work-around exists, VMware publishes it, with the usual warnings and disclaimers.
So, in effect, VMware is releasing unfinished, rather let us say unpolished features, in general releases. How should this issue be addressed? To keep your vendor product management group from declaring VMware products illegal, I have a few suggestions:
- Experimental code must never be included in general release media. It should be on separate media, making it obvious that is an optional, additional component installation; it should not even be downloaded from the same basic web site location, to further isolate its intentional non-production use.
- Every single feature that is experimental should not be installed by default, from with in the general release installer process. Note, I said not installed. This does not mean, not enabled, disabled, or sitting there but not being used, it means the code is never there in physical sense, unless explicitly installed. No one can accidentally enable or use it.
- Never include experimental code in commands or features that can not be explicitly blocked, locked down, or otherwise disabled if it is installed. This does not side step the point above, it augments it. Meaning that if in a lab or test, non-production context, experimental code is installed it can be completely disabled, thus reverting test environment to a product like environment. Without this feature, duplicate environments would have to be maintained.
- Enable or disable of experimental features is done by global flag as well as feature specific flags. A master XML or configuration command. For example, esxcfg-exp -enable or -disable kills everything in one shot. Where as esxcfg-exp -enable thindisk, just enables thin-disking.
Open source code already scares the pants off of corporate vendor management groups. Weak certification methods by vendors, for example not testing on virtualization platforms, and continued rubber stamping of solutions from vendor to vendor, because strategic alliances are worthless, which results in garbage-in gospel-out scenarios freak everyone out, so why would VMware create this issue in the first place? The reason is straight-forward, VMware never wants to be seen as standing still, they are convinced that if they do not add more and more features, faster and faster that they will lose the race with Microsoft or Citrix or whomever is in the shadows of virtualization just waiting to pounce on the market leader. In some ways it is a surprise to me, why VMware, as strong as VMware is in virtualization, acts like the underdog even today? Winners act like winners, sometimes that is the difference between winning and losing.
I remember at the first VMworld session, in San Diego, what was it VMware 2004? Sitting at a table eating lunch - which was the best food any VMworld has ever had by the way - someone from VMware said, I am omitting the name since I consider the source a friend…“VMware ESX is a strong solution, it basically sells it self.” I remember watching the reaction of all sitting at the table… everyone agreed, as they were stuffing their faces. Maybe it was just the good food? No, the statement is true, today, as it was some four (4) years ago.
We do not need experimental code in general release media, nor in production environments, nor should VMware continue this policy in the future. After all, the general release code is strong…it should sell its-self, right?
Add comment June 5th, 2008
