Archived/Xen 4.3 RC1 test instructions

What needs to be tested

General things:

• Making sure that Xen 4.3 compiles and installs properly on different software configurations; particularly on distros
• Making sure that Xen 4.3, along with appropriately up-to-date kernels, work on different hardware.

Specific features:

• Automatic NUMA placement of guests.
• Upstream Qemu for HVM domains
• Openvswitch integration
• Xen on ARM
• others?

Installing

Getting RC1

• xen: Pull from the main repo, and update to tag 4.3.0-rc1:

git clone -b 4.3.0-rc1 git://xenbits.xen.org/xen.git

• tarball: Xen 4.3.0 RC1 Tarball (and signature)

Building

Instructions are available for building Xen on Linux and NetBSD.

Test instructions

General

• Remove any old versions of Xen toolstack and userspace binaries (including qemu).
• Download and install the most recent Xen 4.3 RC, as described above. Make sure to check the README for changes in required development libraries and procedures. Some particular things to note:
  • In Xen 4.3 the default installation path has changed from /usr to /usr/local. Take extra care when removing any old versions to allow for this.

Once you have Xen 4.3 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.

In particular if you are still using the (deprecated) xm/XEND toolstack please do try your normal use cases with the XL toolstack. The XL page has some information on the differences between XEND and XL. As do the instructions from the Xen 4.2 test day.

Specific Test Instructions

Automatic NUMA placement of guests

TBD

Upstream Qemu for HVM domains

In Xen 4.3 we have switched to using upstream qemu (which xl calls "qemu-xen") to provide the device model when running HVM guests instead of the older Xen fork of Qemu (which xl calls "qemu-xen-traditional). Interesting things to test in this context:

• Does the new device model support the guest OSes which you use, can you install as you would have with the old device model?
• Do features behave as expected, e.g. migration, VNC console.
• Do previously installed HVM guests, installed with qemu-xen-traditional, work when switched to qemu-xen?
  • It is expected that some guest types will not like the change in hardware which this entails. In this case is setting device_model_version="qemu-xen-traditional" in the guest configuration sufficient to make the guest OS happy again?
  • If the guest doesn't seem to mind this change then this is useful information, please report it to us.
  • Note: The new device model does not yet support stubdomains and so the default is unchanged if you request stubdomains.
• Does the old device model still work if you set device_model_version="qemu-xen-traditional" in the guest configuration?
• Do new features enabled by the new device model, such as QXL graphics, work?

Openvswitch integration

Xen 4.3 adds support for Open vSwitch based networking in addition to the existing bridge and routed networking schemes.

In order to test this you will need to setup a host with openvswitch support. Information on this is available at http://openvswitch.org/support/. In summary you need to:

• Install a domain 0 kernel with CONFIG_OPENVSWITCH enabled (any recent PVOPS kernel should have this option).
• Install the Open vSwitch userspace, see http://openvswitch.org/download/.
• Configure the host networking to use Open vSwitch instead of bridge.

e.g. to create a switch (which we will call xenbr0 to simplify the transition) and add eth0 as a physical port:

# ovs-vsctl add-br xenbr0
# ovs-vsctl add-port xenbr0 eth0

These appear to be persistent reboot, so only need to be done once. Now you should arrange to add an IP address to xenbr0, e.g. under Debian create an entry in /etc/network/interfaces:

auto xenbr0
iface xenbr0 inet dhcp

(remember to remove/comment any bridge related items like bridge_ports eth0)

Once the host is configured you need to configure the system to use vswitch for guests. You can do this by editing /etc/xen/xl.conf and setting:

vifscript=vif-openvswitch

Now you can try starting your guests and performing the usual operations on them (e.g. reboot, migrate etc) and verify that the network is accessible to the guest.

Xen on ARM

TBD

Reporting Bugs (& Issues)

• 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.

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.3.0-RC1 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!