Changes

m
Text replacement - "<htmlet>xen<htmlet>" to "<htmlet>xen</htmlet>"
Logical Volume Management (LVM) provides a flexible and high level approach to managing disk space. Instead of each disk drive being split into partitions of fixed sizes onto which fixed size are in turn file systems are created, LVM provides a way to group together disk space into logical volumes which can be easily resized and moved. In addition LVM allows administrators to carefully control disk space assigned to different groups of users by allocating distinct volume groups or logical volumes to those users. When the space initially allocated to the volume is exhausted the administrator can simply add more space without having to move the user files to a different file system.<htmlet>xen</htmlet>
 Logical Volume Management (LVM) provides a flexible and high level approach to managing disk space. Instead of each disk drive being split into partitions of fixed sizes onto which fixed size file systems are in turn created, LVM provides a way to group together disk space into logical volumes which can be easily resized and moved. In addition, LVM allows administrators to carefully control disk space assigned to different groups of users by allocating distinct volume groups or logical volumes to those users. When the space initially allocated to the volume is exhausted the administrator can simply add more space without having to move the user files to a different file system. When a Xen guest domain (domU) system is installed in a logical volume , that volume can be increased in size at any time simply by allocating additional disk space to the volume and extending the guest domain's filesystem to utilize the space.
== The Key Components of Logical Volume Management ==
== Preparing for an LVM based Xen Guest Domain ==
In this chapter we will be working with a scenario in which we have a system containing four physical disk drives. The first disk drive, referenced as /dev/sda contains the host operating system. The second and third disks (''/dev/sdc'' and ''/dev/sdd'') will be converted into physical volumes and used to create a logical volume to hold the root filesystem for our Xen guest operating system. We will then use a partition on the fourth disk drive (''/dev/sdb2'') for the guest's swap space. It is important to note that LVM is highly flexible and this is just one of a potentially infinite number of different possible scenarios. For more details about Logical Volume Management read the [http://www.linuxtopia.org/online_books/linux_lvm_guide/index.html Logical Volume Management Reference Guide].
== Converting Physical Disks into Physical Volumes ==
</pre>
Now that we have two physical volumes the next step is to create a volume group to contain them.
== Creating a Volume Group ==
== Creating a Logical Volume for the Xen Guest System ==
Logical volumes are created using the ''lvcreate'' command which takes a number of command line arguments. Firstly, the '''-L''' flag is used to specify the size of the volume. Secondly, the '''-n''' flag is used to specify a name for the logical volume. Finally the name of the Volume Group to which the logical volume is to belong (and from which the space is to be acquired) is specified. Therefore, the following command will create a 3.99Gb logical volume called XenLogVol as part of the XenVolG volume group:
<pre>
</pre>
information Information about the logical volume may be accessed using the ''lvdisplay'' command:
<pre>
</pre>
As we can see from the above output we know now have a 3.00Gb 00GB logical volume which is accessing accessed via the ''/dev/XenVolG/XenLogVol'' device.
== Creating a Filesystem on the Logical Volume ==
== Configuring the Swap Partition for the Xen Guest System ==
In addition to a root filesystem the second prerequisite for a Xen guest (domU) system is swap space. When we partitioned our physical disk drive previously we did so with the intention using using the second partition (''dev/sdb2'') for swap space. As outlined previously, the objective is to use a partition on a different disk drive for swap space. in In this scenario , the device file for the partition is /dev/sdb2. The mkswap command is used to configure this partition as swap space:
<pre>
== Mounting the Root Filesystem ==
Now that we have created an empty root filesystem on the XenLogVol logical volume, the next step is populate it with the system files and directories necessary to create a functioning guest operating system. 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 mounts mount the filesystem located on ''/dev/XenVolG/XenLogVol'' at this location:
<pre>
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>
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 assigned assigns 512Mb to the guest:
<pre>
</pre>
Finally the ''disk = '' directive is used to map the ''XenLogVol'' logical volume we have created with a guest operating system device. The following lines map the root logical volume (reported by ''lvdisplay'' as being located at /dev/XenVolG/XenLogVol) and swap partition to ''/dev/sdb1'' and ''/dev/sdb2'' respectively and define the root filesystem as /dev/sda1''):
<pre>
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 configuiration 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 passd 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.
== 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>
</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 The following output displays the initial phases of a successful boot:
<pre>
* [[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>