"Could we imagine a server world in which apps ran directly under ESX and there was no guest OS at all - or is this my fevered imagination running riot?"

You'd need a mechanism whereby apps could talk to one another. If they are each in a VM, the options are limited, but I dare say you could add them to the VM product. But by the time you've done that, you've just reinvented the OS.

Welcome to cycles of reincarnation.

Yes, all this talk about hypervisors being some shiny new 21st century concept rather ignores the fact that people who wrote the first OSes about half a century ago used the term virtual machine to describe a user-level address space, even before IBM borrowed the term for their VM product.

But most programmers have *no* idea of the history of their discipline, so they are condemned to reinvent it, usually more poorly.

Does VMWare automatically start a new virtual machine on the real hardware for the new process when the application forks? Does it schedule the processes, set up shared memory, sockets, and enforce resource limits for each process?

If it doesn't handle those things, the OS still has to arbitrate IPC, sheduling, and resource limits for the processes independently. If it does handle those things, it is more OS than virtual machine, it's not so much making the OS redundant as imitating the OS's role.

So, we strip down everythiing to just be able to load the os that only has a purpose to make the Application run.

Sounds like it would indeed be easier just to write, or rewrite the application.

Why not just run it all in linux with WINE, except make the application unaware of the other applications, and be able to dedicate a specific amount of memory, and cpu to each app.

oh wait....

So if we follow the trail, it turns back around into just basically that we need an OS that is better at multi-tasking, easy to manage several different services, and has the ability to migrate between hosts, and to not completely kill the OS when one application hangs.

is VMWare running out of ideas? if so I have a few that im sure lots of people would enjoy.

Has anybody rewritten WINE to run directly under VMWare?

"Could we imagine a server world in which apps ran directly under ESX and there was no guest OS at all"

Yes, in fact I can. It´s called an "operational system". I reckon Unix has been doing it for some decades.

Well, that would mean that all resource management would be handled by VMware... in which case it wouldn't be significantly different to a normal OS - especially as the guests would need some ways to communicate and share data.

In which case we would want a hypervisor to run multiple instances of VMware on the same hardware.

The other fallacy with this idea is that most of the big-beastie apps are either multithreaded or multiprogrammed - so inherently require some sort of task management. Not to mention the cloud of helper apps that usually accompany such a beastie - app specific data loading, backup, etc.

Actually it's funny to see this band-aid being applied to the axe wound of Windows one-app-per-server mentality. That was certainly necessary in the days of Windows NT, but the sheer number of Windows boxes and accompanying CALs meant that at the end of the day the cost was similar to the single AS400/HP3000/Unix box it was supposed to replace.

So, in this modern day and age, is it still not possible to configure a Windows server to reliably fulfil more than one task? I ask this because we are happily running a linux box as a combined file/email/intranet server and we all know that proprietary software is supposed to be better.

