View source for Building a Xen Virtual Guest Filesystem on a Physical Disk Partition (Cloning Host System)

<table border="0" cellspacing="0" width="100%">
<tr>
<td width="20%">[[Building a Xen Virtual Guest Filesystem on a Disk Image (Cloning Host System)|Previous]]<td align="center">[[Xen Virtualization Essentials|Table of Contents]]<td width="20%" align="right">[[Building a Xen Virtual Guest Filesystem using Logical Volume Management (LVM)|Next]]</td>
<tr>
<td width="20%">Building a Xen Virtual Guest Filesystem on a Disk Image (Cloning Host System)<td align="center"><td width="20%" align="right">Building a Xen Virtual Guest Filesystem using Logical Volume Management (LVM)</td>
</table>
<hr>


<htmlet>xen</htmlet>


In the previous chapter we looked at [[Building a Xen Virtual Guest Filesystem on a Disk Image (Cloning Host System)|building a Xen guest on a disk image file]]. In this chapter we will look at building the filesystem for a Xen guest (DomU) operating system on a physical disk partition through the cloning of the host operating system.

== An Overview of the Xen Host and Guest Physical Disks ==

For the purposes of this chapter the assumption is made that an entire physical disk drive is available to be dedicated to the Xen guest operating system and that it is visible to the host Linux operating system. In this scenario, therefore, there are two physical disk drives. The first, represented as ''/dev/sda'' contains the host operating system. The second, represented as ''/dev/sdb'' is a new, unpartitioned disk drive on which we will create the root filesystem and swap space for a Xen guest (domU) operating system.

== Preparing the Xen Disk Partitions ==

The first step in the configuration process is to create partitions on the ''/dev/sdb'' physical disk in preparation for creating both the root filesystem and the swap space for our Xen guest operating system. Disk partitioning is achieved using the ''fdisk'' utility. Begin by launching fdisk with the physical device name (in  this case ''/dev/sdb''):

<pre>
fdisk /dev/sdb
Device contains neither a valid DOS partition table, nor Sun, SGI or OSF disklabel
Building a new DOS disklabel. Changes will remain in memory only,
until you decide to write them. After that, of course, the previous
content won't be recoverable.

Warning: invalid flag 0x0000 of partition table 4 will be corrected by w(rite)

Command (m for help): 
</pre>

To display any existing partitions on the device enter '''p''' to print the partition table. If existing partitions exist be sure to back up any data on these partitions and then delete them using the '''d''' command. Assuming the disk is previously unpartitioned, or that existing partitions have been removed we can now create the first partition. The remainder of this section covers the creation of one 4GB partition for the root filesystem and one 1GB partition for swap. These values will differ depending on the size of your physical disk drive and the amount of space you wish to allocate to the root filesystem and swap respectively.

A new partition is created using the '''c''' command. When prompted we specify that this is a ''primary'' partition, it is partition number 1 and is to begin at cylinder 1 (i.e. the beginning of the physical disk):

<pre>
Command (m for help): n
Command action
   e   extended
   p   primary partition (1-4)
p
Partition number (1-4): 1
First cylinder (1-652, default 1): 
Using default value 1
</pre>

Next, ''fdisk'' asks us for the size of the first partition. This value may be specified in terms of the end cylinder of the partition, or the size in terms either kilobyte or megabyte units. In the following example we make the partition 4000Mb in size:

<pre>
Last cylinder or +size or +sizeM or +sizeK (1-652, default 652): +4000Mb
</pre>

If we execute the '''p''' command to print out the partition table we now see our first partition:

<pre>
Command (m for help): p

Disk /dev/sdb: 5368 MB, 5368709120 bytes
255 heads, 63 sectors/track, 652 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

   Device Boot      Start         End      Blocks   Id  System
/dev/sdb1               1         487     3911796   83  Linux
</pre>

Next we need to create a swap partition for our Xen guest operating system. Once again select '''n''', and create a primary partition, this time as partition 2. Since the remainder of the physical disk drive is to be used for this partition the default values offered for start and end cylinders will suffice:

<pre>
Command (m for help): n
Command action
   e   extended
   p   primary partition (1-4)
p
Partition number (1-4): 2
First cylinder (488-652, default 488): 
Using default value 488
Last cylinder or +size or +sizeM or +sizeK (488-652, default 652): 
Using default value 652
</pre>

Now the '''p''' command should show both partitions configured:

<pre>
Command (m for help): p

Disk /dev/sdb: 5368 MB, 5368709120 bytes
255 heads, 63 sectors/track, 652 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

   Device Boot      Start         End      Blocks   Id  System
