Choosing between VMware Server and ESX Server

Customers approaching today server virtualization have multiple vendors and multiple products from the same vendor to choose from.

Many adoption projects fail because companies didn’t carefully evaluate which platform best fits their needs, still unable to fully understand all implications of a choice.

A very simple project may never return on the investment because the adopted solution has a too expensive cost of ownership. On the other side a project which starts small but soon grows in complexity and involves more and more virtual machines at a fast pace, may fail because the adopted platform is not able to scale with it.

In this article we’ll approach the virtualization market leader, VMware, offering, evaluating differences between their products for enterprise deployment: the new, free Server and the popular, expensive ESX Server.

Is a free product reliable enough?

The very first thing to do is dismantle a possible preconception from virtualization newcomers about VMware Server: when a solution is free, mostly if it’s suggested for production use, it’s often considered less reliable, less performing or with less features than commercial competitors.

This habit could lead to discard VMware Server immediately when deciding which product to adopt for serious and complex virtualization projects.

In VMware Server case nothing can be further from the truth.

Before starting its huge investment to deploy virtualization in every company on the planet, VMware sold for five years previous Server versions under the name of GSX Server, with a price near the ESX Server one.

GSX Server has always been aimed at datacenter deployment as well as ESX Server and when the VMware enterprise management tool, VirtualCenter, came out it was immediately able to control both products in the same way.

At GSX Server launch in 2001 the company released an official announcement mentioning mainframe-class control and 300 worldwide known companies adhered its beta program the year before.

After releasing its first free virtualization product at the end of 2005 with VMware Player, the company decided to transform the upcoming version of GSX Server 4.0 in a free product too, renaming it Server 1.0.

Therefore after considering GSX Server a reliable product for so much time, the advent of free edition shouldn’t lower customers’ confidence in product’s capabilities.

Performances versus flexibility

Apart price, the very first difference between VMware Server and ESX Server every consultant or salesman would underline is performance achievement.

At today nobody ever published a benchmark comparison between the two platforms running the same virtual machine on the same hardware, but they way they are architected let people presume which products performs better.

While VMware Server needs an underlying operating system to be installed on, its bigger brother ESX doesn’t: it’s a bare metal solution as the industry usually calls it.

In other words part of ESX Server acts as an operating system, booting the hardware and managing it to achieve all required virtualization tasks, in the same way an appliance would do.

This difference in approach reflects a deep difference in behaviour: while Server capabilities and performances are capped by the hosting operating system, ESX Server is designed to take out the most from available hardware, with the thinnest OS layer possible.

Performing by design means ESX Server can offer customers not only better performances, but also a better consolidation ratio: the amount of concurrent running virtual machines which can be safely allocated for each CPU core in the physical host.

While VMware suggests keeping this ratio between 2 and 4 with Server, customers can reach 4 to 8 with ESX.

These values are highly dependant on expected workload on running virtual machines and on hosted applications inside: a very busy ESX Server may not allow more than three virtual machines per core while a very light Sever could easily run 10 web servers per core.

But in general they can be considered as a good reference point.

The ESX Server capability to directly control hardware components permits to improve performances also in other aspects: for example VMware developed a special file system called VMFS where to store virtual machines, which is faster and more reliable than traditional multi-purpose file systems modern operating systems offer.

Unfortunately when a virtual machine stored on VMFS needs to be migrated on another VMware product its format has to be converted.

VMware Server cannot count on VMFS and its performances depend on Windows and Linux file systems but its virtual machines can be moved on the fly on any computer with a burned DVD or a USB key, considering it just like a standard folder with a bunch of files.

But a bare metal approach brings severe limitations along with benefits: since the product itself acts as an OS, only hardware which has its drivers included will work.

So, for example, at the moment of writing VMware doesn’t include drivers for local SATA disks in ESX Server, and customers adopting it have to choose between local SCSI disks or remote storage facilities, like NAS and SANs.

Customers must also be aware that not only single equipment pieces could not be usable, but a whole machine could not as well: VMware reserves itself right to officially support only a limited amount of systems on the market, so we cannot run ESX Server on any hardware available in our datacenter and receive support for it.

The hosted approach of VMware Server instead permits to rely on underlying operating system for hardware support and drivers availability.

Anything the OS can do, like connecting a remote iSCSI disk or driving a local tape backup unit, is immediately available for Server virtual machines use.

Software availability and support is impacted as well by this difference in approach.

In ESX Server there is a limited amount of installed service utility, new installed applications could not work on it because some mandatory libraries are missing, and customers are highly discouraged to add them, to not mine reliability of the whole system.

This reduces risks but can translate in administrative pains anytime VMware didn’t implement a component needful for us.

In VMware Server environments any program can be installed on the host operating system, allowing customers to achieve tasks like disks defragmentation or backup, performance monitoring or remote management, with tools of their choice, maybe returning on an investment already done before.

Security and learning curve

Security is a hot point of difference between two products.

ESX Server has all characteristics of typical hardware solutions usually called appliances in IT Security: a black box with its own operating system, tailored for performances and minimal attack surface, with a preconfigured application on top (a firewall, an antispam, etc.).

Inside it customers find essential (and sometimes insufficient) tools for administration and vendor doesn’t support installation of any other piece of software which could introduce vulnerabilities in the system.

The appliance approach is a double edge weapon: from a point of view it cuts away the complex task of securing the environment, performing the so called hardening procedure to the operating system.

