Information Technology Reference
In-Depth Information
performance (exclusive of slowdown caused by competition for resources with
other virtual machines running at the same time, of course).
Integrated design of software and hardware was not as straightforward in the
x86 marketplace, where hardware designers (Intel, AMD) do not create hypervi-
sors (VMware ESX, VirtualBox, Hyper-V, Xen), or operating systems (Microsoft
Windows, Oracle Solaris, Linux distributions). Nevertheless, the increased im-
portance of virtualization in the x86 marketplace has led AMD and Intel to cre-
ate architectural enhancements to their products that reduce “trap and emulate”
context switches and make virtualization more efficient. Paravirtualization is now
used by all the hypervisors to reduce or eliminate guest execution of privileged
instructions.
Oracle's Chip Multithreading (CMT) servers with Solaris guests under the
Oracle VM for SPARC (Logical Domains) hypervisor benefit from coordinated
designs to solve this problem. The Logical Domains hypervisor dedicates CPU
strands (virtual CPUs) to each domain rather than sharing them among all
guests, so a guest does not have to be restricted from changing processor state.
This strategy was made possible by defining a new
sun4v
CPU architecture (other
contemporary SPARC servers use the
sun4u
architecture) and porting Solaris to
it to the extent needed to exploit CMT's paravirtualization. Context switching has
been moved into the processor architecture, where it can be performed much more
quickly than in software, requiring only a single clock cycle. Solaris Containers
solve this problem even more directly: Only one kernel exists, no matter how
many virtual environments are present in Containers, and application system
calls invoke the kernel in the same way whether they reside in a Container or not.
These architectures eliminate instruction emulation's complexity and overhead.
The Question of Time (Does Anybody
Really Know What Time It Is?)
A problem first faced by early hypervisors is “clock skew,” a situation in which
time proceeds in a virtual machine at a different rate than on the real hardware.
A guest operating system has no way of knowing that between two sequential
instructions it may have been interrupted by the hypervisor and delayed for an
arbitrary amount of time. Perhaps the hypervisor decided to run a different guest
for a few milliseconds, or the guest suffered a page fault and stalled until a page
was brought in from disk. In either case, real “wall clock time” advanced, while
virtual clock time stayed the same.
Clock skew between virtual and actual time has significant consequences. The
time and date reported by a virtual machine might be wrong, or interval-based
time slicing within a guest may fail to work correctly.
Search WWH ::
Custom Search