Virtualization Automation – A Proper Virtual World

Why Do Hypervisor Based Platforms Dominate Virtualization?

March 17th, 2008

Know What Virtualization Is, But What Is Next? – Chapter 10

Why are hypervisor based platforms for virtualization dominating the industry? There are a number of answers that come to mind:

• P2V (Physical To Virtual) Migration Ease
• Avoiding DLL or .NET hell (Yes, .NET Hell)
• Failure of Utility Computing?
• Dominate Operating System Support Gap

Hypervisors are easy for technical personnel to understand at a 1000 foot level. No they are not easy to manage, hard to understand at the 10 foot level, and require extensive skill to architect, design, and integrate as enterprise platforms, never mind support. Of course technical management hates to acknowledge this, but it is true. So, anything that makes some part of virtualization easy is focused on, and in the pursuit of pain avoidance, dominates thinking. This becomes quite obvious when you consider the list of issues that are noted above. Let us explore each a bit more!

Physical-to-Virtual is a given, moving from very old hardware to new virtualized agnostic platforms, is a pain to do unless you have 1GB dedicated pipes and almost painless if you actually have 10GB connectivity. All the variants, P2I (Physical-to-Image), I2V, V2P, I2P, etc., are applicable, no significant changes are done, but the operating system is kept in tact, more importantly the application installations are kept functional. When you have 100s or 1000s of migrations to get done, of course you want to keep is easy and straight-forward. I can not tell you the number of times I have heard business management say, just move my application, I don’t want to re-install or even update the operating system. Most of the time this because they refuse to let the technical teams have the time to do it right, or worse technical management has no clue how to do it consistently, often because they have laid off the knowledgeable staff that really knew the applications in question well.

Avoiding DLL hell, well this does not need much in explanation now does it? But .NET hell does, yes, .NET hell does exist. .NET, as much as Microsoft would like us to believe does almost nothing to fix the basic issues with DLLs. I best .NET hides the say old issues in the details. Worst, it makes things harder to resolve. Microsoft has never resolved the DLL memory loading issues, never changed the memory mapping model for DLLs to established true DLL integration between mismatched frameworks. I could go on, but anyone that has written serious code for the Windows platform understands these points. Microsoft slogan for .NET should be… The .NET Devil is in the DLL Details. Until mismatched DLL issues really disappear, the isolation benefits of hypervisor virtualization will help avoidance of pain.

Failure of Utility Computing? What the heck is this? To put is in simple terms, application instances, application framework components, etc. But it is a bigger issue, when heterogeneous applications are integrated, and way beyond DLL hell scenarios, resource management, process management, communication management, and configuration management are all aspects of utility computing models. Where you have many different applications running together, which may or may not be isolated by time or resource controls is a very difficult nut to crack. Time is often referenced as CPU loading, and resources are often referenced as Memory, Network, and/or Disk IO, now where do these elements come into play? Virtualization of course deals with the same basic issues, hiding such as part of its isolation. True utility computing is the long term future of virtualization, and it makes operating system publishers, like Microsoft freak. This is because the total number of operating system instances running is significantly reduced with true application instancing, and advance resource and time control. The maturing of management tools for utility computing on Windows is horrible, where as Solaris with its Zones implementation it is powerful. Apple Computer had the basic concept in its core Macintosh operating system about 1989. Never mind the fact that quad-cores beg for application instancing and heterogeneous application integration. Why pay for 4 or 8 package quad-cores, and then run 16, 32 or even 48, horrors 64, instances of various operating systems when you don’t have to do so?

Application frameworks, often integrate better controls, Microsoft SQL, IIS, Oracle, etc. and various other similar instancing models developed resource management within themselves, but the operating system was ignored. This is where the dominate operating system gap comes into focus. Any one that has tried to use Windows System Resource Manager knows exactly what I am saying, specifically soft caps, for resource control just do not work. It is quite a shame that Microsoft has not done more with proper application isolation at the operating system level. This is really a maturity issue, of course the methods and tools will improve, but never to the point that they impact operating system sales. Better solutions must come from publishers that do not publish operating systems. The same basic issue comes with storage vendors, in that as they improve thin-disk or imaging methods they actually impact the total number of storage frames they sell, it is just not going to happen the way we all would like to see it. I am sure some will disagree, fine, but until I see Microsoft really create a application virtualization model that does anything beyond the basics, I will keep my current opinion.
I am sure many others will think of additional rationales but the above noted are those most often encountered given my personal experience. Bottom-line, every short-cut coding to market drives, wastes real money in total cost of ownership, whereas coding for market saves total cost of ownership costs. Virtualization based on operating system isolation, which another way of saying hypervisor based virtualization, protects bad coding methods and techniques, shortened testing periods, promoting junk quality assurance efforts, etc., which are core to the entire coding to market model. The guy that invented single instance concept unit testing? Should be whipped with a bamboo cane, it was an excuse that code shop management was just itching for! So much code we have today is poor quality junk, and until this trend for dumping junk into the market is reversed, utility computing will never see the light of virtual day. Hypervisor based virtualization with its inherent operating system and application isolation is the only protection we have.

Entry Filed under: A Proper Virtual World