FV domain fails to boot after upgrading to SLES 11 SP1

This document (7007137) is provided subject to the disclaimer at the end of this document.

Environment

SUSE Linux Enterprise Server 11
SUSE Linux Enterprise Server 11 Service Pack 1
SUSE Linux Enterprise Server 10 Service Pack 3

Situation

The host system/Dom0 has been upgraded from SUSE Linux Enterprise Server (SLES) 11 to SLES 11 Service Pack (SP) 1.
Starting a fully virtualized (FV) DomU fails, since it is unable to boot. The domain will be terminated shortly after it has been started.

The DomU has more than one disk defined. It could be a configuration like the following in the domain configuration file :
disk=[ 'file:/var/lib/xen/images/sles11sp1-fv1/xvda,xvda,w', 'file:/extdisk/img/sle11sp1/SLES-11-SP1-DVD-x86_64-GM-DVD1.iso,hdc:cdrom,r', ]
Here both a file-backed disk and another one being an ISO image is defined.

Resolution

The root cause of this problem is in-consequent naming of the disk devices, mixing xvdx and hdx disk device names in the domain configuration. Some user or tool in earlier versions may have defined a disk for the FV domain as xvda, whereas the correct name would be hda. At a later stage, a disk definition using the correct naming has then added, which after upgrading to SLES 11 SP1 (Xen 4.0) now leads to this problem.

Background :
For FV machines, it is good practice to name virtual disk hdx (or sdx for SCSI emulation). Disks named xvdx do still work due to a function in Xen that maps xvdN to hdN when booting the domain.
However, when a domain has a mix of disks named xvdx and hdx, then the mapping might fail in case e.g. both an xvda and hda is defined for the domain.

To establish whether the device naming is the exact problem causing the start of the DomU to fail, view the /var/log/xen/qemu-dm-<domain-name>.log of the domain in question.
If an error like the following exists in the beginning of the file :
qemu: ignoring not-understood drive `xvda'
then the domain is hit by this problem.

The tolerant behavior of allowing this mix is due to a bug in Xen 3.3 on SLES 11, which does not check for coexistence of both xvdx and hdx devices for a domain.
In Xen 4.0 shipping with SLES 11 SP1 that bug has been fixed, which leads to the stricter behavior that in turn cause ill-defined domains to fail to boot.
If both disks named xvdx and hdx exist in a domain definition, all xvdx devices are ignored during domain start due to the obvious risk of collisions.

Solution :
There are more ways to resolve the problem :
Scenario 1 :
A CD/DVD definition (e.g. named hdc) has been added to the existing disk(s) named xvd*
Either remove the CD definition or change it from hdx to xvdx in the domain configuration file as follows :

Change xvd to hd in the disk definition part of the domain config file
Update the domain definition in the xen-store with
```
# xm new
```
Start the domain

Scenario 2 :
Boot disk is on a device named xvdx and other disk(s) named hdx exist. It is not possible to remove any of the disk definitions.
The recommended solution is to eliminate use of xvd devices :

Mount the root (and boot if separate) partitions of the domain at fault as described in the cool solution Mount/access Files Residing on Xen Virtual Machines
Replace all occurrences of /dev/xvd with /dev/hd in the following files :

/boot/grub/device.map
/boot/grub/menu.lst
/etc/fstab

This can securely be done with a sed one-liner like :
sed -i 's/\/dev\/xvd/\/dev\/hd/g' $FILE

Unmount the disk file(s)
Change xvd to hd in the disk definition part of the domain config file
Update the domain definition in the xen-store with
```
# xm new
```
Start the domain

Disclaimer

This Support Knowledgebase provides a valuable tool for SUSE customers and parties interested in our products and solutions to acquire information, ideas and learn from one another. Materials are provided for informational, personal or non-commercial use within your organization and are presented "AS IS" WITHOUT WARRANTY OF ANY KIND.