To keep things simple, let's assume that
there's a single CPU. Each guest operating
system is already multiplexing the processes that
it is currently hosting on the CPU
in a non-virtualized setting also. So each operating system. Has a ready que of
processes, that can be scheduled on the
CPU, but there is this hypervisor that is
sitting in between a guest operating system. It's already qued and the CPU.
So the first part of what the hypervisor has to do is to give an illusion of
ownership of the CPU for each of
the virtual machines. So that each virtual machine
can schedule the processes that it currently has
in it's very queue on the CPU. So,
if you look at it from the hypervisor's point of view, it has to have a precise
way of accounting the time that a particular VM uses on the CPU. From the point
of view of billing the different customers, that
is the key thing that hypervisor is worried
about that it gave the CPU for a
certain amount of time to this VM, certain amount
of time to this VM and so on. Now for the time that has been allocated for
instance this virtual machine. How this virtual machine is using the CPU
time, what processes is scheduling on the
CPU? The hypervisor doesn't care about that.
So commensurate with borderware is a scheduling
policy enforced in a particular guest operating system.
That guest operating system. Is free to
schedule its pool of processes on the CPU
for the time that has been given to it by the hypervisor. Now, similar to the
policy that we discussed for memory allocation.
One straightforward way to share the CPU among
the guest operating systems, is to give a
share. Of the CPU. A proportional share of
the CPU for each guest operating system, demonstrates with the service
agreement, that this virtual machine has with the hypervisor. This
is called a proportional share scheduler and it is used in the VM-ware
ESX server. Another approach is to use a fair share
scheduler. Which is going to give a fair share of the CPU for
each of the guest operating systems. An
equal share to each of the guest operating
systems. Running on top of the hypervisor. Most
of these strategies, proportion, share scheduler, or a
fair share scheduler are straight-forward conceptual mechanisms. And
you can learn more about them from the
assigned readings for this course. In either of
these cases, the hypervisor has to account for
the time used on the CPU on behalf
of a different guest during the allocated time for
a particular guest. And this can happen for
instance if there is an external interrupt that is
feeded by the CPU that is intended for
this VM while a process that belongs to this
VM is going to be executing on the CPU.
So this is accounting that the hypervisor would keep
to make sure that. Any time that was stolen away from a particular
VM in order to service an external interrupt that did not belong to this
VM, it'll get rewarded for later on by the accounting procedure in the
Hypervisor. We have discussed this issue already
in the concept of operating system extensibility,
specifically when we discussed the [UNKNOWN]
approach to extensibility. So, it's not new
problem. It is just that this problem occurs in the hypervisor setting also.