Database Reference
In-Depth Information
main lines of work: making Linux work as a guest domain (domU) and allowing it to boot as a control domain (dom0).
Both efforts are grouped under the heading “pvops,” or para-virtualized ops. The aim of the pvops infrastructure for
Xen was to provide a single kernel image for booting into the Xen and non-Xen roles. The rewriting of a lot of code
has been necessary to comply with the strict coding quality requirements of the mainline kernel. Starting with Kernel
2.6.24, domU support has been gradually added with each release, and the xen.org wiki states that as of 2.6.32.10
domU support should be fairly stable. It was more problematic to get dom0 support into the upstream kernel,
and many times the Xen code was not allowed to exit the staging area. The breakthrough came with kernel 2.6.37,
explained in an exciting blog post by Konrad Rzeszutek Wilk: “Linux 3.0 - How did we get initial domain (dom0)
support there?” Although 2.6.37 offered very limited support to actually run guests, at least it booted, and without
the forward-ported patches from 2.6.18. With Linux kernel 3.0, dom0 support was workable and could be included in
Linux distributions.
Although there was a time, shortly after Red Hat announced they would not support a Xen dom0 in Enterprise
Linux 6, that the future of Xen looked bleak, thanks to the many talented and enthusiastic individuals, Xen is back.
And it did not come a moment too soon: the advances in processor technology made the full-virtualization approach
a worthy contender to para-virtualization. Today, it is claimed that the virtualization overhead for fully virtualized
guests is less than 10%.
During its development, Xen has incorporated support for what it calls hardware virtualization. You previously
read that para-virtualized operating systems are made aware of the fact that they are virtualized. Para-virtualization
requires access and modifications of the code. Closed source operating systems, such as Windows, for example,
therefore, could initially not be run under Xen, but this has been addressed with Xen version 3.x. Thanks to hardware
virtualization support in processors, Xen can now run what it refers to as Hardware Virtualized Machines (HVM).
Virtualization support in x86-64 processors is available from Intel and AMD. Intel calls its extensions VT-x, AMD call
their support AMD-V, but it is often found as “Secure Virtual Machine,” as well in the BIOS settings and literature.
As part of the initiatives to do more work in the processor, another set of bottlenecks has been tackled by the chip
vendors. Recall from the previous discussion that the memory structures of the guests had to be carefully shadowed
by the hypervisor, causing overhead when modifying page tables in the guest. Luckily, this overhead can be reduced
by using Extended Page Tables (EPT) in Intel processors or the AMD equivalent called Rapid Virtualization Indexing
(RVI). Both technologies address one of the issues faced by the virtual machine monitor or hypervisor: to keep track
of memory. In a native environment, the operating system uses a structure called page table to map physical to virtual
addresses. When a request is received to map a logical to physical memory address, a page table walk or traversal of
the page tables occurs, which is often slow. The memory management unit uses a small cache to speed up frequently
used page lookups, named Translation Lookaside Buffer or TLB.
In the case of virtualization, it is not that simple. Multiple operating systems are executing in parallel on the host,
each with their own memory management routines. The hypervisor needs to tread carefully and maintain the image
for the guests running on “real” hardware with exclusive access to the page tables. The guest, in turn, believes it has
exclusive access to the memory set aside for it in the virtual machine definition. The hypervisor needs to intercept and
handle the memory related calls from the guest and map them to the actual physical memory on the host. Keeping the
guest's and the hypervisor's memory synchronized can become an overhead for memory intensive workloads.
Extended Page Tables and Rapid Virtualization Indexing try to make the life easier for the hypervisor by speeding
up memory management with hardware support. In an ideal situation, the need for a shadow page table is completely
eliminated, yielding a very noticeable performance improvement.
The advances in the hardware have led to the interesting situation that Xen HVM guests can perform better
under certain workloads than PVM guests, reversing the initial situation. HVM guests can struggle when it comes to
accessing drivers. Linux benefits from so called PV-on-HVM drivers, which are para-virtualized drivers, completely
bypassing the hardware emulation layer. Less code path to traverse provides better performance for disk and network
access. Para-virtualized drivers also exist for Windows and other platforms. This is not to say that you should start
using hardware virtualizing all your operating systems, but there might be a workload, especially when the guest's
page table is heavily modified where PV-on-HVM can offer a significant performance boost.
 
Search WWH ::




Custom Search