latoga labs

Alliances & Partnership Advising

© 2006–2025 · Log in

Watch Your VMware Version Numbers

Leave a Comment

Today I had an interesting issue arise with one of my customers that I’m sure might be experienced by other VMware customers in the future.  It has to do with support for the version of VMware software you are running and the VMware version numbering system.

The issue was some confusion around the maintenance releases and the duration a maintenance release is expected to be running in production.  As detailed on the VMware Upgrade and Update Policies page, the versioning system for VMware products is a typical X.Y.Z numbering scheme.  The Z number indicates a maintenance release.  It is expected that maintenance releases are upgraded to the next Minor or Major release as soon a reasonable.

The issue arises when you run a maintenance release for long term in production.  VMware’s Support Terms and Conditions states (see Section 2.3.a) that:

VMware will provide Services with respect to (i) the most current release of the Software for the Contract Term (ii) the immediately preceding release of the Software, but only for a period of eighteen (18) months following the next Major Release of the Software within the Contract Term…

Meaning that users are expected to upgrade their maintenance releases within 18 months of the next Major release.  When a subsequent maintenance release comes out, it may also shorten the window of support for a maintenance release.  The VMware VI Support Life Cycle Maintenance Information page details each maintenance release and when support for that release ends.

Because of the confusion that the Maintenance release number created, VMware has changed the labeling mechanism for updates.  As of 3.5, there are no longer a Z number for releases.  Maintenance or Update releases are now numbered X.Y Ux, where x is the Update Version (i.e., 3.5 U1, 3.5 U2).

So, if you’re running a release of ESX older than 3.5, check your version numbers to make sure your release is still supported.  And keep the release update version in mind when planning your upgrade and deployment schedules as well as when deploying update release.  It’s best practice to be running the latest Minor or Major release.

Don’t loose sight of your maintenance releases running in production.

(Disclosure: I currently work at VMware as a Solutions Consultant)

VMware ESX & VM Server Differences Explained

2 Comments

One item that I have seen come up again and again recently with my customers is a mis-understanding of ESX and VM Server.  Particularly the performance aspects of both.  These are two entirely different products with entirely different goals that need to be kept in mind when comparing the two.

VM Server is the free server virtualization product from VMware.  It’s purpose was to help seed the market and get people more confortable and familiar with virtualization concepts on the server.  What better way to do that than give something away for free for people to play with!  VM Server is similar to VM Workstation/Fusion in that it runs on top of an OS; so from the ground up you have:

server hardware > operating system > VM Server > virtual machine.

This means VM Server inherets the same performance issues that the OS has.  It also means that it has to rely on the OS for a lot for the management of resources.  Net result:  the performance of VM Server will be impacted by the OS you are running it on top of.

ESX is the data center grade hyperadvisor from VMware.  It’s purpose is to provide virtualization for  business critical data centers.  ESX essentially doesn’t run on top of an OS.  You can think of it as a data center OS as it is the base layer for the Virtual Infrastructure set of products. Similarily, from the ground up you have:

server hardware > ESX > virtual machines

You can see immediately that ESX has eliminated the operating system level, this is the source of the performance gain that ESX provides.  It is running on top of the raw hardware.  It is truely a specialized OS with the sole pupose of virtualization.

One thing that VM Server and ESX share, is the engine to run a virtual machine.  This engine has lots of tricks built into it to manage the physical resources of the box and to distribute them efficiently to the virutal machines that need them.  Of couse, you still suffer from that extra piece of the base operating system under VM Server.  This is why you can have VM Server running with no VMs and still see it utilizing resources.  It’s doing the work of interfacing with the base OS for resource management even when no one is using the resources.

So, if you hear somone complain about their VMs are not performing very well ask them which product they are using.  If they are using VM Server, point them here.  If they are running ESX, then it’s time to dive into the typical operating system and application stack tuning/debugging routine.

(Disclosure: I currently work at VMware as a Solutions Consultant)

Next Level: Application Virtualization

Leave a Comment

There has been a number of announcements over the past few weeks in the area of Application Virtualization, most notably VMware’s release of ThinApp.  With the ability to wrap an application in a virtualization container and then run that virtualized application as a stand alone executable, virtualization has been taken to the next level.

As I have been talking to enterprises about application virtualization, a base understanding of why this is important is always needed.  The simplest example of where application virtualization can be used is when you think of the need to have two different versions of the same application.  Image you are a QA tester testing a web based application.  Usually, you verify that the web based application works with both IE 7 and IE 6 or now Firefox 2 and Firefox 3.  In the past, you had to have two machines (physical or ideally virtualized) with each browser installed since they can’t live together on the same machine.  Talk about overhead.  With application virtualization, each version of IE gets placed in the virtualized wrapper and becomes a standalone executable.  Allowing you to run both apps at the same time on the same machine.

Moving to a more complex example, think about virtualizing most of your core applications across an enterprise.  If each application is a stand alone executable, what happens when a user accidentally deletes one of the library files for the application?  First off, this wouldn’t happen because they are all placed in the virtualized wrapper.  But if it did, all IT has to do is tell the user to download the virtualized app again from a central repository.

The cost savings for IT administrators of the desktop can really start to add up.  These include:

  • Less disk space requirements since the virtualized application is compressed
  • Savings in admin hours just from not having to reboot Windows after an application is installed; virtualized applications don’t require a reboot to install, just copy to the machine and run it (or run it from a USB key).
  • The elimination of the re-builds or re-installation of desktops due to user’s accidentally corrupting an application; the self contained virtualized apps can’t be corrupted like a natively installed one.
  • A reduction in troubleshooting application conflicts since each application lives in it’s own virtualized world.

When you take each of these areas of time saving and extend this across 20k, 50k, 200k desktops the time savings starts to have huge impact to the efficiency of an Desktop IT organization.

Stay tuned as I get more real world examples…

(Disclosure: I am currently employed as a Global Accounts Solutions Consultant at VMware.)