Download Chapter 3. The Xen Hypervisor

Xen DomU guest images can also be imported over the network, as is the case when using NFS (for example,
nfs_server, nfs_path, and root parameters as shown later in this chapter and discussed in more detail in
Chapter 8, "Storing Guest Images"). Additional methods of importing a guest image over the network, such as
iSCSI or ATA over Ethernet (AoE), use the phy: prefix because Domain0 sees the exported network block device
in /dev (or directory within /dev). In these cases, you should also use the phy: prefix and specify the path to
the network block device relative to /dev, just as if it were a local disk. For example, when using iSCSI, you
should use the device node name that is given to the Domain0 by udev (the automatic device management
system used on most modern Linux distributions), because the sd* block device node will not necessarily be
consistent each time the iSCSI device is attached (to Domain0). The best way to do this is by using the
disk/by-uuid entry, which is actually a symbolic link to the corresponding /dev/sd* entry.
Listing 5.4 shows an example of iSCSI. We examine the details of iSCSI in greater detail in Chapter 8. In this
example the exported device will be /dev/disk/by-uuid/210936e7-6cc8-401f-980f-d31ec982ffa5, which is
actually a symbolic link the corresponding sd* device node found in /dev/. The DomU will see the device as
/ev/xvda, and it will have write access to the device. Be advised that the by-uuid support via the kernel and
udev was not supported in older Linux distributions, although we have found good support in the more recent
distributions that we have tested, such as Fedora and Ubuntu.
Listing 5.4. An iSCSI Example of a Disk Parameter Line
disk = ['phy:disk/by-uuid/210936e7-6cc8-401f-980f-d31ec982 ffa5,xvda,w']
For AoE, a similar strategy using udev is also possible and has been shown to work equally well. However, AoE
block devices found in /dev/etherd/ should be carefully managed in a consistent manner, otherwise multiple
guests may use the same device and cause corruption. In Listing 5.5, we demonstrate how you might export an
AoE device directly to a DomU. We examine the details of AoE in Chapter 8. In this example, the exported
device will be /dev/etherd/e1.1, which is the AoE device found in shelf one and slot one of the physical or
logical Ether drive. The DomU will see the device as /dev/hda, and it will have read access to the device.
Listing 5.5. An AoE Example of a Disk Parameter Line
disk = ['phy:etherd/e1.1,hda,r']
It is also possible to use an NFS mount as a root file system for your DomU. This method, however, is not
recommended due to performance and stability issues under heavy load. According to the Xen user manual, the
problems are well known in the Linux NFS implementation and are not specific to Xen.
To configure an NFS server to be used for the root file system of your guest, you need to specify the root
configuration parameter as /dev/nfs, specify the nfs_server as the IP address of the server, and nfs_root as
the path to the exported file system on the server. Listing 5.6 shows an example of using NFS for the DomU
guest image. In this example, DomU uses NFS as its root device with the server and exported path as specified
by the nfs_server and nfs_root parameters. You should be aware that nfs_root support also needs to be
compiled into the DomU kernel. This support is not typically compiled into the kernel by default.
The NFS root file system method does not require the use of the disk parameter, because the DomU guest is
using an NFS mount as its root file system. The disk parameter could still be used to add other virtual drives or
partitions as desired. An NFS root example is covered in more detail in Chapter 8.
Listing 5.6. An NFS Configuration Example