I must admit that there are open-source apps out there which assume that they have a machine to themselves, or just take everything over anyway (Zimbra I'm looking at *you*). But that's the app rather than the platform.

"The guest OS running under a hypervisor could be stripped down to a kernel, letting the hypervisor handle things like multi-tasking and talking through drivers to physical resources." ......

That would be AIdDream Application and also such for a guest OS/Project Driver.

"Cavalliere also plays the stability card, saying that some 80 per cent of server failures are due to driver code failures .." ...... A Driver that eats its Own Code Never Ever Fails to FailSafe. And I would normally, as a Golden Rule, Never Ever use Never Ever such is the True Nature Of Virtual Reality in ITs SurRealities.

"But Microsoft is not taking part. No, really!" .... WOW, I wonder Why?

If the VM is doing part of the work of the OS then why use Virtualisation. Instead move the features of a VM that people like into the OS.

The ability to live migrate an OS to other hardware would be very neat.

IBM's VM/CMS did *exactly* this when I was in college in the '80s, and it wasn't exactly new stuff then. "VM" stood for "Virtual Machine" and you logged in and had a virtual System/370, and you ran whatever OS you wanted, usually a stripped down single-tasking thing called CMS shrunk down just as this article describes.

Why has it taken 15 years for this to be rediscovered? What's next? Punch cards?

"... hypervisor can detect memory pages that are duplicated by multiple instances ..."

Whoa. They've rediscovered "copy-on-write" too! These people are GOOD!

>"For example, if there are several Windows XP/application VMs running then ESX won't load each XP instance's full set of memory pages as some single pages can be shared between the multiple XP instances."

Thus breaking down the security isolation between those separate VMs.

In theory a hypervisor could just about make this robust, but I'm not betting on it. Wonder what happens if you remap a new view of the physical address of one of those pages and write to it, or use DMA to change it... there's a whole lot of possible ways to slip past the COW protection and reach from one VM into another there.

The lean-OS model where many of the normal OS functions are handled in the app layer is more properly called an exokernel. I'm not sure about the current state of exokernel research aside from the MIT exokernel OS I saw some years back.

"Could we imagine a server world in which apps ran directly under ESX and there was no guest OS at all - or is this my fevered imagination running riot?"

So that would be an operating system then...

Seriously, it's just a sandboxed OS...

I thought one of the main advantages of virtualization is that every host OS is truly independant from the others, meaning that if someting goes wrong with one of the hosts, the others stay unaffected. How does that work if the OSes are sharing stuff (even "only" memory pages and drivers)? Wouldn't a compromised instance be able to modify system-wide ressources then?

Would it be, by any chance, one of the reasons why MS doesn't want to go down that road (not that they don't trust their OS to be absolutely secure, of course...)?

I'm retired now, but I spent 20 years running an IBM mainframe using IBM's VM operating system. Although VM was developed to host multiple versions of MVS etc, IBM also offered a simple OS called CMS that was a single-user operating system designed to exploit the VM hypervisor. It was fast, stable, reliable - all the things your author describes. And I miss many of its features....

Been there done that, have the t shirt

Regarding the last comment, the ESX provides a common set of drivers so each OS/application doesn't need to worry about them. And it handles the multitasking, so the applicatoin/OS doesn't have to.

Geez - sounds like the original reason Microsoft pitched Windows to begin with. Talk about taking a page from Microsoft's playbook!

If you take away the guest OS from being in the middle between ESX and the application, aren't you back to where you started i.e. an OS and an App?

In which case, why not improve seperation in the OS and dump ESX??

Of course, you'll have to have the word virtual in front of everything so people will still think it is a good idea.

"Could we imagine a server world in which apps ran directly under ESX and there was no guest OS at all..."

So we've gone from the big shared hardware resource of the Mainframe to x86 servers to ESX. If ESX decides what it really wants to be was an OS, in another 5 or 10 years we'll need something that consolidates our ESX servers. Virtualization III or Virtual-Virtualization, something like that...

Not to be too glib about this but how is shrinking the OS+APP down, and the VM up until the former becomes basically what is known as a process and the latter basically what is known as an OS (with drivers, messy multitasking, warts and all), going to solve anything? Ultimately, all the complexity has to go somewhere.

But that's it, isn't it? Ultimately, it comes to down providing a more "complete" process environment, i.e. each process gets its own disk, registry, windowing system, keyboard and filesystem.

Ah. So we come full circle. Why have duplicated operating systems and drivers when you can just write software against the "bare metal"? Avoiding writing applications directly against hardware (virtualized or not) is exactly why operating systems were invented in the first place. If VMware were to provide another abstraction layer for applications to run against directly, it'd just be yet another operating system with processes just implemented differently. The only cool thing would be the ability to migrate "processes" on the fly --which isn't a new idea either.

Personally, the reason why I use VMware is so I can run multiple _different_ operating systems without buying additional hardware. Having paravirtualized drivers is probably a good idea, but If you try to boil this down any further, we just wind up right back where we started before hardware virtualization.

Rather than rewrite all my applications to run under some uber VMware OS, why not just continue to run operating systems that already work, isolate processes using thing like BSD jails and Solaris Zones and implement dynamic process migration between machines.

Wait, so all we need is a simple app loader, where the single-threaded app talks directly to the "hardware"? You're talking about DOS, aren't you? The future is DOS?

I'm sure I have Turbo C++ around here somewhere....

"So, in this modern day and age, is it still not possible to configure a Windows server to reliably fulfil more than one task? I ask this because we are happily running a linux box as a combined file/email/intranet server and we all know that proprietary software is supposed to be better."