It also avoids administrators to care about system patching: when a new vulnerability on included components appears, customer just has to wait VMware to release the proper patch or a platform replacement.

For these reasons appliances, and ESX Server, are considered solutions with a lower total cost of ownership (TCO).

But from another point of view anyway, customers have few or no capability to perform an emergency operation on a vulnerable platform component.

If a system is exposed to attacks, recognized as vulnerable, but VMware is in late for a patch administrators have to mitigate risks recurring network defences where possible, or avoiding using the compromised feature.

Last but not least in some highly security environments a black box is not allowed at all, by corporate policy, for inability to fully control the platform.

In a hosted solution like VMware Server we have to face opposite problems: full control on the operating system behind the application implies notable knowledge for hardening it, time and a tremendous amount of time for finding, testing and implementing new patches.

In fact it’s not only a problem of allowing time to monitor new security bulletins, downloading patches and installing them, but more important it’s a problem testing the patch and judging it reliable before applying it to production environment.

A patch may fix security vulnerability but impact on overall system reliability.
To assure this doesn’t happen a company should have a lab environment, where production systems are replicated, a valuable network traffic generator and a team handling the whole QA phase.

It’s evident this approach has huge costs which few companies can sustain, so the large majority of customers usually have only two savvy choices: use a hosted solution but maintain its OS unpatched until the application vendor (VMware in this case) doesn’t official approve the patch, or turn to a black box solution.

Less savvy customers allocate time and staff for patch management but implement OS patches without testing them. While this can be accepted on some less critical servers, it’s highly discouraged on a virtualization environment, where reliability is the first need to satisfy.

Another notable difference between VMware Server and ESX Server is the learning curve.

ESX Server has more features which obviously require more time to be mastered, but apart quantity, its adoption involves other aspects impacting on training.

For example a company only adopting Microsoft technologies may find more problems than others in studying ESX Server, because it requires some limited knowledge of Linux environment and commands.

Any delay in understanding the platform has consequences, because administrators have to learn how to interact with product, and are slower in doing troubleshooting or performance tuning.

And this delay is bigger when a company decides to not invest in qualified training.

While ESX Server lets no choices, VMware Server, being a hosted solution, can be installed both on Windows and Linux, permitting to immediately spend existing knowledge.

Boosting products with VirtualCenter

Per se differences between Server and ESX Server can be considered limited. But this changes much when they are used in conjunction with VirtualCenter.

Both products benefit some common enterprise management features like multi-host centralized monitoring console and virtual machine inventory, a template based repository for fast provisioning of new virtual machines, a granular permission system to control user access to virtual machines, and a flexible alerting service.

But ESX Server is much more integrated with VirtualCenter than Server, and can perform more complex operations like the famous VMotion: migration of a virtual machine from a physical host to another without interruption of service.

This integration is even tighter between the new ESX Server 3.0 and VirtualCenter 2.0, called together VMware Infrastructure 3, permitting more acrobatics.

The new platform for example is able to detect failures on a physical host, and restart a lost virtual machine on a different one available in the datacenter.

Another impressive capability permits to dynamically move away a running virtual machine from the physical host where it’s running if it becomes overloaded, and to place it on a less busy server. All without manual intervention and without interruption of service.

While these features are desirable by every company to drastically lower maintenance costs, they imply a huge investment in terms of hardware equipment: without a very fast network connection and an expensive SAN infrastructure behind there are no chances to implement them.

At the moment of writing VMware Server cannot benefit same advanced features, since 1.x branch can be remotely managed only by VirtualCenter 1.4, which is limited.

Future releases of VMware Server are expected to be managed by VirtualCenter 2.0 but it’s unclear if listed advanced capabilities will be unlocked for the free platform.

Until that time who decides to adopt Server will have to rely on 3rd party solutions like one provided by vizioncore to obtain some of the VMware Infrastructure 3 capabilities.

Finally VirtualCenter 1.4, despite its limitations, is not free, so customers adopting the free Server but wanting centralized capabilities have to consider the overall price before choosing.

Vital support

As already said in the first part of this article, free software can be often not perceived as fully functional, reliable or performing, and avoided for these reasons.
In some corporate realities it can even be disallowed by company policy, because IT managers are scared by the idea they are relying on a product which has no economical model behind, and the company producing it could suddenly stop supporting it.

To address this legit idea VMware offers Server as a free product but at the same time offers enterprise-grade commercial support for it.

Considering the problem from another point of view, often happens some companies, mostly smallest ones, when considering differences between Server and ESX Server do not feel support a mandatory need, planning to rely to online documentation, support forums, blogs and books to solve any issue popping up during the virtual infrastructure lifecycle.

Unfortunately there are a large amount of factors which make things much more complex than that, including incompatibilities with some hardware configuration, unexpected behaviours of some virtual machines depending on hosted applications, sudden performances bottlenecks at host level and others.

Any virtualization platforms should be considered a mission critical tier, considering on it depend many virtual machines and related services, and customers have few reasons to avoid purchasing commercial support.

In this perspective Server and ESX Server are identical, offering same Gold and Platinum support plans.

Conclusion

VMware Server and ESX Server offer different approaches to solve the same problem, addressing different company needs.

Customers looking for maximum performances and partial datacenter automation should look at ESX Server, knowing it implies a significant cost in hardware equipment, implementation efforts and training time.

Customers looking for a faster startup time and a flexible solution can adopt VMware Server with confidence: it’s reliable enough to be considered in every virtualization project.

This article originally appeared on SearchServerVirtualization.