Xen is an open-source type-1 or baremetal hypervisor which has the following structure:
The Xen Hypervisor is an exceptionally lean, less than 150,000 lines of code, software layer that runs directly on the hardware and is responsible for managing CPU, memory, and interrupts. It is the first program running after the boot-loader exits. The hypervisor itself has no knowledge of I/O functions such as networking and storage.
The Control Domain, or Domain 0, is a specialized Virtual Machine that has special privileges like the capability to access the hardware directly, handles all access to the system’s I/O functions and interacts with the the other Virtual Machines. It also exposes a control interface to the outside world, through which the system is controlled. The Xen hypervisor is not usable without Domain 0, which is the first VM started by the system.
Guest Domains/Virtual Machines are virtualized environments, each running their own operating system and applications. Xen supports two different virtualization modes: Paravirtualization (PV) and Hardware-assisted or Full Virtualization (HVM). Both guest types can be used at the same time on a single Xen system. It is also possible to use techniques used for Paravirtualization in an HVM guest: essentially creating a continuum between PV and HVM. This approach is called PV on HVM. Xen guests are totally isolated from the hardware: in other words, they have no privilege to access hardware or I/O functionality. Thus, they are also called unprivileged domain, or DomU.
xenrecSystemDataRecorder agents can be installed on dom0 or domU guests. To have the best visibility and accuracy we need to place all data recorders on dom0. There have been some comparative measurements between dom0 and domU and SDR, where we can see the difference between guest and host regarding data recording.
However during these measurements, one part, missing was the possibility to report per guests metrics directly from dom0. Welcome xenrec, a simple utility based on xentop , a standard Xen administrative tool.
Why xenrec ?In short, because xentop does not record time series data, in a CSV format, simple to be consumed by systems like RRDtool or R Statistical. More xentop utility is an interactive tool, designed in general to be run from the terminal and visual check the results. You could run xentop and use other tools like awk, sed etc to parse and store data on disk. But we want something simple and easy to be used.
So, we did use xentop to record domain statistics and handle all output using Perl, with final results:
Tip: we used xentop -b -d1 -i2, inside our Perl agent. Why not -d0 ? Take a look:
|xentop, 9 columns output, delay 0 seconds|
Using a delay of 0 seconds will add an overhead on the dom0 for xentop and xenrec. So we don't want that. Increasing to 1second for example will make things different:
|xentop, 9 columns output, delay 1 second|
Performance Metricsxenrec will record all xentop reported parameters, which unfortunatelly are not proper documented under xentop manual page nor help system. Thats another reason we wanted to add xenrec to SystemDataRecorder, better documentation.
The metrics below, using help function, -h:
|xenrec, help usage funtion|