views:

143

answers:

3

I see many deployments where IT groups run effectively nothing but a JVM application stack inside a VM (vmware, &c) instance.

I guess I consider the JVM to be a formal VM: what real benefit is it to run your Java application stack inside another VM?

+1  A: 

Two JVM instances within the same (real or virtualized) machine wouldn't be completely isolated from each other: they couldn't both have sockets listening on the same well-known numbered port, they might interfere with each other if they both wrote in the same filesystem, and so on, and so forth.

Using OS-level VMs (vmware or whatever) does guarantee you as much isolation as you would have on physically separate systems, which is quite a different proposition.

Alex Martelli
Questioning genuinely out of curiosity, for port conflict why would you not then employ virtual network interfaces rather than the whole OS itself?
Xepoch
@Xepoch, if you only need to isolate some specific aspects (networking, or file systems, or other specific devices, etc, etc), and can get a lighter-weight solution aimed exclusively at the aspects you care about, that's great; but once you start piling up multiple such point solutions the lightweight aspect soon fades, while OS-level virtualization can guarantee a buffet of "all you can eat" isolation solutions for one fixed, reasonable price!-)
Alex Martelli
I'm thinking of my next project to limit JVM resources at an OS level to do the same :)
Xepoch
+1  A: 

It's an unfortunate terminology collision

Those are really two different terms that unfortunately use the same english words, but have only a rather abstract connection.

IBM used the term "virtual machine" first, so I guess we can't rename that one to "virtual server" or something.

Too bad "software framework" doesn't have VM in its initials. If you think of the JVM that way it will be obvious that you are really just running a framework in a VM, not a thing inside the same kind of thing...

So a real VM can casually give away super user shell accounts, ssh access, software installation privs, ....

DigitalRoss
Yeah, call me old but VM is still *virtual machine* in my nomenclature in this context.
Xepoch
A: 

what real benefit is it to run your Java application stack inside another VM?

By doing this, your JVM will run on virtualized hardware that you can modify and run in parallel of other virtual machines. This is a nice way to slice a big server into "shares" that you can allocate on demand.

(EDIT: I'm answering a comment from the OP directly in this answer)

I get what you're saying, but why would one not be able to do the very same thing as separate processes on the host OS?

I could mention that a guest can possibly run another OS but this is not the most important part. As pointed out in another answer, the biggest difference is that a virtual machine is isolated from other VMs, it's are real dedicated environment. The port stuff was a good example but I prefer to illustrate it this way: another process won't eat "your" CPU cycles. This is a very important difference, especially for IT teams that usually don't like to share resources. Instead, you can size a virtual machine exactly as needed, possibly dynamically, and bill IT teams for what they are really using. This is IMO what makes mutualisation of resources actually possible (and thus costs cutting).

Pascal Thivent
I get what you're saying, but why would one not be able to do the very same thing as separate processes on the host OS?
Xepoch
I've answered to this in my answer
Pascal Thivent