Original URL: https://www.theregister.com/2009/11/23/repetitive_os_bloat/
O/S bloat: What's the cure?
Code belly's gonna get you
Posted in OSes, 23rd November 2009 10:48 GMT
Comment It is becoming increasingly obvious that a virtual server wastes great chunks of its memory occupied by the operating system wrappers around the applications in the virtual machines (VM) running in the physical server. If each VM occupies 50MB, and 20MB of that is the Windows O/S, then around 40 per cent of the servers's DRAM holds repetitive and relatively useless code.
In a virtual server a main function of the O/S wrapper around the apps is to provide a bridge to facilities controlled by the hypervisor. If there are 20 VMs then there are 20 copies of, say, Windows, all doing pretty much the same thing - which, if you added the essential part to the hypervisor, could be cut by 19 copies since the VMs would then share the now centralised Windows O/S.
It is worse than that as VMs often contain a single application, yet Windows is a multi-tasking O/S with code to prevent different applications interfering with each other, code to schedule multiple applications, and code to provide virtual memory resources, paging to disk and so forth. None of this needed when a VM contains a single app and there is no multi-user contention for resources within the VM.
In such a situation Windows is memory-hogging overkill that prevents more VMs executing in the server because server memory is filled up with repetitive instances of Windows bloat.
But Microsoft doesn't see it like this, and one product manager said it wasn't a good idea to consolidate functionality from Windows-controlled VMs in a Hyper-V environment because you would then run the risk of a single point of failure.
You can't have thin O/S wrappers around O/Ss in VMs unless the hypervisor takes on the necessary functionality stripped out of the currently fat O/S wrappers, there are thin O/S wrappers available, and application code can be compiled to execute with the thin O/S wrappers.
Microsoft is happy to provide thin client software but not a thin version of Windows to run under Hyper-V. VMware isn't, as far as we know, supporting the development of a thin O/S wrapper around apps destined to execute in VMware VMs. The result is that we're stuck with repetitive O/S bloat in virtual servers which are forced to waste processor cycles, memory capacity and electricity cycles loading, storing and executing repeated instances of O/S code that are not needed, which nobody wants, and which, unless it's Linux, have to be licensed and paid for.
A Windows and Unix tax is preventing virtual servers from running at their full potential.
Security researchers at HP Labs in Bristol have been looking at how to protect desktop and other users from the results of their own carelessness. When downloading free software to achieve some business end, such as an unusual file format conversion, they are inadvertently loading botnets, trojans and other malware onto their systems which can infect a corporate network.
Richard Brown from HP Labs says they have come up with the idea of a bare metal hypervisor which is integrated with a trusted computing module (TCM) fitted to the system the hypervisor is running. The aim is to help prevent "botnets and trojans in the dark archives of users' machines".
The applications are run inside secured virtual machines which have no direct access to hardware resources at all. Any VM that is infected with malware can simply be deleted and the infection destroyed.
The researchers have made another step to reduce malware instances by coming up with the idea of a a virtual machine appliance. These are lightweight virtual appliances in which the VM contains the application and a skinny O/S delivering its needs to the hypervisor and receiving hypervisor services for the app.
Brown says that a desktop user can then run different trusted and secured virtual machines for different applications with differing needs, such as access to a secure banking network, running business applications, and doing general mainstream PC work.
The fun bit is that such an environment has been prototyped with a Xen-based hypervisor talking to the bare-metal, and lightweight thin Linux O/S wrappers created to run applications compiled to execute inside them. A potential answer to repetitive VM O/S bloat has been devised by researchers looking to solve a security problem.
Brown thinks that things will evolve such that a bare metal hypervisor and thin O/S-style VM ecosystem will evolve alongside the current full-blown O/S VM model. It may happen if hardware manufacturers and Linux hypervisor suppliers get together and produce thin Linux VM operating systems.
Ah, but will they? It would be great if they did because it would remove at a stroke the Windows and Unix VM tax, in terms of both license money and memory occupancy, that inhibits the full exploitation of both server and desktop virtualisation technology. ®