The very basic idea of the microkernel is that by isolating certain services and drivers to their own isolated address space with a safe API to interface with the microkernel, if a certain driver crashes it won't bring down and destabilize the entire system. You can imagine how much it helps not to bring down the whole system if the SATA driver crashes, or if the ext3 filesystem crashes.

However, such failures don't always result in loss of functionality. For example, a pure firewall may be ok with such a failure, because the network packets will pass through regardless of the I/O not being functional. You can imagine how much it helps to keep doing I/O just fine if the TCP stack or the ethernet driver crashes, and no network packet can reach the server anymore, or if the data received from the network is corrupted. So, for the majority of services a failure is fatal to the operation of the whole system. In a fault-tolerant setup the secondary should takeover when a failure happens regardless if the microkernel of the primary is still alive.

Those design issues that have been common to all OS for the last decades, and have parallels in the virtualization world too. For example, if an hypervisor is stripped of all the drivers in order to do only memory management and scheduling of the virtual machines, much like a microkernel, and it relies on a monlithic kernel living in its own separate and securely isolated address space for all drivers and I/O, that will imply a slowdown in the API. Because it will require a privilege level change for any privileged operation that involves the hardware. It doesn't really bring any benefit in security terms if there's a little bug in the SATA driver of the "trusted" monolithic kernel that has to take care of all the I/O. This without mentioning the fact that without VT-d or proper iommu support a buggy driver can overwrite the hypervisor with DMA.

Furthermore, as the requirements for advanced virtualization features increase, this stripped-off hypervisor will have to either grow in size by including a lot more code and algorithms that will make it look closer and closer to a real OS, and in turn diminishing the benefit of the effort of keeping most drivers in a separate address space, or alternatively it would need to grow its API with the OS doing the I/O and in turn it would run slower and slower and more complex by keeping many critical algorithms in a different privilege level.

Next: Linux Advantages as a Hypervisor »