latoga labs

Alliances & Partnership Advising

© 2006–2026 · Log in

Archives for August 2008

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)

Upcoming Events

Leave a Comment

Here are some upcoming events that I will be attending:

  • WordCamp 2008 San Francisco:  On Saturday August 16th I’ll be here at the Mission Bay Conference center in San Francisoc. This is looking to be a great day of networking with other WordPress Bloggers.
  • VMworld 2008 Las Vegas:  From Monday September 15th through Thursday September 18th I’ll be at the The Venetian Hotel in Vegas.  VMworld is the networking event for virtualization, full of keynotes, sessions, and access to all levels of VMware emloyees.

It’s always great to hang out in person with people, so if you’re going to be attending either of these two events let me know.