/dev/sdb1               1         487     3911796   83  Linux
/dev/sdb2             488         652     1325362+  83  Linux
</pre>

All that remains is to write out the new partition table using the '''w''' command:

<pre>
Command (m for help): w
The partition table has been altered!

Calling ioctl() to re-read partition table.
Syncing disks.
</pre>

With the new partitions created we now need to build a filesystem on partition 1 and configure partition 2 to serve as swap space for our guest operating system.

== Creating the a Filesystem on the Xen Guest Root Partition ==

In the above section of this chapter we created two partitions on physical device ''/dev/sdb''. These partitions are ''dev/sdb1'' and ''/dev/sdb2'' respectively. The next step is to create a filesystem on the /dev/sdb1 partition to hold the root filesystem for our guest (or domU) Xen system. This is best achieved using the ''mkfs'' tool:

<pre>
# mkfs -t ext3 /dev/sdb1
mke2fs 1.39 (29-May-2006)
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
489600 inodes, 977949 blocks
48897 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=1002438656
30 block groups
32768 blocks per group, 32768 fragments per group
16320 inodes per group
Superblock backups stored on blocks: 
        32768, 98304, 163840, 229376, 294912, 819200, 884736

Writing inode tables: done                            
Creating journal (16384 blocks): done
Writing superblocks and filesystem accounting information: done

This filesystem will be automatically checked every 22 mounts or
180 days, whichever comes first.  Use tune2fs -c or -i to override.
</pre>

The above command has created a filesytem of type ''ext3'' on the first partition of our disk drive.

== Configuring the Swap Partition for the Xen Guest System ==

In addition to a root filesystem the second pre-requisite for a Xen guest (domU) system (or any other Linux system for that matter) is swap space. When we partitioned our physical disk drive previously we did so with the intention using the second partition (''dev/sdb2'') for swap space. In order to configure this partition as swap space we need to run the ''mkswap'' command passing the device name of the partition as a command-line argument:

<pre>
# mkswap /dev/sdb2
Setting up swapspace version 1, size = 1357164 kB
</pre>

== Mounting the Root Filesystem ==

Now that we have created an empty root filesystem on the ''/dev/sda1'' the next step is populate it with the system files and directories necessary to create a functioning operating system which can be booted from within the Xen environment. Before this can be achieved, however, the partition needs to be mounted. For this we need to use the ''mount'' command in conjunction with a pre-existing directory to act as a ''mount point''. The following commands create a directory named /xen and then mount the filesystem located on ''/dev/sdb1'' at this location:

<pre>
# mkdir /xen
# mount /dev/sdb1 /xen
# cd /xen
# ls
lost+found
</pre>

As we can see, the guest root filesystem contains a single item, the lost+found directory created by ''mkfs''. The next step is to clone the system files from the host operating system onto our guest root filesystem.

==  Cloning the Host OS on the Guest Root Partition ==

One of the easiest ways to install the necessary files on the guest OS root filesystem is to simply copy the files from the host operating system. Before doing so, however, it is important to keep in mind a few points. 

Firstly, the following steps will copy a considerable amount of files from the host operating system to the guest root filesystem. This may well be much more than is actually necessary. For example, you may need a minimal Linux installation for your guest OS. If the host system has graphical desktop environments, office productivity applications and other packages not needed by the guest OS then cloning the host environment may not be the best approach. If, on the other hand, you are confident that everything on your host operating system will be of use in the guest system, or are unconcerned about disk space then this approach will work well for you.

The following steps assume that the root filesystem for the Xen guest has been mounted in /xen as outlined in the previous section. 

Having created the mount point and mounted our root filesystem image the next step is to copy the relevant files from the host operating system to guest filesystem image. Execute the following command to copy the required directories and files to the root filesystem (be very careful to substitute the correct destination path if you mounted the filesystem somewhere other than ''/xen''):

<pre>
cp -ax /{bin,dev,etc,lib,root,sbin,usr,var} /xen
</pre>

The amount of time the copy process takes to complete will depend to a large extent on the speed of physical disk drive and the number of additional applications and packages installed in the root partition of the host operating system.

Once the copy process is completed a number of directories need to be created (once again the following example assumes the image has been mounted at /xen):

<pre>
mkdir /xen/{home,proc,opt,sys,tmp}
</pre>

The ''tmp'' directory created above must have read/write access for all users. To ensure this the ''chmod'' command needs to be run:

<pre>
chmod 777 /xen/tmp
</pre>

