Hypervisor : Monolithic Vs. Micro
Hi,
this will be a quick review about 2 approaches for Hypervisor implementation which is the basis to any part of an enterprise virtualization server both MS or other.. this is a high technical review and I’ll try not to dig really deep and yet explain the basics.
OK ! so there are 2 parts of virtualization platform before even getting in to Hypervisor and its important to understand both, you all know the products so I’ll be rapid.
VMM – Virtual machine monitor is the part of the product that actually simulate to the guest OS what it needs to be installed, like hardware, CPU and memory access .. there are 2 kinds of VMM’s:
- One is a hosted VMM that actually share hardware resources with host OS, examples are: Virtual PC, VMware Workstation and KVM.
- Another VMM approach is the Hypervisor VMM which runs alone on the hardware, the most common products are : Hyper-V, VMware ESX and Xen…
A few quick words on the name ‘Hypervisor’, the bad news is that MS didn’t invent this name :), Hypervisor is an IBM name. In the old age .. when mainframe was the most common computing systems it could run a few supervisor (IBM name for Operation System before the term OS has been created) and they wanted to run multiple supervisor on the same mainframe but they had to come up with a name for a UBER-supervisor that will monitor and control all those other supervisor.. so they sat down and came up with ‘Hypervisor’ as a name for this function.
A monolithic Hypervisor is an architecture that replace OS Kernel with its own, it is simpler then modern kernel but still a very complex one, holds its own Driver model and needs to be supported by HW Vendors, a good example for Monolithic Hypervisor will be VMware ESX.
A Micro-Hypervisor is relativity simpler way on doing it , its still very complex but with simple partitioning functionality, increased reliability while minimizing TCB. this implementation of hypervisor is well implemented in Microsoft Hyper-V and the most important thins is that you don't have to make HW vendor create 2 sets of drivers, we have them for Windows and therefore extremely minimize 3rd-party code usage.
now days the most common virtualization platform is VMware, the technological difference is already discussed by me on an earlier post but the “tax” HW vendors pay in order to be compatible with VMware products needs to be reviewed by both the vendors and VMware, now days its OK to vendor to pay this tax an invest on building drivers for ESX themselves because it means that they can sell more powerful machines is a higher amount of money,
now that Microsoft is in the game of building products that will compete with ESX, vendors needs to ask themselves “is this forth it?" ,VMware on her side needs to think about it… and make sure they wont loose this technological and HW vendors edge..
In the end we’re as IT PRO’s are the main benefiters of those dark battles between the light and dark forces (I’ll let everyone choose its own side) we have diversity in products motivated by 2 different approaches to the same subject …
That’s it for today
Thanks for reading.
Ido