Because the "host" OS is also running CentOS, installing a child CentOS session is fairly simple. The yum program has an option which makes it do its work totally within a given directory- similar to how the chroot command works, but without actually using chroot. The CentOS yum repository also has a pre-defined meta-package which includes 95% of what needs to be installed on a new system.
We need to use yum to create the files to be stored on the new system, but we need to do it in such a way that the existing system's packages don't affect what gets installed on the new client, and the packages on the new client don't affect what's on the host system.
Yum normally works by reading the /etc/yum.conf file and combining it with any files it finds in the /etc/yum.repos.d directory. When I first tried this, I discovered that no matter what I did, the "other" repositories (extras, contrib, etc.) were being consulted as well, even though they weren't listed in the custom yum.conf file I was using. Eventually I added a line to the yum.conf file which prevented it from looking in the /etc/yum.repos.d directory.
After a bit of trial and error, I finally found a yum.conf which works correctly. Download a copy of the file and save it in root's home directory.
You will notice the path /mnt at the beginning of two of the lines. This is because when we install the client (below) the client's root filesystem will be mounted as /mnt on the host system.
The first step is to mount the new partition and create a few "basic basics" which have to be there in order for pretty much any Linux system to exist.
Once this is done, we can use yum to install a minimal CentOS system on the partition, along with a few individual packages which are needed but are not included in the "Core" meta-package.
Go get some coffee, this will take a while.
This one will take a little while to run as well, but not nearly as long as the first one did.
At this point we are about 90% done. All that remains is a bit of manual tweaking.
SELinux tends to complicate things. Disable it.
Configure the network - the client will need an IP address.
Make sure DNS resolution will work.
Make sure /etc/hosts resolution works as well.
Set up the /etc/inittab file.
The "kudzu" service is a waste of time for a virtual system.
Make sure the virtual system doesn't use the TLS libraries.
And finally, we can un-mount the disk from the host system.
One thing which changed from Xen 2.0.7 to Xen 3 is that the non-privileged "xenU" sessions now use the same kernels as the privileged "xen0" sessions. The RPM installation only installed the one kernel, so we're going to use it for the xenU sessions as well as the xen0 session.
In order to start a xenU session, we need to create a text file which defines the parameters of that session- what kernel it will run, how much memory it will have, the network interface(s), the virtual disks, and so forth.
Once you're attached to a session (whether by using "xm console" or by using the "-c" option of "xm create") you can "detach" from that virtual console by pressing CONTROL and ] (the right square bracket key) at the same time. This will not stop the session from running, it simply returns the keyboard and screen to the host machine.