Xen 4.13 RC test instructions: Difference between revisions
Lars.kurth (talk | contribs) m (→Known issues) |
|||
(2 intermediate revisions by 2 users not shown) | |||
Line 44: | Line 44: | ||
* '''RC1:''' xen-shim may not build and may fail to install |
* '''RC1:''' xen-shim may not build and may fail to install |
||
* '''RC2+:''' mini-os contains save/restore |
* '''RC2+:''' mini-os contains save/restore of minios - a new feature - which does is not currently supported by our toolstacks. However, this change is not yet available in RC1 |
||
* '''For changes between 4.11 and 4.12, see [[Xen_4.12_RC_test_instructions#Known_issues|4.12 known issues]]:''' there were some namespace changes, which you may trip over if your previous version of Xen was older than 4.12 |
* '''For changes between 4.11 and 4.12, see [[Xen_4.12_RC_test_instructions#Known_issues|4.12 known issues]]:''' there were some namespace changes, which you may trip over if your previous version of Xen was older than 4.12 |
||
Line 82: | Line 82: | ||
== Specific x86 testing instructions == |
== Specific x86 testing instructions == |
||
=== |
=== Core scheduling === |
||
In order to activate core scheduling in Xen you need to install Xen as usual and boot with the following option added to the command line: |
|||
sched-gran=core |
|||
1. Call `make menuconfig` in xen directory. |
|||
2. Enter "Architecture Features" submenu. |
|||
3. Select "PV support" / "HVM support" as you see fit. |
|||
This will result in the hypervisor no longer scheduling vcpus individually on physical cpus, but to combine vcpus to virtual cores and scheduler those on physical cores. |
|||
Or you can edit existing config file by adding or changing CONFIG_HVM and CONFIG_PV options. |
|||
To run an HVM-only hypervisor, you must use a Dom0 kernel capable of booting as PVH guest. Linux 4.19 kernel is a good start. |
|||
=== Qemu Deprivilege === |
|||
Testing QEMU deprivileging involves two basic steps; |
|||
# Setting up appropriate usernames for libxl to use |
|||
# Setting <code>dm_restrict=1</code> in the xl config file. |
|||
See the [http://xenbits.xen.org/docs/unstable/features/qemu-deprivilege.html QEMU feature documentation] for details on how to set this up, as well as what features and restrictions still need to be implemented. |
|||
=== PVH domU boot via grub2 === |
|||
grub2 has gained support for Xen PVH guests recently. In order to test that you need to build grub2 for <code>xen_pvh</code>: |
|||
git clone git://git.savannah.gnu.org/grub |
|||
cd grub |
|||
./configure TARGET_LDFLAGS=-static \ |
|||
--prefix=/usr \ |
|||
--sysconfdir=/etc \ |
|||
--target=i386-suse-linux \ |
|||
--with-platform=xen_pvh \ |
|||
--enable-device-mapper |
|||
make |
|||
cat > ./grub.cfg <<EOF |
|||
insmod part_msdos |
|||
insmod part_gpt |
|||
insmod search |
|||
insmod configfile |
|||
insmod legacy_configfile |
|||
if search -s root -f /boot/grub2/grub.cfg ; then |
|||
configfile /boot/grub2/grub.cfg |
|||
elif search -s root -f /@/boot/grub2/grub.cfg ; then |
|||
configfile /@/boot/grub2/grub.cfg |
|||
elif search -s root -f /boot/grub/menu.lst ; then |
|||
legacy_configfile /boot/grub/menu.lst |
|||
elif search -s root -f /grub2/grub.cfg ; then |
|||
configfile /grub2/grub.cfg |
|||
elif search -s root -f /grub/menu.lst ; then |
|||
legacy_configfile /grub/menu.lst |
|||
fi |
|||
EOF |
|||
./grub-mkstandalone --grub-mkimage=./grub-mkimage -o grub.xen_pvh -O i386-xen_pvh -d grub-core/ "/boot/grub/grub.cfg=./grub.cfg" |
|||
The resulting binary <code>grub.xen_pvh</code> can then be used as the kernel in the guest configuration file. It will boot in PVH mode and use the <code>grub.cfg</code> file on the guest's disk. |
|||
=== PVH Dom0 === |
=== PVH Dom0 === |
Latest revision as of 14:19, 14 October 2019
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. |
What needs to be tested
General things:
- Making sure that Xen 4.13 compiles and installs properly on different software configurations; particularly on distros
- Making sure that Xen 4.13, 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.13 will work on the board that you use. If you want to see which boards need testing, check Xen ARM Manual Smoke Test/Results.
Installing
Getting a RC
For the expressions/examples below, set the following bash/sh/... variable to the release candidate number (e.g. one of rc1
, rc2
, ... )
RC="<release candidate number>" # rc1, rc2 ...
Important notes:
For RC1: RC=rc1 (see #RC1)
From xen.git
With a recent enough git
(>= 1.7.8.2), just pull from the proper tag (4.13.0-$RC
) from the main repo directly:
git clone -b 4.13.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.13.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.13.0-$RC
From tarball
Download:
https://downloads.xenproject.org/release/xen/4.13.0-$RC/xen-4.13.0-$RC.tar.gz https://downloads.xenproject.org/release/xen/4.13.0-$RC/xen-4.13.0-$RC.tar.gz.sig
Building
Instructions are available for building Xen on Linux, NetBSD, and FreeBSD
Known issues
- RC1: xen-shim may not build and may fail to install
- RC2+: mini-os contains save/restore of minios - a new feature - which does is not currently supported by our toolstacks. However, this change is not yet available in RC1
- For changes between 4.11 and 4.12, see 4.12 known issues: there were some namespace changes, which you may trip over if your previous version of Xen was older than 4.12
Test instructions
General
- Remove any old versions of Xen toolstack and userspace binaries (including
qemu
). - Remove any Xen-related udev files under /etc because Xen 4.13 doesn't use those anymore.
- Download and install the most recent Xen 4.13 RC, as described above. Make sure to check the
README
andINSTALL
for changes in required development libraries and procedures. Some particular things to note:
Once you have Xen 4.13 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.
Credit2 is now the default scheduler
For more information see [1] and [2] - see the Testing Section for more information on testing.
Specific ARM Test Instructions
Follow Xen_ARM_with_Virtualization_Extensions and Xen_ARM_with_Virtualization_Extensions#Testing
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.13, 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.
Dom0less
To Do:
Stefano to add some information here - also see http://xenbits.xen.org/docs/unstable/features/dom0less.html |
Small Arm default configurations for specific boards
To Do:
Stefano to add some information here - also see https://markmail.org/message/fzhiaskqon26ybja |
Specific x86 testing instructions
Core scheduling
In order to activate core scheduling in Xen you need to install Xen as usual and boot with the following option added to the command line:
sched-gran=core
This will result in the hypervisor no longer scheduling vcpus individually on physical cpus, but to combine vcpus to virtual cores and scheduler those on physical cores.
PVH Dom0
In order to setup a PVH dom0 you need to install Xen as usual and boot with the following option added to the command line:
dom0=pvh
Note that it's recommended to also set the amount of dom0 memory, since the automatic calculations are not very accurate:
dom0_mem=8g
Finally, a Linux kernel >= 4.18 or FreeBSD >= 12.0 is required in order to boot into PVH dom0 mode.
Support for AMD is still very experimental, and currently it's not possible to create guests from a PVH dom0 when using AMD hardware.
RC specific things to test
RC1
None for now.
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 - jgross at suse dot com).
Reporting success
We would love it if you could report successes by e-mailing xen-devel@lists.xen.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.13.0-<Some RC>
for testing, please make sure you state that information!
Subject: [TESTDAY] Test report * Hardware: * Software: * Guest operating systems: * Functionality tested: * Comments:
For example:
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!