- Improved report submission
- Fixes to some tests
- Updated XFAIL tests
- New test group: block-create
We would really like to get people running xm-test on a regular basis,
so that we can start to get some ideas about regression trends from
the submitted data.
* For those who are not familiar with xm-test:
Several of us here at IBM have been working on a framework for testing
the xen tools, specifically xm. Our goal is to provide a way for
developers to _easily_ write tests for new and existing xm commands.
We believe that such a test suite will help reduce breakages in the
user-facing tools when developers modify xm and/or xend.
We would like some feedback from the community on the usefulness of
our framework, in hopes that it might be hosted by xensource so that
everyone can contribute tests to help harden xm and xend.
The framework tests (as well as the support libraries) are written in
python, which are executed by the standard automake "make check"
facilities. We build a standardized ramdisk that can be used for
portable test writing, therefore reducing dependencies on the test
The framework library provides several abstractions to make common and
complex tasks easier for the test writer. For example, we provide a
domain and console abstraction that allows a test writer to start a
domU and execute arbitrary commands, retrieving the status and output
of each. This allows a decent amount of automation for verifying that
(for example) "xm sysrq mydomain s" actually sent the sysrq.
IBM Linux Technology Center
Open Hypervisor Team
email: [hidden email]
> We would like some feedback from the community on the
> usefulness of our framework, in hopes that it might be hosted
> by xensource so that everyone can contribute tests to help
> harden xm and xend.
We're big fans of the xm-test work, and certainly want to encourage
xm-test has already beed incorporated into the XenRT suite -- it's even
part of the 'fast' programme that will be used for validation before
pushing changesets out to xenbits.