
Tuning JVM for a VM - Lessons Learned, Directly from VMware - Emdub
http://marakana.com/s/tuning_jvm_for_a_vm_lessons_learned_directly_from_vmware_video,1138/index.html
======
sciurus
Efficiently using memory when you have three levels (Hypervisor->OS->JVM) that
are largely opaque to each other is an real challenge. Doing ballooning at the
JVM level [0] instead of the OS level makes sense for VMs primarily running
Java applications. VMware often seems to be the first to get a new technology
out, but their competition quickly follows (e.g. KSM for transparent page
sharing and compcache for memory compression). I wonder if Oracle or Red Hat
are working on their own JVM ballooning implementation.

[0] [http://pubs.vmware.com/vfabric5/topic/.../vfabric-tc-
server-...](http://pubs.vmware.com/vfabric5/topic/.../vfabric-tc-server-
em4j-1.0.0.pdf)

~~~
rrdharan
[Disclosure: I worked at VMware from 2002 through 2011.]

I take issue with the claim that the competition "quickly followed" on for (at
the least) the transparent page sharing feature. VMware was shipping
transparent page sharing in their type 1 hypervisor since ESX 1.5, which was
released before I joined the company.

KSM was first proposed in 2008, and I believe it didn't actually ship until
2009 (note: the delay was at least in part because the developers wanted to
avoid the possibility of exposure to patent litigation since VMware held a
patent on the technology, software patents are evil, blah blah).

You can tell a similar story for VMotion/live migration of running virtual
machines; VMware first shipped it in 2003 and it was at least 2007 before any
competing hypervisors were shipping a similar feature (Hyper-V didn't have it
until 2008 R2, Xen had it sooner - possibly in 2007?).

~~~
HackR
Out of curiosity what made you leave VMware?

------
gaius
Is it just me or is running a VM in a VM just crazy? The application stack now
looks like

OS -> Hypervisor -> VM -> OS -> VM -> App

Where "App" might be a service so you might have this stack duplicated dozens
of times for an actual app that a user can use. And you don't save anything
either, rather than "processes" your sysadmins manage "VMs". What happened to

OS -> App

~~~
emmelaich
Yes it bothers me a bit. I think the 'everything to a VM' culture at the
moment unfortunately misses doing isolation in a lighter way.
(jails,zones,lxc,lguest etc). Some of those are not quite mature but still.
Relatedly sometimes license requirements are per cpu, and the license accepts
vmware restrictions but not cgroup or resource manager type restrictions.

I hate licensing.

------
guelo
Or you could just run the JVMs on the base OS and use good old file system
security if you really need sandboxing. The supposed advantages of adding a OS
VM layer seem iffy if you're just running one app per.

~~~
rickette
It always amazed me that the JVM doesn't have any options to restrict CPU
resources (something VMware does have). The only alternative I can think of is
to use the unix taskset utility to limit JVMs to specific CPU cores. Anybody
got experiece with a setup like this?

Limiting memory usage and file permissions with the JVM is indeed easy.

~~~
guelo
Let the OS manage the CPUs, you can use nice if you need to prioritize.

~~~
ntoshev
There is also cpulimit if you want to set hard limits.

------
derleth
So, how reasonable is it right now to run a JVM directly on a VM?

~~~
fleitz
Pretty reasonable as proof of concept, MS runs the .NET VM as an operating
system, see Singularity. There's also JavaOS, JNode, JX

In practicality the issue is drivers, databases, webservers, etc.

~~~
derleth
There are a few ways to solve this; the simplest might be to replace the OS
with a library (a libos) linked into the JVM that implements whatever the JVM
needs from an OS API in terms of what a specific VM offers. This is the idea
of the MIT Exokernel Operating System, XOK.

<http://pdos.csail.mit.edu/exo/>

