Xen is short for "the Xen Virtual Machine Monitor", which is a technology for running multiple
operating system environments on a single physical
computer. It is not a proper
virtual machine, nor is it a simple
chroot environment with shared executables - it lies between those two, although much closer to the virtual machine approach. The term the developers have chosen to use for this is
paravirtualization.
First things first: information straight from the horse's mouth can be found on the project web page at:
http://www.cl.cam.ac.uk/Research/SRG/netos/xen/
A quick description of the technology follows from the point of view of someone hacking around with it. Note: If you're not into computing, you may not care about this or understand it. First, some vocabulary: rather than virtual machines, instances on a Xen environment are called domains. They are numbered, starting at domain 0 and rising, in the order in which they are 'created' or instantiated on the machine. Note that this refers to the Xen 'paravirtual' machine itself, not the OS running inside it, which is referred to as the 'guest OS.'
Xen itself is not a full OS; rather, it's more of a stub. The physical machine being used as the Xen environment boots the Xen monitor. That, in turn, immediately boots the 'host OS' into domain 0. It's the 'host OS' by virtue of it running in domain 0. This host OS cannot be purely stock; it must be modified in order to recognize that it is running under Xen (this is why Xen is not a 'full' virtual machine). Domain 0 will always have privileged access to the hardware and the Xen machine monitor, allowing it supervisor control over the higher-numbered domains as well as privileged access to the machine's hardware.
Note that the 'host OS' can be a variety of OSes. There are versions of the linux kernel which have been modified to include Xen extensions, and entire linux distributions which ship with such kernels. As such, XenLinux (as such distros are known) can boot into domain 0 and provide the user with essentially a full linux system. SuSE 9.3, when booted with the (included) Xen kernel, contains all normal functionality - it just happens to be running in domain 0 of a Xen environment, allowing it to spawn additional domains if the user so chooses. Various BSDs have been modified to work with Xen as well.
Once domain 0 is up, additional domains can be spawned using userspace utilities available for the host OS. Those domains, although they cannot typically be netbooted as if they were hardware (i.e. no PXE booting), can take network installs, or be booted from disk files or disk partitions or even CD-ROMs. They can run different OSes from the host OS so long as their guest OS has been Xen modified. These domains can be controlled from domain 0. They will access the network via a software bridge in domain 0; they can be given their own MAC addresses and hence their own IP addresses, and be treated (from outside the physical computer) as entirely separate machines.
Xen provides the ability to migrate running domains from one physical node to another, so long as both the source and dsetination node have access to the filesystem that the domain is using (a network drive, or if it's fully in RAM). This can be accomplished purely over an IP network, and does not require an out-of-band connection - using ARP switching, the new physical node will assume the MAC address of the old one once the domain has transferred, and in ideal situations the switch will happen rapidly enough that network connections to the domain from outside need not even drop.
Needless to say, this has profound implications for failover, load balancing, disaster recovery, deployment, and all around cool factor. The excellent consumer hosting provider linode, which currently uses user-mode linux to provide static IP virtual machines to the public, is switching to Xen-based implementation in the near future.