Virtual Appliances:Xen Troubleshooting Guide

From rPath Wiki

Use the following information to troubleshoot your efforts installing or building a Xen™ virtualization solution using rPath technologies.

Troubleshoot a Dom0 Install

Ensure that you have used instructions provided in the rPath Linux Xen Dom0 HOWTO to install your rPL Xen Dom0. Use the following information to troubleshoot the installation.

Troubleshoot a DomU Install

Ensure that you have used instructions provided in the Virtual Appliances:Xen DomU Guide to install your Xen DomU. Use the following information to troubleshoot the installation.

Troubleshoot a DomU Build

Ensure that you have used instructions provided in either the rBuilder interface or the Conary command line to build your Conary-based Xen DomU. Use the following information to troubleshoot the installation.

Recook with New Flavors

If you recook an existing group with a new flavor, it should work without any additional steps. At the command line, this means cooking with the xen and domU flavors.

cvc cook group-example[xen,domU]

In the rBuilder interface, this means checking the option in Group Builder when you recook the group.

Failed Group Builds

A build could potentially fail for one of the following reasons:

Troves failed to replace in rBuilder

rBuilder is very specific about which troves it removes in order to resolve trove conflicts; troves may not removed when one is a different flavor than another. If you have a failed to replace message followed by path conflicts during the group build when you switch to a [xen,domU] flavor, this is likely the reason. This happens most commonly when you replace distro-release with your own distro-release for such reasons as to tailor the boot messages.

The quickest way to get back on track is to edit your group recipe by hand and remove the flavor and version that rBuilder's Group Builder tool has inserted. To do this, check out a copy of your recipe on the command line using cvc co distro-release and then edit the recipe. Locate the following line:

r.remove('distro-release', 'conary.rpath.com@rpl:devel//1/1.0.1-1-1', '[is: x86]')

Change this line to:

r.remove('distro-package', 'conary.rpath.com@rpl:1', '')

Using rpl:devel components

When including stuff from conary.rpath.com@rpl:devel, Conary can drag in glibc that is not Xen capable. Try choosing everything you need from the rpl:1 versions. If something is not available on rpl:1, try rpl:devel for just those components. (For example, pycurl and s3-curl from rpl:devel are acceptable but openssl is not. In general, anything on rpl:devel with soname dependencies will not work.)

Alternative group-core

If you include group-core from somewhere other than conary.rpath.com it may not be built with the [xen,domU] flavor. If you cook your own group-core, you will need to cook that with the [xen,domU] flavor.

Sub-groups that include conflicting components

If you have lower-level groups that include things that conflict (such as group-core), recook the lower level groups first with the [xen,domU] flavor.

Kernel modules not built for Xen

If you include kernel modules, they will not match the Xen kernel until you build [xen,domU] flavored kernel modules. You will need to build them relative to exactly the version of the domU kernel you will include; normally whatever is shown by the conary rq kernel=conary.rpath.com@rpl:1-xen[xen,domU] command.