How to Build a Software Defined System
Another approach to virtualization is to modify the source code of the guest operating system. If we can do that, not only can we avoid problematic instructions but we can also include optimizations. For instance, letting the guest operating system see real hardware resources, underneath the hypervisor, access to real hardware resources and also being able to employ tricks such as page coloring, exploiting the characteristics of the underlying hardware.
It is important to note, however that so far as the applications are concerned, nothing is changed about the operating system because the interfaces that the applications see is exactly the interfaces provided by the operating system. If there is an application that is running on Windows, it sees the same API. If the application is running on top of Linux, it sees exactly the same API as it would if this Linux operating system was running on native hardware.
In this sense, there is no change to the applications themselves. But the operating system has to be modified in order to account for the fact that it is not running on bare metal, but it is running as a guest of the hypervisor.
This is why this technology is often referred to as Para virtualization, meaning it is not fully virtualized, but a part of it is modified to account for being a guest of the hypervisor. The Xen product family uses this para virtualization approach. Now this brings up an interesting question.
In order to do this para-visualization we have to modify the operating system, but how big is this modification?
Even though, in para-virtualization we have to modify the operating system to run on top of the hypervisor, the amount of code change that has to be done in the operating system in order to make it run on top of the hypervisor can be bound to a very small percentage of the total code base of the original operating system. Which is good news.