Chapter 2: Getting Started

From PrgmrWiki

Fascinating though the theoretical underpinnings and implementation details of Xen are, we should probably move on to working directly with Xen for a bit of practice. There is, after all, no substitute for experience.

So! Welcome to Xen. This chapter is an easy quick start aimed at gently introducing Xen to one of your machines. We will hold your hand and not let it go.

Because this is a detailed walk-through, we’re going to give focused, specific instructions, deviating from our normal policy of being vague and distro-agnostic. For the purposes of this chapter, we’ll assume you’re installing CentOS 5.x with the server defaults and using its built-in Xen support.

If you’re using something else, this chapter will probably still be useful, but you might have to improvise a bit—the goals will be the same but the steps will probably be different.


In general, the goals for this walk-through are as follows: Make sure your hardware can run Xen.

  • Install a basic OS.
  • Install Xen.
  • Familiarize yourself with the Xen environment.
  • Install a domU.
  • Log in to your domU and configure it to make sure everything works.
  • Rest.

Hardware Compatibility

First, make sure that your hardware’s up to the task of running Xen. (It almost certainly is.)

All you need is a Pentium Pro or better, 512MiB of memory,1 and a few hundred MiB of hard drive space. If you can’t manage that, dig some change out of your couch cushions and buy a machine. The PPro came out in, what, 1996? Haven’t you heard? This Is The Future.

At present, Xen runs only on x86 (that is, Intel and AMD) processors and IBM’s PowerPC. X86_64—the 64-bit extension to the x86 instruction set—is supported on both AMD and Intel processors. Xen also supports Intel’s Itanium. For the sake of this walk-through, we’ll assume that you’re using an x86 or x86_64 machine.

Our test box, for example—chosen to be as common as possible—was a three-year-old Dell, with a Pentium 4, 1GB of RAM, and a quantity of hard drive space beyond my wildest imaginings. Personally, I think it’s all so fast it makes me sick.

Anyway, so you’ve got a machine capable of running Xen. Congratulations. First, it needs a basic operating system that Xen can run on top of.

NOTE: Run on top of is probably not the best way of characterizing Xen’s interaction with the dom0 OS, in view of the fact that the dom0 kernel runs on the hypervisor, but it is a convenient and frequently used phrase. We beg your patience, Constant Reader.

Installing CentOS

First, we’ll install CentOS in a completely ordinary way. Put the install medium in the drive, boot from it, and install it according to your preference. We opted to accept the default partitioning, which creates a small /boot partition and devotes the rest of the drive to an LVM group, with a logical volume for swap and a volume for root. We also accepted the default configuration for the GRUB boot loader and the default network config.

NOTE: Now would also be a good time to make sure you have some sort of Internet access.

Set your time zone and enter a root password. We’re just running through the standard CentOS install process at this point—it’s probably familiar territory. Follow the prompts as usual.

Next comes package selection. We chose the virtualization server package group, since that’s the one that includes the Xen hypervisor and supporting tools, and left the rest blank. If you’d like to, you can also choose other package groups to install, like the GNOME desktop or server-gui set of packages, without modifying any of the steps in this section.

Select Next. Now the machine will install the packages you’ve selected. This may take a while, varying with package selection and install medium. It took us about 15 minutes to install from a DVD. When that’s done, the machine will reboot and give you the chance to do postinstall configuration— firewall, services, SELinux, and so on.

At this point you may wish to do other system configuration related stuff, not directly related to Xen. Feel free.

Now, we’re ready to create a virtual machine. But first let’s look at Xen’s boot messages and get familiar with the Xen environment.


So, you downloaded the LiveCD? May as well try it. It’s pretty slick, but when

it’s booted, it’s just another operating system. This captures what makes Xen so fascinating—its sheer banality. After all this work, you wind up sitting in front of a Linux box. Yes, it will pretend to be multiple Linux boxes on demand, but there’s not really much “there” there, to borrow a well-turned phrase from Gertrude Stein.

The LiveCD does showcase some useful features, though. For example, it uses a copy-on-write filesystem to give each Xen domain persistent writable storage across VM reboots. The LiveCD also has some neat scripts that use the XenBus to pop up a VNC console automatically on domU startup. (See Chapter 14 for more information on that.)

It’s a nice demo, but it’s not really useful for production, and it doesn’t give you the sort of hands-on experience that comes with setting up a machine. The other problem is that the LiveCD hasn’t been updated in a while. The last version (as of this writing) is two years old and is based on Xen 3.0.3. There have since been some

changes to Xen.

Booting with Xen features extra Xen-specific boot output, as shown in Figure 2-1. Figure2-1.jpg

Figure 2-1: Success! The Xen kernel wants to have a conversation with us.

