Archive for June, 2008

This Article Will Be A Bit Different?

Virtualization Critical Evaluation – Chapter 01

This article will be a bit different.  How so?  Well, that is both easy to explain and hard to illustrate.  The year 2008 is effectively just past half over.  This is significant, because thoughts about the near future of virtualization come to mind, and how I will communicate to my clients what makes sense and what does not make sense over the next 18 months on paper?  Preparing them for the next 36 months?  Really strategic scope would be 60 months!  There will be long hours with spent with AIX (Dynamic LPARs), Xen (be it RHEL integrated or Citrix aligned), Solaris Zones, even Parallels, and the potential 800 pound gorilla, Hyper-V of Windows 2008 heritage with Microsoft SCVMM as well.  Why?  Because ESX 4.0 and its lean relative ESXi based on 4.0 core must be a winner.  Unfortunately for VMware, as Rome, there are many Huns at the gates of Rome.  I do hold out hope that VMware will have another winner, or I should say a better winner than ever before.  The history of ESX major versions for the most part has been one of best of breed, but the competition is prepared as never before.

VMware, with a few missteps, has achieved a notable hat-trick, 2.5.x, 3.x, and 3.5.x.  I do not quality 2.1.2, not because it was lacking significance, but it was just on the introduction of shared-storage as a serious feature or infrastructure component to virtualization, and was from my perspective the precursor to the serious modern hypervisor trend VMware established with 2.5.x and VirtualCenter 1.x.  This is subjective of course, but VMotion was the single most intriguing and significant feature that VMware has ever implemented, and it came into its own with ESX 2.5x.  As for those missteps?  Well, VirtualCenter comes to mind again, as does VCB, in fact, scaling seems to be a concept that VMware has and continues to struggle with. Including more recent solutions like Update Manager, and even in the core VMware API, which still seems slow for some reason at any significant scale, as I have noted in the past in verbose detail.  Unfortunately, this is where Microsoft can nail VMware to the wall.  The very same wall that has the writing on it, that says…Abandon All Hope, All Ye That Read This Here…if you see complete doom for VMware ahead?

In spite of what others may predict or even believe about my views, I do not yet, see failure for VMware.  VMware has potential, but so does every other virtualization platform.  As other solutions move or prepare to move into application instancing, VMware still holds firm that its future is ESXi and a pure hypervisor-ized vision.  That is dangerous.  Hypervisors will always exist, but will never dominate the industry over time.  VMware keeps its virtual-appliance model, only because it is a fake instance model?  That is a dead end, when any true application instancing solution out performs it hands down, this is where Citrix may be going?  There are just too many strategic reasons to reduce the complexity of virtualization, as only application instancing allows.  How do I know this to be true?  Why the emergence application instancing?  My wish list for 2009 and 2010 are not dependent on hypervisor technology, is why.  The wish list, in simple descriptors is as follows:

  • Reduce the Total Number of Lines of Code Executed!  This is #1
  • Avoid any solution that layers filter drivers upon filter drivers.  This is hard to do!
  • Easy intra- and inter-site recovery, De-Duplication Models for Archival
  • Thin Disking and Imaging, Greater alignment to Storage Arrays
  • Reduced Support Staff (Yes, This Is Reality)
  • Realign instancing back to its roots, Exchange, SQL, etc., all are instancing models that should never be in operating system isolation
  • Utility Computing (Heterogeneous Application Hosting), Application Instancing
  • Grid Computing?  To some degree a solution looking for a problem?
  • Kill dependence on VMFS, Explore other file systems, NFS, iSCSI (Again)
  • Become Even More Green, this is related to #1 (Energy Consumption Must Be Reduced)

How many of these goals is VMware presenting against?  Since LifeCycle solutions are nothing more than creative repackaging, not that many as I see it.  None of these goals or concepts is in any way new.  But achievement of these simple goals still is not consistent throughout the information technology industry or across hardware vendors.  We, all seem to be waiting for something, watching, believing that just around the corner, over the next slight hill; the ultimate solutions, in each scope is there just out of sight, the supreme utopia for those of us that are architects of infrastructure.  Why are we still chasing solutions to problems, not implementing?  I for one, can not continue to wait, VMware VI based on revision 4 must be a quantum leap again.

Remember I said, it is easy to explain, but hard to illustrate?  Well, we do well to itemize the problems, but do not do was well discovering the solutions?  So, we compromise against the options that are available, saying to ourselves, it is just the 80/20 rule, that I can not have everything, everything does not exist.  Food for thought no?  I want my cake, and will eat it too, and I want zero calories with that real sugar taste!  Well, for me, 2009 starts in the later half of 2008, and 2011 will start in 2009, if you understand my inference?  2015 is just not that far away, will you have the right solution, for 2015?  Global Datacenter will be the expectation for 2015.  Yes, I want everything just the way I want it, and to do that, I will have to implement a multiple vendor and tiered virtualization solution platform which may be, no will be, more complex than I want, but is the only way to achieve the efficiency I need.  The operations teams are not going to be happy?

Do I sound sad?  Or is the impression I present a bit dark?  That is reality, providing VMware ESX 4.x is a winner, it may not be as dark as it could be.  My hope is that VMware will spend major time in code validation and quality assurance certification with ESX 4.0, eliminating new introductions of features in 4.0, for inclusion in 4.0.1, 4.0.2, cough, or even 4.5 Update 1, in preference to solid stability.  I hope that VMware has a true instancing model that is a surprise?  Did I mention this all has to happen at a penance of a price?  Dang, knew I forgot something in my wish list…Adding…Everything Has To Be Done On The Cheap.

Add comment June 26th, 2008

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


June 2008
« May   Jul »

Posts by Month

Posts by Category