Xen 4.8 RC test instructions
|If you come to this page before or after the Test Day is completed, your testing is still valuable, and you can use the information on this page to test, post any bugs and test reports to xen-devel@. If this page is more than two weeks old when you arrive here, please check the current schedule and see if a similar but more recent Test Day is planned or has already happened.|
- 1 What needs to be tested
- 2 Installing
- 3 Known issues
- 4 Test instructions
- 4.1 General
- 4.2 Specific ARM Test Instructions
- 4.3 Specific x86 testing instructions
- 4.4 RC specific things to test
- 5 Reporting Bugs (& Issues)
- 6 Reporting success
What needs to be tested
- Making sure that Xen 4.8 compiles and installs properly on different software configurations; particularly on distros
- Making sure that Xen 4.8, along with appropriately up-to-date kernels, work on different hardware.
For more ideas about what to test, please see Testing Xen.
ARM Smoke Testing
If you use ARM Hardware, which is not widely available or not rackable (and thus not part of our automated test suite), please check out Xen ARM Manual Smoke Test. Helping out to manually test ARM boards (which will only take a few minutes) will guarantee that Xen 4.8 will work on the board that you use. If you want to see which boards need testing, check Xen ARM Manual Smoke Test/Results.
Getting a RC
For the expressions/examples below, set the following bash/sh/... variable to the release candidate number (e.g. one of
rc2, ... )
RC="<release candidate number>" # rc1, rc2 ...
With a recent enough
git (>= 184.108.40.206), just pull from the proper tag (
4.8.0-$RC) from the main repo directly:
git clone -b 4.8.0-$RC git://xenbits.xen.org/xen.git
With an older
git version (and/or if that does not work, e.g., complaining with a message like this:
Remote branch 4.8.0-$RC not found in upstream origin, using HEAD instead), do the following:
git clone git://xenbits.xen.org/xen.git ; cd xen ; git checkout 4.8.0-$RC
- libxl deadlocks while trying to set memory target for a guest (fixed in http://xenbits.xen.org/gitweb/?p=xen.git;a=commit;h=031655daea9bb0f69ce54a32fea0eab319471d04)
- Build issues with gcc6 on ARM (fixed in http://xenbits.xen.org/gitweb/?p=xen.git;a=commit;h=cb8290f68410c6c951699abd3a24124627f3f1f2)
- Remove any old versions of Xen toolstack and userspace binaries (including
- Remove any Xen-related udev files under /etc because Xen 4.8 doesn't use those anymore.
- Download and install the most recent Xen 4.8 RC, as described above. Make sure to check the
INSTALLfor changes in required development libraries and procedures. Some particular things to note:
Once you have Xen 4.8 RC installed check that you can install a guest etc and use it in the ways which you normally would, i.e. that your existing guest configurations, scripts etc still work.
For more ideas about what to test, please see Testing Xen or the sections below. Note that typically specific tests for new features will be added around RC2.
Specific ARM Test Instructions
Boards and hardware we do not test in our CI Loop
Although we do have automated Test Infrastructure for the project, we only include rackable hardware into our CI Loop. We do have a mixture of Allwinner and Exynos processors in a custom chassis. If you have one of the following boards and want to ensure it runs on Xen 4.8, please make sure you run the Xen ARM Manual Smoke Test on an RC.
Boards not tested by our CI Loop: Allwinner sun6i/A31, DRA7[J6] EVM, Exynos5410, HiKey board from 96boards.org, Mustang (XC-1), OMAP5432, Renesas R-Car H2, Versatile Express and Xilinx Zynq Ultrascale MPSoC
We are also not able to include non-production servers that require a legal agreement such as an NDA into our Test Infrastructure.
Live Patching of the hypervisor (now also on ARM 32 and 64)
Live Patching is a Xen technology that enables to binary patch the running hypervisor with a payload file that is intended to primarily contain security updates (but not necessarily only so). v1 of Live Patching is in technology preview mode and compile-disabled by default. It also has some restrictions on what payloads can be encoded in the payload file. Xen 4.8 comes with built in Hypervisor support and the
xen-xsplice upload|apply|replace|revert tool to manage payloads (the code is in tools/misc). Additional tools such as
xsplice-build to create a payload are at this stage not shipped with Xen, but are available out-of-tree.
To test xSplice, check out:
- Build Xen with xSplice enabled, see Enabling xSplice in hypervisor
- Patch hypervisor as it is running. There are three simple built-in simple examples, see How to build built-in examples on how to build, install and test it.
- Alternatively, see xsplice-build-tools on how to build, install, and test it.
- Do this for the ARM32 and/or ARM64 architecture (new in Xen 4.8)
- Check restrictions for restrictions removed in Xen 4.8 and test these
- Works for Linux and FreeBSD dom0's only
- Cannot generate payloads for patches with .data sections in the ELF file (in other words, patches that introduce global or static variables cannot be encoded)
Building ARM64 guests with ACPI support
<TODO: Add Additional Feature here>
Specific x86 testing instructions
Building HVM guests
The way that HVM guest is built is rewritten in this release. Please test if creating a your usual HVM guests still works as expected.
HVM USB Passthrough
We can now use QEMU to emulate USB controllers and passthrough USB devices to HVM guests.
RC specific things to test
None for RC1.
Reporting Bugs (& Issues)
- Use Freenode IRC channel #xentest to discuss questions interactively
- Report any bugs / missing functionality / unexpected results.
- Please put [TestDay] into the subject line
- Also make sure you specify the RC number you are using
- Make sure to follow the guidelines on Reporting Bugs against Xen (please CC the relevant maintainers and the Release Manager - wei dot liu2 at citrix dot com).
We would love it if you could report successes by e-mailing
firstname.lastname@example.org, preferably including:
- Hardware: Please at least include the processor manufacturer (Intel/AMD). Other helpful information might include specific processor models, amount of memory, number of cores, and so on
- Software: If you're using a distro, the distro name and version would be the most helpful. Other helpful information might include the kernel that you're running, or other virtualization-related software you're using (e.g., libvirt, xen-tools, drbd, &c).
- Guest operating systems: If running a Linux version, please specify whether you ran it in PV or HVM mode.
- Functionality tested: High-level would include toolstacks, and major functionality (e.g., suspend/resume, migration, pass-through, stubdomains, &c)
The following template might be helpful: should you use
Xen 4.8.0-<Some RC> for testing, please make sure you state that information!
Subject: [TESTDAY] Test report * Hardware: * Software: * Guest operating systems: * Functionality tested: * Comments:
Subject: [TESTDAY] Test report * Hardware: Dell 390's (Intel, dual-core) x15 HP (AMD, quad-core) x5 * Software: Ubuntu 10.10,11.10 Fedora 17 * Guest operating systems: Windows 8 Ubuntu 12.10,11.10 (HVM) Fedora 17 (PV) * Functionality tested: xl suspend/resume pygrub * Comments: Window 8 booting seemed a little slower than normal. Other than that, great work!