Archived/Xen 4.3 RC1 test instructions: Difference between revisions
No edit summary |
No edit summary |
||
Line 10: | Line 10: | ||
* Openvswitch integration |
* Openvswitch integration |
||
* Xen on ARM |
* Xen on ARM |
||
* |
* ''others?'' |
||
= Installing = |
= Installing = |
||
Line 31: | Line 31: | ||
** In Xen 4.3 the default installation path has changed from <code>/usr</code> to <code>/usr/local</code>. Take extra care when removing any old versions to allow for this. |
** In Xen 4.3 the default installation path has changed from <code>/usr</code> to <code>/usr/local</code>. 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 scripts still work |
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_RC2_test_instructions|Xen 4.2 test day]]. |
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_RC2_test_instructions|Xen 4.2 test day]]. |
||
Line 43: | Line 43: | ||
=== Upstream Qemu for HVM domains === |
=== 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: |
|||
TBD |
|||
* 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 <code>device_model_version="qemu-xen-traditional"</code> 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 <code>device_model_version="qemu-xen-traditional"</code> in the guest configuration? |
|||
* Do new features enabled by the new device model, such as QXL graphics, work? |
|||
=== Openvswitch integration === |
=== Openvswitch integration === |
Revision as of 11:58, 29 April 2013
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.
- In Xen 4.3 the default installation path has changed from
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.
- It is expected that some guest types will not like the change in hardware which this entails. In this case is setting
- 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
TBD
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!