Why Java is important to VMware but may not matter long term

VMWare has a problem. Consolidation is the usual angle thats used to sell it. Most boxes run at 5% load so ideally you want to consolidate 15 machines or so on to a single box pushing its utilization to 75%. But, that means you need memory for 15 virtual machines on the box. Thats a lot of memory and memory isn't cheap.

So, they usually say overcommit the memory and everything will be ok. Thats not true (especially for Java applications, we run into this ALL the time, don't believe the ok to overcommit advice) but thats another blog post on why swapping and Java DO NOT MIX right now. VMWare needs a way to reduce the cost of RAM so that it lowers the cost of the platform and lets people host as many virtual machines as possible on a single box without breaking the bank on memory cost.

A normal unvirtualized box runs an operating system and the OS hosts processes. One per application maybe. Memory utilization is pretty efficient. All processes can share libraries in memory, file system caches and the memory of the operating system is amortized over many processes.

This isn't the case with VMWare, a hypervisor. Each virtual machine runs its own copy of the operating system with its own file system cache. There is usually no sharing of memory between virtual machine instances (although thats changing). This means a virtualized box is inherently less memory efficient than a single operating system instance running the same applications. The multiple operating system instances are costing VMWare a lot of memory. A hypervisor may be more CPU efficient but it's not as memory efficient as a single operating system running the same applications. You can enable swapping to avoid the need for so much memory but Java applications don't work well with swapping so lets assume we are not swapping. Now, there are advantages to using a hypervisor but we are talking about the resources needed to run X applications here and memory factors in.

VMWare could get in to the operating system business but thats going to fail. Windows and Linux basically own that space. Microsoft is busy adding hypervisor capabilities to their own stack which will cost less than VMWare so hosting Microsoft applications is probably not a long term business for them.

I said at the beginning that Java is important to VMWare. Normal applications are built against a specific operating system thats evolving. VMWare is unlikely to be able to host normal applications without an operating system because they can't emulate the operating systems. They would need to host the operating system as a virtual machine and as we said earlier, thats not memory efficient.

Now, there are a lot of Enterprise applications written in Java. This means that if VMWare could host Java applications natively, i.e. if VMWare can host a Java virtual machine without an operating system then potentially they can be as memory efficient as an operating system. They can use shared memory between JVM instances for JITed code. They would only need to implement the Java API which is basically portable across machines and operating systems. This is significantly easier than emulating Linux or Windows. A Java skin gives them a way to host Enterprise Java applications natively and cut the memory overhead a hypervisor brings to the table by removing the overhead of an operating system.

A hypervisor has advantages over a native operating system in that it can move virtual machines from one box to another and suspend/resume them. Application or virtual machine mobility is a big selling point for a hypervisor. It's possible that VMWare sees Java as a way to lower the cost of virtualizing Enterprise applications. However, operating system zones and WPARs offer application mobility also so this advantage is not such a big deal anymore. A big advantage WPAR/Zones have over virtual machine mobility is that you're not bound to an operating system with WPAR/Zones. You can upgrade an application by moving it from a Linux Version N to a Linux Version N+1 machine. Moving a VMWare image doesnt upgrade the OS, the OS is still the same after you move the virtual machine. You'd need to upgrade it in the virtual machine which is more hassle than just moving a WPAR/Zone.

This native Java Virtual Machine puts them in a similar situation to Azul. Azul can run standard Java code but unless the applications are certified to be supported on it then customers are reluctant to do it and vendors are reluctant to support their products on that configuration mostly because of support/testing cost. A VMWave JVM would suffer the same consequences. Application server vendors would have to certify and support it to move applications over and that can be a tough thing to get them to do.

Buying Spring gives VMWare Spring TC and Spring DM. These are Java application containers which can probably run 80% of departmental and many enterprise Java applications (Servlets, JDBC, JPA, JMS). It's not JavaEE certified but it's probably enough to run most Java applications. If customers can move Java applications to such a container and hosting them on a virtualized environment then potentially you can lower VMWares TCO as it'll require less memory to host them.

I'm actually skeptical that VMWare offers many advantages over just running an operating system natively on the box for Java applications. Best case, VMWare would match the memory footprint of the operating system and it would likely run the applications a little slower. Application mobility is still an issue for operating system hosted applications but technologies like Solaris Zones or AIX WPARs are starting to address application mobility without the memory cost of a full virtualized environment such as VMWare.

So, to summarize. VMWare could host Java applications natively to lower TCO. This would allow them to host multiple Java applications on a single box with similar TCO best case to a conventional operating system. Hosting commercial application servers like this would likely be a support problem but as I said, many Java applications would run on a native Spring TC environment. Application mobility between boxes was a big advantage for hypervisors such as VMWare but operating system features such as Solaris Zones and AIX WPARs are rapidly eroding that advantage because applications installed in a zone or WPAR are basically portable anyway between machines and have the advantage of not being bound to an operating system version as is the case with a virtual machine image. Once customers figure this out then they may decide that using a conventional operating system with WPARs or Zones is actually a more cost efficient and easier path to swallow than picking up a new platform based on a hypervisor which would not be as memory efficient as a normal operating system would be. 

Will VMWare ultimately fail because what customers really want is not virtual machine mobility, they want application mobility?

Comments

[Ryan de Laplante]

Excellent post. I was thinking the same thing about Solaris Zones.

[Jacques Talbot]

This is the age-old argument whether an OS or an hypervisor (e.g.VM vs MVS)is the appropriate container to run multiple applications.
Actually, for Java, this makes little difference since you need multiple JVMs in both cases, because the multi-tasking JVM never really happened. The overcommiting issue is the same in both cases.
So I can't see how your memory argument makes a significant difference. Even with a decent multiapplications OS with the appropriate WLM algorithms (say AIX), you end-up with one JVM per application, and even per process.
So the pro-VMware argument seems to be: since anyway you need one JVM per app, at least, let's take a simple Linux and run one app/JVM per Linux per VM, instead of several app/JVM per AIX per VM.
The only memory overhead is the OS footprint which can end up being actually smaller that the JVM footprint.

What do you think?

[John]

"Thats a lot of memory and memory isn't cheap."

Interesting. So 15 boxes with 4GB of RAM each is cheaper than 2 boxes with 32GB of RAM each?

Good thing you don't work on my system admin team!

[bnewport]

Jacques,
given the os would be hosting the jvm, I can't see how it would take less memory than a native jvm or just a normal process running the jvm on a wpar etc. This is why I think best case scenario is that it matches the memory footprint of a conventional os running the jvms.

[bnewport]

John,
which system can I run more applications on from a memory point of view. The wpar/zone based system can because there is only one os footprint on it. A full hypervisor has advantages over a single os instance. Multiple os versions, virtual image isolation and so on. But if it is possible to just consolidate the applications rather than the full os and application, you will save more money.

[Cameron Bromley]

Solaris zones can and do share memory, though each zone doesn't know it, the root zone sees all the processes running on the box and does the normal solaris memory sharing. On top of that if all the zones are using a shared jvm (say from /usr/jdk/latest in the root zone) not only will the kernel memory for the jvm itself be shared across zones but also, I believe, the memory consumed by the java.lang classes (anything in rt.jar) using Class Data Sharing. So that's a huge saving and explains why it's not uncommon for a mid-range Solaris box to be running a hundred zones.

[green tea]

I know about Java. But I don't know about VMware. What is it ? Is it any kind of software or platform or framework ? If more information, post here.