After GRUB loads, it loads the Xen hypervisor, which then takes control of the hardware and outputs its initialization lines (starting with (XEN)). Then it loads the dom0 kernel, which takes over and spews the familiar Linux boot messages that we know and tolerate. (Note that you may not see these messages if you’re using the VGA console, since they go by rather quickly. You can type xm dmesg to see them at any time.)

After the system boots, you should be looking at the normal login prompt, with nary a sign that you’re running in a Xen virtual machine. (Albeit a specially privileged virtual machine.) Now would be a great time to log in, if you haven’t already.

Getting Familiar with Your Xen System

Before we start creating virtual machines, let’s take a brief look at the Xen configuration files in the dom0. We’ll be referring to these a lot in future chapters, so now might be a good time to take a quick tour.

First, there’s the Xen configuration directory, /etc/xen. Most, though not all, of the Xen configuration happens via files here or in the scripts subdirectory.

The main Xen config file is xend-config.sxp. This where you’d perform tasks like enabling migration or specifying the network backend. For now, we’ll be content with the defaults.

NOTE: If you’re planning on using this Xen installation for anything besides this walkthrough,

now is a good time to set the (dom-min-mem) option in xend-config.sxp to

something sensible. We use (dom-min-mem 1024). See Chapter 14 for more details.

The /etc/xen/scripts directory contains scripts to handle tasks like setting up virtual devices.

Finally, domain configuration files live in /etc/xen. For example, you can take a look at xmexample1 to see a liberally commented sample config.

The /etc/init.d directory contains scripts to start and stop Xen-related services. The Xen control daemon, xend, runs as a standard service from the /etc/init.d/xend script. Although you probably won’t need to modify it, this can be a handy place to change xend’s parameters. It’s also the easiest way to restart xend, by running /etc/init.d/xend restart. The xendomains script may also be of interest—it automatically saves domains when the system shuts down and restores them when it boots up.

There’s also /boot/grub/menu.lst. This file tells the bootloader, GRUB, to boot the Xen kernel, relegating the dom0 Linux kernel to a “module” line. Here you’d change the boot parameters for both Xen and Linux. For example, you might want to specify a fixed memory allocation for dom0 using the dom0_mem hypervisor option, or increase the number of network loopback devices via the Linux nloopbacks option.

domU data itself, if you’re using file-backed virtual disks under CentOS and following the default prompts for virt-install, resides in /var/lib/xen/ images. Other distros and frontends are likely to have different defaults.

Management with xm

The main command that you’ll use to interact with Xen is xm. This tool has a wide variety of subcommands. First, since we’re still looking around the environment, try xm list:

# xm list
Name                                       ID Mem(MiB) VCPUs State   Time(s)
Domain-0                                    0      934   2   r-----  37.6

The output of xm list shows the running domains and their attributes. Here we see that only one domain is running, Domain-0 (abbreviated dom0 throughout the book) with ID 0, 934MiB of memory, and two VCPUS. It’s in the “running” state and has used 37.6 seconds of CPU time since boot.

NOTE: Red Hat doesn’t officially support xm, although they unofficially expect it to continue

working through RHEL 5.x. For this reason, xm’s documentation may advertise capabilities that don’t work on RHEL or CentOS. The supported management tool on RHEL

and friends is virsh, for virtualization shell.

You might also try xm info for more information on the hypervisor. We’ll introduce more xm subcommands in later chapters, and there’s a complete list in Appendix A.

Making a DomU

For the moment, since we want to create a domU, the xm subcommand we’re most interested in is create. However, before we can create a domain, we need to create an OS image for it to boot from and use as storage.

Because this is an initial walk-through, we’re going to install our Xen image using Red Hat’s virt-install tool. For information on building your own domU images, take a look at Chapter 3.

Begin by starting virt-install. It’ll start in interactive mode, and have a bit of a conversation with you, as shown. Our inputs are shown in bold. (If you decided to install the GUI, you can also use the graphical virt-manager tool. The prompts will look very similar.)

# virt-install

What is the name of your virtual machine? prospero
How much RAM should be allocated (in megabytes)? 256
What would you like to use as the disk (file path)? /var/lib/xen/images/prospero.img
How large would you like the disk (/var/lib/xen/images/prospero.img) to be (in gigabytes)? 4
Would you like to enable graphics support? (yes or no) no
What is the install location?

The machine then begins an interactive network install of CentOS. We won’t go into the details of its operation for now—suffice it to say that great pains have been taken to preserve the appearance of installing an OS on a physical machine. As such, the install process should eerily resemble the one we performed at the start of this chapter. Follow its prompts. (For the curious, we discuss virt-install and its accompanying tools more thoroughly in Chapters 3 and 6.)

Once you’ve made your selections and gone through the install, the machine will reboot. Log in, and then shut the machine down via shutdown -h now (remember, it’s an ordinary Linux box) so that we can look a bit more at things from the dom0 end.

Anatomy of a Domain Configuration File

Let’s take a moment to examine the config file that virt-install generated for us. As we’ve mentioned already, the config file is /etc/xen/<domain name> by convention.