Perfectly possible; I've got several. It's only vitualisation which leads one to consider one app per machine.

I was GOING to post something like this:

"In other news, VMware Advanced Development has invented a new technique called 'duplicate-on-modify'....."

Most 'big' OSes share read-only pages. If you are an app that's not running with suitable privileges - which should be all apps - then you can't remap nuffink. It's safe, implementation bugs aside.

DMA, though... if the OS/cpu can't control what goes into memory then all bets are off I guess. But that requires hardware. You can crash an OS easily with any of a wide range of hardware - a screwdriver jammed in properly will take anything down. Permanently too.

Does anyone know how this fits in with HURD? It may be a silly misunderstanding of mine but HURD and virtualisation layers seem to be similar. Maybe.

We had this back in the mid 70's on an NCR mainframe. A multitasking operating system called B3, under which you could run up to 9 partitions, each running B1, which was a single task operating system. Each B1 partition would run as if it were alone on the hardware with B3 managing the overall system resources.

How is this any different? Simply change B3 to ESX and B1 to Windows and all of this remains the same.

Maybe I have been in this business too long, and have seen everything old become new again.

Nuff said...

"So, in this modern day and age, is it still not possible to configure a Windows server to reliably fulfil more than one task? I ask this because we are happily running a linux box as a combined file/email/intranet server and we all know that proprietary software is supposed to be better."

Perfectly possible; I've got several. It's only vitualisation which leads one to consider one app per machine.

The theory is, you can separate each kind of service so that one getting clobbered won't take down everything, you can use VM backups to roll back, and if the app needs more resources it's easy to migrate it to a different VM host.

Basically virtualisation reduces maximum capacity of your servers ( a lot more overhead per app) but more importantly reduces overcapacity as well. You need to have the right kind of requirements for it to be worthwhile

Clearly VMWare want to build an OS business out of the virtualisation niche they are in, so want to add all the features of an OS to their product. Probably not the way to go. What seems more likely is the OS developers adding less resource hungry virtualisation to their OS offerings - KVM as part of Linux as AC points out, or Solaris containers. Microsoft have something more similar to VMWare with their VirtualPC product, though they will probably be building stronger support for Windows on Windows more directly into their host OS products if they are not already doing so. I guess you'll probably still need a fuller virtualisation layer if the host and guest operating systems are different than if they are the same.

DMA access on a guest OS are still virtualized since the hardware is virtualized. The hypervisor would trap and analyze the request and perform a duplicate-on-modify as needed.

I always maintained that the IBM PC/ MS OS team put computing back at least 20 years, looks like it was really 30. The ICL "VM" Operating Systems in my youth ran multiple alien operating systems then and they used less than 2 Meg of memory - couldn't fit it in the room! so basically all that has happened is a re- invention of a very old concept but very poorly.

The long term result is that performance is better under the real computer operating system so eventually one layer disappears as the applications are rewritten as required.

The other little trick was to have an address flag on the segment and if it was code, it was not modifiable - stopped a lot of corruption creeping in by accident or design and if it was system code you only ever needed one copy. No doubt some American will invent this soon.

And let's not let this little gem go by uncommented "VMware is now, according to one survey, as reliable as a mainframe"

Which survey was that ? Ask 3 VMware engineers if there code has being running for the last 10 minutes? Seriously, I'm not putting VMware down, but marketing folks throwing around these meaningless asides, which some folks will pick up and use, is just annoying, dangerous and laughable. Did I miss the announcement of x86 server hardware with all the reliability features of a mainframe ? How many x86 apps run for years without a reboot/re-IPL? Come on.

Not really, the copy-on-write protection for shared code pages isn't much different to that used in guest OS'es. Note I use the word 'code' since data pages should be in user mode so will get written to. This can be verified by loading apps or data in the guest and tracking the lifecycle of each page through the working set to the standby/modified page lists - as soon as anything is changed a private copy is written.

Looks to me like VMware would like to pull the OS rug out from under MS's feet.

Microsoft have been progressively throwing away and subverting everything that an operating system ought to do for one, culminating in Vista. VMWare is capable, to some extent, of giving its end users back some degree of control over their hardware and their data.

