The real pros and cons of server virtualization

The real pros and cons of server virtualization

Summary: PC style virtualization, derived from IBM's zVM ideas and now supported in both AMD and Intel hardware, is a revenant of data processing's failure to adapt to the age of digital computing - an expensive, user punishing, detour into 1920s management ideas in pursuit of that period's holy grail: 100% systems utilization.


First, lets be clear: this comment is about server virtualization through ghosting - the business of using one OS to run one or more ghost OSes in lieu of applications each of which in turn is able to run one or more applications - it's not about desktops, not about N1 type technologies, and not about containerization.

The pre-eminent examples of ghosting OSes are IBM's zVM - an OS that originated in the late 1960s as one answer to the memory management and application isolation problems confronting the industry at the time- and VMware's more recent rendition of the same ideas for x86.

Back then, IBM was caught between rocks and hard places: lots of people (including IBM's own research leaders) were developing system resident interactive OSes aimed at using the computer largely as a central information switch, but its commercial customer base absolutely refused to countenance any advance on the batch tabulation and reporting model around which its management ideas had evolved in the 1920s and 30s.

Thus when the Multics design effort started at MIT in 1959/60, most of IBM's people didn't even know there were two sides to the argument but the research people lined up with science based computing while those who made the money for IBM almost unanimously choose the data processing side - and ten years later, after MIT's people had first won their design battles and then lost the war (by letting data processing get control of the Multics development effort), IBM's own fence sitting solution: VM, ended up roundly hated by nearly everyone.

Nearly everyone, that is, except people limited to IBM 360 class hardware who had no other means of achieving any kind of interactive use (this was before MTS and a dozen later solutions) - and they, essentially over the objections of IBM's own management, made VM the success it still is.

All of which brings us to the 90s when available x86 hardware mostly wouldn't run NT 3.51 and Microsoft's emergency iVMS port, aka 4.0, contained a misconstrued uaf derivative known as registry that effectively limited it to loading one application at a time - thus forcing buyers to choose between a lot of downtime or rackmounts of dedicated little boxes.

The rackmounts won - at least for a few years; but then data processing got took control of the wintel world and VM, in the VMware incarnation of its ideas, soon became the preferred tool for reducing the rackmount count in the name of their professional holy grail: higher system utilization.

Unfortunately there are two big problems with this:

  1. first, NT 4's limitations went away with NT 4 - addressing them today with VMs achieves a level of absurdity no audience would accept in musical comedy -it's right up there with using a licensed terminal emulation on a licensed PC to access a licensed server running a licensed PC emulation; and,

  2. it is very nearly a universal truth that every gain data processing makes in improving system utilization produces a larger loss in IT productivity for the business paying them to do it.

The reductio ad absurdum example of the latter is Linux running under VM on a zSeries machine: data processing can get very close to 100% system utilization with this approach, but the cost per unit of application work done will be on the order of twenty times what it would be running the same application directly on Lintel; and every variable in the user value equation: from response time to the freedom to innovate, gains a negative exponent.

You can see the latter consequence in virtually every result on benchmarks featuring some kind of interaction processing. For example, the Sun/Oracle people behind their recent recent foray into TPC/C, both demonstrated their own utter incompetence as IT professionals by achieving less than 50% CPU utilization and the user value of this "failure" by turning in response times averaging roughly one seventeenth of IBM's:

  IBM p595 Avg Response time in seconds at 6,085,166 tpmC Sun T5440 Avg Response time in seconds at 7,717,510.6 tpmC
New-Order 1.22 0.075
Payment 1.20 0.063
Order-Status 1.21 0.057
Delivery (Interactive) 0.78 0.041
Delivery (Deferred) 0.26 0.021
Stock-Level 1.20 0.090
Menu 0.78 0.044
Values from the detailed reports at

The counter argument I usually hear about all this is that virtual system images are more easily managed than real ones - and this is both perfectly true and utterly specious.

It's perfectly true that VM style virtualization lets you bundle an application with everything it needs to run except hardware, and then move that bundle between machines at the click of an icon; but the simple fact that this applies just as well to Solaris containers as it does to VM ghosts shows that this is an argument for encapsulation and application isolation, not for ghosting.

Worse, the argument is completely specious because it bases its value claims on two demonstrably false beliefs: first that the only alternative is the traditional isolated machine structure, and second that virtualization lets the business achieve more for less. Both are utter nonsense: Unix process management has worked better than VM since the 1970s, and because virtualization adds both overheads and licensing it always costs more to do less than modern alternatives like containerization or simply letting the Unix process management technology do its job.

Again the quintessential example of this is from the heart of the data processing profession: when you take a $20 million dollar zSeries installation and achieve a 60 way split to produce 100% system utilization from 60 logical machines running applications or ghosts, what the business gets out of it is roughly equivalent to what it would get from four Lintel racks costing a cumulative $500,000.

A more down home illustration is provided by VMware itself - their competitive value calculator computes a cost advantage for their products over those from others on the basis of their belief that their VMs impose less overhead and allow you to get closer to 100% hardware utilization. Thus if you enter values saying you've got 200 applications running on NAS connected quad core servers, want to manage virtually, and have average infrastructure costs, they produce a table with this data:

  VMware vSphere 4: Enterprise Plus Edition Microsoft Hyper-V R2 + System Center
Number of applications virtualized 202 205 (inc. mgmt VMs)
Number of VMs per host 18 12
Number of hosts 12 18
Infrastructure Costs $206,571 $280,941
Software Costs $240,951 $181,830
Total Costs $447,522 $462,771
Cost-per-application $2,238 $2,314
Cost-per-application Savings 3%  

All of which should raise a couple of questions in your mind:

  1. first, if the consensus that ghosting doesn't have significant overhead is right, where is VMware getting the third of the box it claims you can recover by getting its ghosting software instead of Microsoft's?

  2. and, second, wouldn't the money VMware wants you to spend on ghosting ($241K in this example) be better spent on hiring people who can move these applications to free environments like Linux or OpenSolaris?

So what's the bottom line? Simple: the real ghost in ghosting is that of 1920s data processing - and the right way to see this particular con job for the professional cost sink it is, is to focus on costs to the business, not ideological comfort in IT.

Topics: Virtualization, Hardware, IBM, Servers, VMware

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.


Log in or register to join the discussion
  • Yep

    VMwear is starting to look like Windoze - adding unneeded functionality just because it can. Moving VMs around from server to server live - is COOL. But why do you need it? If you are on a consolidation binge and utilization is king, then there will be no "extra" capacity to use for this VM move. Most standard DR scenarios utilize development servers to run production - while prod is down. But dev environments are "lightweight" - lower specs than production, so this DR plan usually doesn't work so well.

    VMwear is also replacing *NIX process management. Sun rewrote their entire OS (from BSD-based SunOS to SysV Solaris) JUST to be able to do multi-threading and multi-processor. And that happened more than a decade ago. You would think that Solaris is rock solid now (version 1.0, 1.1, 1.2, 1.3 were unusable ...). So why would you trust VMwear to rewrite this same functionality? And are you willing to shoulder the "growing pains" as VMwear gets the kinks out?

    Don't get me wrong, I am the proud owner of a VMwear 1.0 license. I supported them when very few people were on their side (and I don't pay for much software). Their workstation solution was superior to SoftWindoze/SoftPC emulators, and it allowed us Linux guys to run Windoze under Linux. It kept Linux "in the game" when there was ALWAYS some critical app that HAD to run in Windoze.
    Roger Ramjet
    • Your silly name calling takes away from your

      perfectly valid argument.

      How old are you?
      • Yeah

        I should have said Vmwhere? instead ;)
        Roger Ramjet
  • Right

    Virtualisation was required because MS script kiddies
    couldn't write applications that could co-exist with others
    (lack of ability and poor OS features). Our server rooms
    started filling up with single use servers with low levels of

    Early 2000 I was contracted by a multinational to advise
    windows developers how they could deploy to a managed
    infrastructure platform. You should have heard them
    squeal. With management support I was able to
    consolidate some 100 applications to the platform. The
    only problem was NT's IIS reliability, but simpler to reboot
    a few servers than hundred.

    Today we use clustered Java EE AS / RDMS servers on *nix.
    Windows developers continue to struggle to develop
    applications for such environments, but now we simply
    ignore them.
    Richard Flude
    • *nix is the way to go with VMware

      VMware leads the pack because it works!
      • Agreed

        VMware does seem to be the best at what it does - but very very few people should be doing it.
        • Agree

          VMware cost money, however it is
          cheaper to buy software than continue
          the vicious cycle of hardware.

          Buy good hardware beyond what you need
          'now' and have room to grow out.

          This way you can add blades in with
          time than stand_alone servers.

          I am getting rid of stand_alone servers,
          they are a pain and a source of a
          single point of failure.

          • Hardware

            The reality is that IT budgets are getting slammed. You need to control costs. So, where do you keep the flat line?

            IT staffing is flatlined even beyond their budget requirements. About 80-90% of all IT budgets just go to maintaining existing environments. In terms of modernization, I suspect it is a lot easier to move existing systems onto VM boxes and decommissioning older servers to gain back some of the money through discontinued maintenance contracts.

            That's not an optimal use of the VM environment, but a realistic one. You can generally pull together the skills and equipment to do this fairly fast.

            There isn't an easy way to port to other operating systems. You have to dig through code and that means you need the people and time to do it. There have been a lot of assumptions built into all those numbers posted in this article. Number of VM's per host, size of host server, cost of floorspace, and how the apps are used and their purpose. The reality is that it really does depend on a case-by-case evaluation. You can't generalize beyond a certain point.
          • Pain and failure

            [I am getting rid of stand_alone servers,
            they are a pain and a source of a
            single point of failure.]

            And replacing it with another (VMwhere?). Other than the beancounters and prideful departments (that own the servers), there is no reason why you can't run more than one app on them. Repurpose - don't buy extra software (VMwhere? again).
            Roger Ramjet
    • How is the 20C Richard?

      Appears the rest of us moved on, but you haven't.

      I mean really, Java?

      You must like slow, cumbersome and a 20C UI a lot. Glad to see you are ignoring the Windows developers, both of your developers must be happy ;-)

      • Happy to hear your recommendations

        I'm happy to compare my career against yours. Perhaps you'd like to
        provide some details.

        "Appears the rest of us moved on, but you haven't."

        What have you moved on to? .NET, the Java clone?

        Please enlighten us with your experience of Java EE environments and it's
        Richard Flude
        • Perhaps you could try Ada

          Well my career started in the 70s although my first punch card Fortran was in the 60s. I've worked on mainframes, managed minis (mainly DEC) and installed a Windows network in 1983-84. My main app was written in IBM structured BASIC in 1982 and is now in Version 13 and over a million lines of code (of course it was ported to VB years ago). I've written code in most languages (even a DOS emulator in Forth ;-)) and I've been a Windows developer since Windows began. I looked at Java with a few different development environments and even tried an app or two, but it's tired UI and it's slowness were not attractive. Also the development environments were very primitive compared to MS's Visual UI. It also didn't help that the Java VM seem to be updated every week as they strove to fix things. Finally when MS dropped the JVM it was the final bell. The environment no longer exists on Windows computers, which represent 100% of my client base which is both government and large commercial organisations.

          I've since expanded to HTML/Javascript and ported my player (my main app is an eLearning authoring system) to the Web as well as moving our old storage formats to XML. I've had the duty of also developing code to run on all the browsers and other OSs - even my bete noir - the Mac.

          So I hope that's given you some idea of my history and my opinion of Java ;-)

          • Things sure would have been different

            if the government ate its own dog food. Ada was designed to make it easy to write huge programs and still manage to be able to "prove" them. The government MANDATED that ALL code was to be written in Ada. Of course, no one followed that and continued to crank out C code - because they were "comfortable" with it.
            Roger Ramjet
          • Been there, done that

            "My main app was written in IBM structured BASIC in 1982 and is now
            in Version 13 and over a million lines of code (of course it was ported
            to VB years ago)."

            Million lines of code in BASIC and you find Java bad?

            "I looked at Java with a few different development environments and
            even tried an app or two, but it's tired UI and it's slowness were not

            Hasn't always been as good as it is today.

            "Also the development environments were very primitive compared to
            MS's Visual UI."

            As primitive as MS was compared to many others.

            "Finally when MS dropped the JVM it was the final bell. The
            environment no longer exists on Windows computers, which represent
            100% of my client base which is both government and large
            commercial organisations."

            The crippled MS JVM was no longer available but JRE/JDKs have always
            been available for windows, and most other OSes.

            Sounds like your requirements, web based cross platform is ideal
            candidate for Java. I'd revisit the new tools (Java EE 5, Netbeans, etc).
            You might find something you like.
            Richard Flude
          • Dinosaur time

            I think the most telling thing is you dismissing my main point.

            The JVM doesn't exist on most of the world's computers. It doesn't matter if you can download it, who's going to bother? You didn't address my main concerns about Java being slow, it's UI looking old and an update to the VM every few days doesn't instill confidence. You may think .Net is a Java clone (does that mean you like it?) but it's significantly beyond that and I see very few similarities between it and Java anyway. I used to see the occasional Java shop in organisations a few years ago, but I haven't seen many lately.

            I don't even understand your comment on BASIC. Those million lines of code are all object oriented and since it is BASIC, there might even be more lines than that as it allows multiple statements on a line ;-) These days VB is indistinguishable from the other .Net languages - eexcept for being easier to use.

            Yes I've tried Netbeans and a few others but it's still 20C stuff - great if you are coming out of the old edit/compile/test cycle but primitive when compared to the MS developement environments. I would suggest they stop writing the IDE in Java to make it a little snappier ;-)

            I think it might be time to instead widen your horizons Richard, just to improve your employability in the future.

            Since I've shared my history - where is yours?
  • Sun Still is Shady.

    I'd like to congratulate Sun for beating a P595 that's has been available for a year, with a hardware configuration Sun doesn't even sell yet! CONGRATS SUN! WAY TO GO!
    •'re missing the point(s)

      This is about the pros being the con (artists) wrt virtualization, not the Sun benchmark result.

      On the other you didn't just miss my point - you also missed Sun's: the T5440 has been available been for some time - so has the software and the storage.

      Sun has not yet assembled and offered for sale a package containing all of the pieces - but you can buy them all now and just package them together yourself.
      • Yes I know

        I know.. I got your point.

        I like your post and understand your approach. That's not the problem. The problem is the reality of modern IT. 2000 Wintel boxes sitting around with 5% utilization. Its way easier, safer, and more cost effective to shovel a VMWare cluster full of VM's by Platespinning physical hosts than to go back and re-engineer the entire infrastructure.

        Should it work the way you suggest? Probably. Does it? Most certainly not.

        And I still think you understand the benefits of virtualization, but you channel your criticisms of hypervisor-based technologies to bolster the Sun approach of 'advanced chrooting.' I don't think the differentiation in approaches is as big as you make them out to be, and each technology has its place.
        • Ok - that makes sense, but let me add

          1 - Wndows servers today are not limited to one app each. So why are most still being used as if it still had NT's limits?

          2 - if VMware can claim that its software lets you have one third more productivity per box than the other guy's, they have to be saying that other guy's overheads exceed one third.

          Containers have virtually no overhead and using normal Unix process management has zero. Makes this approach rather obviously better, doesn't it?

          3 - what's wrong with 5% utilization if that serves user needs? Imagine a dedicated mail server - maxes out for a few minutges every day, idles along the rest of the day. Most don't make an average 5% utilization - but so what? the thing costs a few thousand bucks and VM-ing it to achieve higher utilization slows user response.

          1000 users times 1 minute more each per day in waiting for mail at $25/hr... doesn't take long to pay for that idle time, does it?
  • Mainly agree.

    I liked this post, Murph. I appreciated you clarifying your scope accurately at the start, then sticking to the plot. For once I thought you had mainly managed to pass to cognitive gap that normally limits you to preaching to the converted, so to speak.

    Incidently, I'm still sceptical about your NT 4 is a VMS port line. Actually, I'm not sceptical - i simply do not believe it. NT 4 is a revision of the 3.51/3.5 code base. Can you point me to a credible source that backs up your claims?

    Answers like "google is your freind" will be interpreted as a negative answer, 'cos I've looked and didn't find. More to the point, I was using these versions of the OS when then shipped, and the evolution (rather than replacement) was frankly obvious.