# cat /etc/xen/prospero
name = "prospero"
uuid = "9f5b38cd-143d-77ce-6dd9-28541d89c02f"
maxmem = 256
memory = 256
vcpus = 1
bootloader = "/usr/bin/pygrub"
on_poweroff = "destroy"
on_reboot = "restart"
on_crash = "restart"
vfb = [ ]
disk = [ "tap:aio:/opt/xen/images/prospero.img,xvda,w" ]
vif = [ "mac=00:16:3e:63:b7:a0,bridge=xenbr0" ]

As you see, the file consists of simple name=value pairs, with Python-style lists in square brackets. Note the values that we specified in the virt-install session, plugged into appropriate places—the name, the memory amount, and the disk image. virt-install also fills in some network configuration, specifying a MAC address and dom0-level bridge device.

We’ll examine many of the config file parameters more deeply in subsequent chapters. For now, let’s just move on to seeing the effects of these values on our domain.

Configuring the DomU

Finally, start the image! We’ll run xm with the create subcommand, which expects a config file name as an argument. We can omit the path, since it defaults to looking in /etc/xen.

# xm create -c prospero

Since we passed the -c option to xm create, it’ll immediately connect us to the domain’s console, so that we can interact with the bootloader. Hit ENTER to boot with default options, and watch it go.

Once it boots, you should be looking at the console of a shiny new Xen domU, as illustrated in Figure 2-2. Log in as root and frolic.

Start by looking at the output of the dmesg command within the domU. Note that the disk and network devices are Xen’s special paravirtualized devices.

Figure2-2.jpg Figure 2-2: We assure you that this is the domU console.

You can also take a look at the domU’s networking, which is essentially indistinguishable from that of a normal Linux system:

# ifconfig eth0
eth0       Link encap:Ethernet HWaddr 00:16:3E:63:B7:A0
           inet addr: Bcast: Mask:
           inet6 addr: 2001:470:1:41:a800:ff:fe53:314a/64 Scope:Global
           inet6 addr: fe80::a800:ff:fe53:314a/64 Scope:Link

           RX packets:73650errors:0 dropped:0 overruns:0 frame:0
           TX packets:49731 errors:0 dropped:0 overruns:0 carrier:0
           collisions:0 txqueuelen:1000
           TX bytes:106033983 (101.1 MiB)       RX bytes:2847950 (2.7 MiB)

Note that we’re using standard commands—one of the major features of Xen is that most of the management takes place via familiar Linux commands. This makes it easy to customize your Xen environment, usually by making changes to the support scripts. Furthermore, standard commands will generally behave in expected ways—for example, you can give yourself a new IP address via ifconfig, and it’ll work just as it would on a physical machine.2

Let’s return to the dom0 for a moment, just to take a look at the running domain from outside. To break out of the domU’s console, type CTRL-]. You can reconnect at any time by running xm console <domU name or id> from the dom0.

Now that we’re back in the dom0, we can note that our new domain shows up in xm list, consuming memory and CPU time:

# xm list
Name                                         ID Mem(MiB) VCPUs State   Time(s)
Domain-0                                      0    739     2   r-----   136.7
prospero                                      1    255     1   -b----   116.1

And that it’s got a visible network device:

# ifconfig vif1.0
vif1.0     Link encap:Ethernet HWaddr FE:FF:FF:FF:FF:FF
           inet6 addr: fe80::fcff:ffff:feff:ffff/64 Scope:Link
           UP BROADCAST RUNNING NOARP MTU:1500 Metric:1
           RX packets:49731 errors:0 dropped:0 overruns:0 frame:0
           TX packets:73650 errors:0 dropped:0 overruns:0 carrier:0
           collisions:0 txqueuelen:32
           RX bytes:2847950 (2.7 MiB) TX bytes:106033983 (101.1 MiB)

Some points to mention about the network device: First, it’s got a dummy MAC address. You can see the actual MAC address of the virtual Ethernet device from within the domU. Second, the counters are reversed— the domain’s actually downloaded 100MiB, and transmitted 2.7. Third, both IPv4 and IPv6 “just work” with the default setup. We go into further detail in Chapter 5. From here you can treat the domain just like any other Linux box. You can set up users on it, SSH into it, or access its console via <t>xm console. You can reboot it via the xm reboot command, and shut it down using xm shutdown.

You’re Finished. Have a Cookie.

Now that you’ve got a domain, read the next chapter.

If it didn’t work . . . what a fabulous opportunity to examine Chapter 15. We are sorry. Please email us and mention that our directions need work.


1 The absolute minimum would probably be 128MiB, but CentOS itself requires 256, and each domU will also require a significant amount of memory.
2 The administrator can disable this, however. You’ll still be able to change the IP from the domU, but the dom0 will block traffic from the new IP. See Chapter 5 for details.


previous chapter | next chapter