This chapter excerpt was republished from this
location.
by Andrew Hudson, Paul Hudson
© Copyright Pearson Education. All rights reserved.
In This Chapter
Xen is a powerful new virtualization system that enables you to run
multiple operating systems on one computer. If you have ever used
virtualization software such as VMware or Virtual PC, you have an idea
how
Xen works, except that it is faster, more powerful and, of course,
completely free.
This chapter contains an introduction to the world of Xen: how it
differs
from normal virtualization solutions, how you can install it on your
Fedora machine, and how to get it configured to best suit your
environment.
Why Virtualization Is a Smart Idea
The last few years have seen an incredible growth in the market for
blade servers - high-performance, low-cost, space-saving servers
that can be hooked together to form massive computing networks. These
server farms provide a terrific amount of power for a relatively small
budget, but the main problem with them is that distributing workload
makes
it much more likely to have idle servers. For example, server A is a
monolithic server: It has four CPUs, 4GB RAM, and so on, and runs both
your database and web servers. If your database server is quiet but your
web server is overrun with requests, it simply gives more resources to
the
web server. The downside here is that running multiple servers on one
computer is insecure - a hole in your web server (hardly an uncommon
thing) would also expose your database server. Now imagine that
situation
in which there are two servers: one running a database and the other
running the web server. In this scenario, the database blade server
would
simply stand idle while the web server is swamped with requests.
If you think this problem is quite rare, you ought to know that
experts
estimate that current server farm utilization is as low as 15%, which
means that 85% of your computers are likely to be sitting around waiting
for something to do. Virtualization allows you to create multiple
independent virtual machine (VM) operating systems that run on a
single server. If one VM needs more processing power, the server simply
allocates it more resources. More importantly, because the VMs are
completely isolated from each other - they are literally treated as
independent hardware - a security hole in one server cannot affect the
others.
Moving your server farm from 15% to 80% or higher utilization
either means
your users get a much faster and more reliable service, or you suddenly
have a huge amount of hardware that you can sell or keep offline until
needed. Either way, it is a huge cost savings, which makes
virtualization
the easiest way to cut down your IT budget.
Virtualization-Versus-Paravirtualization
The method in which operating systems are kept isolated is quite
simple:
They really do get a virtual machine. When you create a new VM, it is
allocated a chunk of RAM all to itself, and lives completely
self-contained from the outside world. VMware even has a virtual BIOS to
complete the illusion. If your VM wants to communicate to other VMs on
the
same computer, it has to do so over a TCP/IP network connection, just
like
any other machine. In fact, when you install an operating system on a
virtual machine, it cannot even tell that it is a virtual
machine
because it looks identical to raw hardware.
The problem with this type of virtualization is that it is very
slow. For
example, the VM has to access hardware frequently (to save files, show a
display, and so on), but of course it cannot access the hardware
directly
because doing so would interfere with other VMs. Instead, its requests
have to be translated and rerouted to the host operating system
(OS), where they are handled. Similarly, if the VM tries to
execute
any special CPU instructions that would reveal that the VM is actually a
virtual machine, the host OS has to stop those instructions and fake the
answer so that the VM is not any wiser (a technique known as binary
patching).
The solution is to move from virtualization to paravirtualization -
the
technique that Xen uses. Linux is open source, so the Xen developers
modified the Linux source code so that Linux becomes aware of its
existence as a virtual machine. When the virtual Linux needs access to
the
hardware, it just asks Xen for permission. The difference is huge: You
can
expect a normal VM to run at about 50% of the speed of a native machine,
whereas a Xen virtual machine can run up to about 95%, simply by
removing
the need for binary patching and other virtual hacks.
The downside to Xen is that the source code has to be patched,
which rules
out closed-source operating systems. VMware runs Windows XP on Linux out
of the box, but Xen cannot. That said, the new chips from Intel and AMD
include virtualization on hardware, which allows Xen to run unmodified
Windows at full speed on top of Linux. Without this technology, Xen can
only use a modified, open source distribution, such as Linux, NetBSD, or
FreeBSD.
How Xen Works
Xen is actually a very small operating system that has the sole
goal of
managing the resources of virtual machines. On top of the Xen OS runs
what
would previously have been called the host OS - the main
operating system for the machine. Unlike VMware, the host OS (known as
domain 0 or just dom0 in Xen terminology) is a virtual
machine, but has special privileges assigned to it so that it is more
responsive.
The domain 0 VM is where you control Xen, and where you start other
guest
VMs - known as unprivileged domains or domU. You
can start as many as you want, with the only really limit being the
amount
of RAM in your machine. Because the domU OS is fully aware of its status
as a Xen virtual machine, Xen lets you change the amount of RAM in a VM
while it’s running, with the exception that you can’t go above
the initial allocation of RAM.
Fedora Linux specifies a minimum system requirement of 256MB RAM,
which
means that if you are to run Fedora on top of Fedora, you need at least
512MB RAM. Keeping in mind that Xen uses a very small amount of RAM for
itself, you should ideally have at least 768MB of RAM to be able to run
two operating systems side-by-side at full speed.
Note that if you have tried Xen on old versions of Fedora, you no
longer
need to disable SELinux to get Xen to work.
Installing Xen
The first step is to convert your current OS to a virtualized guest
OS. This is actually a very easy thing to do because, as discussed,
domain
0 has special privileges - such as the capability to access hardware
directly. As a result, you do not have to reformat your machine: dom0
reads straight from the disk, uses the graphics card, uses the sound
card,
and so on.
To get started, go to Applications, Add/Remove
Software. From the window that appears, choose List view,
and then select the following packages: kernel-xen,
vnc, and xen. The kernel-xen
package provides a Linux kernel that is configured to run on top of Xen
without any special privileges as well as a Linux kernel designed to be
used as dom0, and so it can access hardware directly. The
vnc package is there to make VM management much
easier. Finally, the xen package gives us all the tools we
need to create and manage virtual machines. When Fedora resolves the
dependencies for you, go ahead and install all the packages.
Because you have installed two new kernels, Fedora updates your Grub
boot configuration to make them bootable, but leaves your original,
non-Xen kernel as the default. Switch to root and bring up
/boot/grub/grub.conf in your favorite text editor. Look for
the line "default=2" and change it to read
"default=0". This might vary on your machine - set it to the
position of the Xen hypervisor kernel in the grub.conf
file, remembering that Grub counts from 0 rather than 1. That is, the
first OS in the list is considered to be number 0. Note that you should
not set the guest kernel as the default because it will not boot
- it is designed only to be created on top of the hypervisor (dom0).
Save your changes and reboot, making sure that your new hypervisor
kernel is the one that boots. Your system should restart as normal, and
you will probably not notice anything different beyond a smattering of
"XEN" at the very beginning of the boot phase. But when you
are back in control, open a terminal and run uname -r - it
should tell you that you are running the Xen hypervisor kernel.
At this point, you are already running as a virtual machine on top
of the
Xen kernel, but there is no way for you to communicate with the Xen
kernel
and thus manipulate the virtual machines on the system. To do that you
need to start the Xen daemon, which provides the link between dom0
(where
you are working) to the Xen kernel underneath.
Run ps aux | grep xend - if you do not see
xend in there, you will need to start it yourself by
switching to root with su - and then running service
xend start. Now run the command xm list, which
prints out a list of all the virtual machines that are running and how
much RAM they have allocated - you should see Domain-0, which is your
current system, in the list.
Setting Up Guest Operating Systems
The output from xm list probably shows that domain 0
is
taking up all the RAM on your system, which means there is no room to
create a new guest OS. Fortunately, we can resize that memory usage
downward to make space: Run the command xm mem-set Domain-0
256 to have domain 0 use 256MB RAM. This is the bare minimum for
a Fedora install, so expect some slowdown - if you have more than 512MB
RAM, we recommend you allocate more to each VM.
Creating a domU VM on Fedora is handled with the
xenguest-install.py script, which you should run as
root. You are asked to do the following things:
-
Give your virtual machine a friendly name (for example,
FCUnleashed)
so that you can differentiate between it and other virtual machines.
-
Allocate it some RAM, with the minimum being 256MB; more is
better.
-
Choose where it should save its files. Xen uses a loopback
filesystem
so that all of a VM’s files are stored in just one file on domain
0. Enter something like /home/paul/vms/fcu.img.
-
Select how big the virtual disk should be. For a basic install,
around
4.0GB should be enough.
-
Set the install location (where Fedora should install from).
This
needs to be an online resource, so enter http://download.fedora.redhat.com/pub/fedora/linux/core/6/i386.
Now sit back and wait. Downloading the necessary files can take
quite a
while depending on your connection speed.
Anaconda eventually asks whether you want to install using text
mode or
VNC - choose Start VNC so that you have a graphical install. Xen’s
guests do not have direct access to the hardware, which means they have
nowhere to display graphics. VNC lets you have your Xen VM render its
graphics to your dom0 display inside a window, which means you can work
with multiple VMs simultaneously. When you select Start VNC, you are
prompted to enter a password. Click OK, and you see the VNC
address you need to connect to. This address should look something like
10.0.0.1:1, where the :1 is the number of the VNC display.
Back on dom0, you should have installed VNC Viewer at the start of
this
chapter, so go to Applications, Accessories, VNC
Viewer. Now enter that address (including the :1 or whatever it is
for you) and click Connect. Enter your password when
prompted. VNC
starts and you see the Fedora installer. Depending on the resolution of
your screen, the Fedora installer might not fit entirely on the screen;
in that case, you have to use the scrollbars to get around.
The installer is as normal from here on in, except of course that
it is
using the virtual disk we created earlier so you have only a small
amount
of space. It might refer to your hard disk as something like
/dev/xvda - do not worry about that.
Runtime Configuration
Now that your guest OS is up and running, you can start trying out
more
of the features of the xm command on dom0. You have
already
seen xm mem-set, which alters the amount of memory
allocated to a machine. This works because the domU VM is aware of its
virtualized state and can therefore handle having memory taken
away. This extends further: You can use xm shutdown yourvm
to have Xen politely request the VM to shutdown. On Linux, this goes
through the whole shutdown sequence properly, ensuring that the machine
is cleanly terminated. If you want an immediate shutdown, use xm
destroy yourvm (warning: data might be lost).
The xm command can also be used to save snapshots of a
virtual machine, rather than just switching them off. To do this, use
xm save yourvm yourvm.state. That command
essentially saves the RAM of the yourvm VM (change yourvm
to whatever you called your virtual machine) to a file, and then turns
off the VM. To restore a saved state, just use xm restore
yourvm.state. If you want to create a virtual machine from a
configuration file, use xm create -c yourconfig. Note that
Xen searches the directory /etc/xen for configuration
files, and that each VM must have a unique name assigned to it and set
in the configuration file.
You can connect to the console of any virtual machine by running
xm console yourvm. To exit from a console, press
Ctrl+] (Control + right bracket). This does not shut down the VM;
the VM continues to run, but you are no longer connected to it and have
to use xm connect to reconnect.
|
Tip
|
The configuration files in /etc/xen are in text
format and so are easily edited. For example, if you want to
change the number of CPUs a VM sees, look for the vcpus
setting. Note that these are virtual CPUs rather than
real ones - you can set this to 8 and have your guest see eight
CPUs, even if your actual machine has just one. This is a great
way to test a cluster without going beyond your desktop!
|
Related Fedora and Xen Commands - The following commands
are useful
for working with Xen on Fedora:
virt-manager - Red Hat’s new graphical Xen management
system
vncviewer - Lets you connect to the graphical output
of a Xen
VM
xend - Starts and stops the Xen daemon without using
the
service command
xenguest-install.py - A helpful script that generates
configuration files for you
xm - Lets you manipulate the state of virtual
machines while
they are running
Reference
The following are references for Xen:
http://www.xensource.com
- A company (run by some of
the Xen engineers) that offers help and support for Xen, as well as
produces XenOptimizer to ease enterprise deployment.
http://www.cl.cam.ac.uk/Research/SRG/netos/xen -
The
Xen home page at the Cambridge computer laboratory.
