Now this is interesting: BEA is coming out with a version of its application server that runs directly atop VMware.
With this move, VMware takes another step toward becoming a full fledged operating system in its own right. VMware is already promoting the distribution of applications as virtual machine images, and operating systems are first and foremost application platforms. If VMware is an application platform, why not cut out the middle man entirely, particularly given that the middle man adds a few hundred megabytes of largely invisible baggage to the application, not to mention an enormous amount of maintenance burden for the ISVs that make or break an application platform?
For me, the real question is: Why BEA and not VMware? A JavaOS makes a lot of sense, since it builds on one of the world’s largest developer communities—it’s a well known environment among developers, and there are a huge stable of applications that could take advantage of the new platform with minimal porting. Furthermore, applications are increasingly server based, with the browser providing the UI, so this matches well with industry trends and nicely addresses the problem that VMware would have a very hard time building any sort of graphical user interface into its platform, just given the nature of what it is.
That said, VMware should really want to provide the JavaOS directly. With Xen and Virtual Server moving aggressively to bundle their products with widely deployed operating systems, the game’s already afoot, and if virtualization becomes just another operating system feature, VMware is at a distinct disadvantage, as it owns no operating system to bundle its product with. Finally, what about standards? New kind of operating system or operating system feature, there are going to be multiple application platforms if history is any indication (and it usually is), so how do applications take advantage of the new platforms without the inevitable fragmentation?
It’s going to be an interesting space to watch, that’s for sure.
Except that the lowest level vmware product, ESX server, is still a glue on top of a linux kernel…
That’s actually not true. Although the service console, which manages interaction with the VMkernel, is built on Red Hat, the actual VMkernel hypervisor is not based on Linux.
John’s right. ESX Server runs on the bare metal. -ian
You’re both half right. The vmkernel runs on top of the linux kernel of the service console.
Glandium – you suffer fromm a common mis conception – the VMkernel boots the ESX server – the system console is infact a special virtual machine brought up after VMkernel bot time.
VMkernel is not based upon linux, nor does it run on top of linux – in fact the complete opposite is true.
rob: considering the vmkernel is started by an init script on the service console, and that what grub starts is the service console linux kernel…
Pingback: tecosystems / links for 2006-12-18
Glandium –
there’s a long history of booting a basic operating system to load a more sophisticated one. I may be dating myself, but Netware 3.X/4.x would boot DOS, and then load the netware kernel. That didn’t mean that netware was based on DOS. In fact, there was even a command that would remove DOS from memory after netware was started.
The VMKernel is NOT based on Linux, no matter what the service console may look like.
Pingback: Planeta Debian » 451 CAOS Links - 2006.12.18
someonewhoreallyknows: Linux and DOS are not the same beast. Come on, DOS didn’t even have memory management…
my point wasn’t to compare the two – my point was that it’s possible to boot one OS and load a completely different one, and have no architectural relationship between the booted OS and the running one.