In the worlds of Unix, Linux and VMS, the operating system pretty much does what VMware is suggesting they can do. These systems errect secure walls between processes, they enforce security restrictions and prioritization on access to resources, they are controllable by their users.

Which is not to say that VMs aren't useful here as well: one is often stuck with legacy applications that won't run on the latest OS, wile also wanting to upgrade to run the latest non-legacy apps. Virtual machines become very useful if you need to run two or more different kernels. Then there are snapshots and rollbacks, so incredibly useful for debugging deep system-level problems, or catching out vendors who try to infect your systems with slimeware or DRM without telling you before it's "irreversibly" installed.

A helicopter, because it's a good symbol of what goes around coming around again.

SR10... sorry to say much as I love Apollos I never noticed a virtualization layer in there. But I've ready to be educated as there are so many technologies touted as "new" that I first encountered in the Apollo OS.

One I'm still waiting for someone to reinvent is the "just hook the new machine up to the network and it talks to all the others" idea.

And not to subvert the discussion into a totally Apollo-head direction:

* Which is the better, SR9.7 or 10.4?

* Anyone here seen the PA-RISC port of Domain/OS in operation?

(why is there no Apollo icon here?)

An even bigger challenge is getting the vendor to support the apps... Last time I was looking it was always "Oh well, if our app isn't the only one running on the server we can't support it.

As for HURD - isn't that, to all intents and purposes, vaporware, ads there's no sign of it being ready for production use within any particular timescale?

"The other little trick was to have an address flag on the segment and if it was code, it was not modifiable"

Hmm, the x86 architecture used to have a Code Segment register ... which IIRC originally could be used to specify different memory from Data memory, if required.

"Ditch the guest Windows OS drivers and use VMware's ones for increased server reliability."

Once upon a time, a certain large company said that Windows would be reduced to "a poorly debuged set of device drivers." Now it looks like it won't even keep the device drivers. Poor windows.

"Actually it's funny to see this band-aid being applied to the axe wound of Windows one-app-per-server mentality. That was certainly necessary in the days of Windows NT, but the sheer number of Windows boxes and accompanying CALs meant that at the end of the day the cost was similar to the single AS400/HP3000/Unix box it was supposed to replace."

Um, actually, in my experience, that was 'significantly greater than', rather than 'similar to'. Mind you, I was just a young pup, so I didn't know how much the old Unix box cost; I only knew the cost of the replacement kit suggested by the Unix vendor.

And that's before you factor in the power, the space, the cooling, and the staff.

I don't think that I've ever read such utter rubbish. This sounds like CMS (a single-threaded OS working only through virtual devices) running under VM and that dates back to the late 70s. Try running a modern database (or almost any modern non-trivial application that way).

yes folks, it looks like wheel-re-inventing time again.

Time for the ex ICL folks to dust off their VME manuals and see what else is going to be 'pinched' by the new boys.

Anyone remember VMM_MOVE_VM_TO_NODE to move a virtual machine from one OCP node to another?

A few facts :

* Windows is, in fact, an extremely bloated OS to run one application per VM, but its reliability, or lack thereof, means that running multiple applications per server is suicidal ;

* other OSes only take about 32MB of RAM to boot and run (Red Hat EL5 for instance), making the overhead of running a real OS in a VM minimal ;

* Wall Street chose RHEL because of its reliability, only 4 hours of downtime per year due to patching in 2007 according to an independant study, easily beating Solaris (which did not do too bad either) and Windows ;

* newer multitasking code (Linux 2.6.22+) is tickless and so does not take any ressource in guests when they are not doing anything ;

* paravirtualised kernels use the hypervisor and console OS (in Xen's parlance, Domain-0) drivers to talk to the hardware, so what VMWare is trying to do is nothing new, except that Windows was very late in coming into the paravirtualised fray (Windows Server 2008 is paravirt-aware, as far as I can tell, but that's not the case of XP, Vista, and 2003 Server);

* sharing data blocks between VMs is a security nightmare, from my point of view.

VMWare is trying to solve a problem that has mostly been created by running Microsoft Windows... and sent its PR team spinning about it. I love it :)