SystemDataRecorder is offering several data recorders for different jobs: overall system utilization, per-CPU, per-NIC utilization along with many others. On systems where we use virtualization in general we can monitor the guests directly or if we want more accurate numbers, we will need to monitor the host. The purpose of this short article is to show how you can use SystemDataRecorder to record Xen performance metrics.

Xen Hypervisor

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.

Xen dom0

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.

Xen domU

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. 


SystemDataRecorder 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
Very clear that xentop -b -d1 -i2 will do nicely the job.

Performance Metrics

xenrec 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
We will soon add xenrec to our data recorders and make available the source code under SystemDataRecorder repository.




Popular posts from this blog

Raspberry Pi and Redis

Asus Zenbook and FreeBSD 11

Asus Zenbook UX32VD and FreeBSD 11, part two