== Creating a Xen Configuration File ==

Now that we have physical disk partitions for the root filesystem and the swap space, and have populated the root filesystem with the necessary system files the next step is to create a Xen configuration file. In this file we need to specify the kernel and initial RAM Disk image files together with directives to map the disk partitions to devices within the guest OS. 

For the purposes of this example we will load the initial RAM disk and kernel images from the host operating system. These are typically located in the ''/boot'' directory. The kernel file typically begins with the name ''vmlinuz'' and the initial RAM disk begins with ''initrd''. These two images are defined in the Xen configuration file using the ''kernel = '' and ''ramdisk = '' directives. For example:

<pre>
kernel = "/boot/vmlinuz-2.6.18-53.1.14.el5xen"
ramdisk = "/boot/initrd-2.6.18-53.1.14.el5xen.img"
</pre>

Note that using the default host system initial RAM disk can cause problems on some Linux distributions. If the system fails to boot it may be necessary to generate an initial RAM disk without SCSI modules. Details of this and solutions to other Xen problems can be found at [http://www.linuxtopia.org/ProblemSolutions/index.html Linuxtopia.org]

Next, the amount of memory to be allocated to the guest system is defined using the ''memory = '' directive. The following assigns 512Mb to the guest:

<pre>
memory = 512
</pre>

The optimal amount to allocate will depend on both the available memory on the host machine and the amount of space required by the guest system. 

Each guest domain needs to have a name by which it can be referenced when using the Xen management tools. This is assigned using ''name = '':

<pre>
name = "XenGuest1"
</pre>

Now we specify network configuration options. The following lines indicate to Xen that the IP address of the system will be assigned using DHCP and the empty ''vif'' line instructs Xen to use the default values for the network interface configuration:

<pre>
vif = [ '' ]
dhcp = "dhcp"
</pre>

Finally the ''disk = '' directive is used to map the physical disk partitions we have created with guest operating system devices. The following lines map the root and swap images to ''/dev/sdb1'' and ''/dev/sdb2'' respectively and define the root filesystem as /dev/sdb1'':

<pre>
disk = ['phy:sdb1,sdb1,w', 'phy:sdb2,sdb2,w']
root = "/dev/sdb1 ro"
</pre>

Note that these device mappings will be needed when the ''fstab'' file is configured later in this chapter.

Bringing all these configuration lines together should result in the following configuration file which we will name ''XenGuest1.cfg'':

<pre>
kernel = "/boot/vmlinuz-2.6.18-53.1.14.el5xen"
ramdisk = "/boot/initrd-2.6.18-53.1.14.el5xen.img"
memory = 512
name = "XenGuest1"
vif = [ '' ]
dhcp = "dhcp"
disk = ['phy:sdb1,sdb1,w', 'phy:sdb2,sdb2,w']
root = "/dev/sdb1 ro"
</pre>

== Configuring System Files for the Guest Operating System ==

It is important to keep in mind that at this point in the process we have copied all of the system files from our host operating system onto the disk image for our guest operating system. It is vital at this point, therefore, that we change any system configuration files to meet the requirements of our guest domain. Typical settings that will need to be changed are:

* ''/etc/fstab'' - This file contains the mappings between physical and network devices and filesystems. This will need to be changed to reflect the disk configuration used by the guest system.

* ''/etc/passwd'' - Contains password information for all user and application accounts on the host system. It is important to remove the entries for any accounts which will not be required on the guest system.

* ''/etc/group'' - This file contains information about user and application groups and, as with the passwd file, should be modified to remove any groups not required in the guest system.

* ''/etc/hosts'' - Contains information about the local host and other hosts on the network. Be sure to change the name of the local host to match  the name to be used by the guest operating system.

* ''/etc/sysconfig/network'' or ''/etc/network/interfaces'' - Depending on which Linux distribution you are using, one of these files will contain networking information such as the host name and possibly a static IP address. Be sure to modify this file to remove any conflicts between the host and guest operating systems.

* ''/etc/exports'' - Contains information about any filesystems local to the host operating system which are exported for NFS access to remote systems. This should be modified to reflect any exports needed for the guest OS.

== Modifying /etc/fstab for the Guest System ==

In the preceding section we talked about the system configuration files which may need to be modified in the root filesystem of the guest operating system. One file which needs particular attention is the ''/etc/fstab'' file. The file currently present in the guest root filesystem is a direct replica of the file used by the host operating system. It is almost certain that this file will not be configured to work with the disk represented by our root filesystem and swap disk partitions. The following shows a typical file from a CentOS, Red Hat Enterprise Linux or Fedora host operating system:

<pre>
/dev/VolGroup00/LogVol00 /                       ext3    defaults        1 1
LABEL=/boot             /boot                   ext3    defaults        1 2
tmpfs                   /dev/shm                tmpfs   defaults        0 0
devpts                  /dev/pts                devpts  gid=5,mode=620  0 0
sysfs                   /sys                    sysfs   defaults        0 0
proc                    /proc                   proc    defaults        0 0
/dev/VolGroup00/LogVol01 swap                    swap    defaults        0 0
</pre>

Clearly, this doesn't match the disk configuration we have set up using disk partitions for the root filesystem and the swap device. The guest OS copy of the fstab file needs to be modified to reflect the device mappings in the Xen configuration file created above (recall that the root filesystem was mapped to /dev/sdb1 and swap to /dev/sdb2). For example:

<pre>
/dev/sdb1               /                       ext3    defaults 1 1
/dev/sdb2               none                    swap    sw       0 0
none                    /dev/pts                devpts  gid=5,mode=620 0 0
none                    /dev/shm                tmpfs   defaults 0 0
none                    /proc                   proc    defaults 0 0
none                    /sys                    sysfs   defaults 0 0
</pre>

== Booting the Guest OS ==

Now all that remains is to boot the guest operating system. Before issuing the command to do so it is important to note that the system may not boot for a number of reasons. 

If the system fails to boot be sure to read the Xen Guest Boot Problems section at the end of this chapter.

Before booting the guest system it is important to first unmount the guest root filesystem:

<pre>
umount /xen
</pre>

With the set up and configuration complete we are now ready to start up the guest OS. This is achieved using the ''xm create'' command:

<pre>
xm create XenGuest1.cfg -c
</pre>

The '''-c''' flag above instructs Xen to attach a console to the guest system so that we see output as the system boots. The following output displays the initial phases of a successful boot:

<pre>
Using config file "./XenGuest1.cfg".
Started domain centos.5-1
Linux version 2.6.18-53.1.14.el5xen (mockbuild@builder6.centos.org) (gcc version 4.1.2 20070626 (Red Hat 4.1.2-14)) #1 SMP Wed Mar 5 12:39:19 EST 2008
BIOS-provided physical RAM map:
 Xen: 0000000000000000 - 0000000020800000 (usable)
0MB HIGHMEM available.
520MB LOWMEM available.
NX (Execute Disable) protection: active
ACPI in unprivileged domain disabled
Built 1 zonelists.  Total pages: 133120
Kernel command line:  ip=:1.2.3.4::::eth0:dhcp root=/dev/sdb1 ro
Enabling fast FPU save and restore... done.
Enabling unmasked SIMD FPU exception support... done.
Initializing CPU#0
CPU 0 irqstacks, hard=c0727000 soft=c0707000
PID hash table entries: 4096 (order: 12, 16384 bytes)
Xen reported: 2992.640 MHz processor.
Console: colour dummy device 80x25
Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
Software IO TLB disabled
</pre>

== Xen Guest Boot Problems ==

A number of different problems can occur during the boot process of the Xen guest system. Solutions to common Xen problems are as follows:

* [[Ubuntu Xen Guest (DomU) Hangs after EXT3-fs: mounted filesystem with ordered data mode message]]
* [[Ubuntu Xen System Boot Hangs After Setting System Clock Message]]
* [[Xen domainU fails to boot with a "Xen Guest OS Fails to Boot with Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)" error message]]
* [[A Xen Guest OS fails to boot with a "switchroot: mount failed: No such file or directory error message" error message.]]
* [[Xen CentOS/Fedora/Red Hat Guest OS Hangs During Boot]]
* [[Xen domainU Boot Fails with Invalid kernel / ERROR: Not a Xen-ELF image Message]]


<htmlet>xen</htmlet>


<hr>
<table border="0" cellspacing="0" width="100%">
<tr>
<td width="20%">[[Building a Xen Virtual Guest Filesystem on a Disk Image (Cloning Host System)|Previous]]<td align="center">[[Xen Virtualization Essentials|Table of Contents]]<td width="20%" align="right">[[Building a Xen Virtual Guest Filesystem using Logical Volume Management (LVM)|Next]]</td>
<tr>
<td width="20%">Building a Xen Virtual Guest Filesystem on a Disk Image (Cloning Host System)<td align="center"><td width="20%" align="right">Building a Xen Virtual Guest Filesystem using Logical Volume Management (LVM)</td>
</table>