Chapter 12. Guest Installation

Chapter 12. Guest Installation¶

Contents

12.1. Basic Installation with qemu-kvm
12.2. Managing Disk Images with qemu-img

A virtual machine is comprised of data and operating system files that define the virtual environment. Virtual machines are hosted and controlled by the VM Host Server. This chapter provides generalized instructions for installing virtual machines.

Before creating a virtual machine, consider the following:

If you want to use an automated installation file (AutoYaST, NetWare® Response File, or RedHat Kickstart), you should create and download it to a directory on the host machine server or make it available on the network.
When creating sparse image files, make sure the partition on which you create them always has sufficient free space. The guest system has no means to check the host's disk space. Having no space left on the host partition causes write errors and loss of data on the guest system.
NetWare and OES Linux virtual machines need a static IP address for each virtual machine you create.
If you are installing Open Enterprise Server (OES) 2 Linux, you need a network installation source for OES 2 Linux software.

For further prerequisites, consult the manuals of the respective operating system to install.

12.1. Basic Installation with qemu-kvm¶

The libvirt-based tools such as virt-manager or vm-install offer convenient interfaces to set up and manage virtual machines. They act as a kind of wrapper for qemu-kvm. However, it is also possible to utilize qemu-kvm directly without using libvirt-based tools at all.


Virtual machines created with qemu-kvm are not "visible" for the `libvirt`-based tools.

In the following example, a virtual machine with the same parameters as in Example 5.1, “Interactive Setup on the Command Line Using vm-install” will be set up using qemu-kvm. For detailed information on the commands, refer to the respective man pages.

If you do not already have an image of a system which you want to run in a virtualized environment, you need to create one from the installation media. In such case, you need to prepare a hard disk image, and obtain an image of the installation media or the media itself.

Create a hard disk with qemu-img.

qemu-img create -f raw /images/sles11/hda 8G

	The subcommand `create` tells qemu-img to create a new image.
	Specify the disk's format with the `-f` parameter. Currently, only the `raw` disk format is supported by Novell.
	The full path to the image file.
	The size of the image—8 GB in this case. The image is created as a sparse file that grows when the disk is filled with data. The specified size defines the maximum size to which the image file can grow.

After at least one hard disk image is created, you can set up a virtual machine with qemu-kvm that will boot into the installation system:

qemu-kvm -name "sles11" -M pc-0.12 -m 768 \
-smp 2 -boot d \
-drive file=/images/sles11/hda,if=virtio,index=0,media=disk,format=raw \
-drive file=/isos/SLES-11-SP1-DVD-x86_64-GM-DVD1.iso,index=1,media=cdrom \
-net nic,model=virtio,macaddr=52:54:00:05:11:11 \
-vga cirrus -balloon virtio

	Name of the virtual machine that will be displayed in the window caption and also used for the VNC server. This name must be unique.
	Specifies the machine type (Standard PC, ISA-only PC, or Intel-Mac). Use qemu-kvm `-M ?` to display a list of valid parameters. `pc-0.12` is the default Standard PC.
	Maximum amount of memory for the virtual machine.
	Defines an SMP system with two processors.
	Specifies the boot order. Valid values are `a`, `b` (floppy 1 and 2), `c` (first harddisk), d (first CDROM), or `n` to `p` (Ether-boot from network adapter 1-3). Defaults to `c`.
	Defines the first (`index=0`) hard disk. It will be accessed as a paravirtualized (`if=virtio`) drive in `raw` format.
	The second (`index=1`) image drive will act as a CD-ROM.
	Defines a paravirtualized (`model=virtio`) network adapter with the MAC address `52:54:00:05:11:11`. Be sure to specify a unique MAC address, otherwise a network conflict may occur.
	Specifies the graphic card. If you specify `none`, the graphic card will be disabled and it is then possible to connect and view the graphical output through VNC.
	Defines the paravirtualized balloon device that allows to dynamically change the amount of memory (up to the maximum value specified with the parameter `-m`).

After the installation of the guest operating system finishes, you can easily start the related virtual machine without the need to specify the CD-ROM device:

qemu-kvm -name "sles11" -M pc-0.12 -m 768 \
-smp 2 -boot c \
-drive file=/images/sles11/hda,if=virtio,index=0,media=disk,format=raw \
-net nic,model=virtio,macaddr=52:54:00:05:11:11 \
-vga cirrus -balloon virtio

12.2. Managing Disk Images with qemu-img¶

In the previous section (see Section 12.1, “Basic Installation with qemu-kvm”, we used the qemu-img command to create an image of a hard disk. You can, however, use qemu-img for a general disk image manipulation. This section introduces useful qemu-img subcommands to help manage the disk images flexibly.

12.2.1. General Information on qemu-img Invocation¶

qemu-img uses subcommands (like zypper does) to do specific tasks. Each subcommand understands a different set of options. Some of these options are general and used by more of these subcommands, while some of them are unique to the related subcommand. See the qemu-img manual page (man 1 qemu-img) for a complete list of all supported options. qemu-img uses the following general syntax:

qemu-img subcommand [options]

and supports the following subcommands:

create: Creates a new disk image on the filesystem.
check: Checks an existing disk image for errors.
convert: Converts an existing disk image to a new one in a different format.
info: Displays information about the relevant disk image.
snapshot: Manages snapshots of an existing disk images.
commit: Applies changes made to an existing disk image.
rebase: Creates a new base image based on an existing image.

12.2.2. Creating, Converting and Checking Disk Images¶

This section describes how to create disk images, check their condition, convert a disk image from one format to another, and get detailed information about a particular disk image.

12.2.2.1. qemu-img create¶

Use qemu-img create to create a new disk image for your VM Guest operating system. The command uses the following syntax:

qemu-img create -f fmt -o options fname size

	The format of the target image. To get a complete list of image formats supported by QEMU, run qemu-img `-h` and look at the last line of the output. Currently, Novell only supports the `raw` image format. It is a plain binary image with no advanced features, and, therefore, very portable from and to other emulators. Moreover, if your filesystem supports sparse files (most UNIX modern filesystems or NTFS do), the image occupies only the space actually used by its data.
	Some of the image formats support additional options to be passed on the command line. You can specify them here with the `-o` option. The `raw` image format supports only the `size` option, so it is possible to insert `-o size=8G` instead of adding the size option at the end of the command.
	Path to the target disk image to be created.
	Size of the target disk image (if not already specified with the `-o size=<image_size>` option. Optional suffixes for the image size are `K` (kilobyte), `M` (megabyte), `G` (gigabyte), or `T` (terabyte).

To create a new disk image sles11sp1.raw in the directory /images growing up to a maximum size of 4 GB, run the following command:

tux@venus:~> qemu-img create -f raw -o size=4G /images/sles11sp1.raw
Formatting '/images/sles11sp1.raw', fmt=raw size=4294967296

tux@venus:~> ls -l /images/sles11sp1.raw
-rw-r--r-- 1 tux users 4294967296 Nov 15 15:56 /images/sles11sp1.raw

tux@venus:~> qemu-img info /images/sles11sp1.raw
image: /images/sles11sp1.raw
file format: raw
virtual size: 4.0G (4294967296 bytes)
disk size: 0

As you can see, the virtual size of the newly created image is 4 GB, but the actual reported disk size is 0 as no data has been written to the image yet.

12.2.2.2. qemu-img convert¶

Use qemu-img convert to convert disk images to another format. To get a complete list of image formats supported by QEMU, run qemu-img -h and look at the last line of the output. Currently, Novell only supports the raw image format. The command uses the following syntax:

qemu-img convert -c -f fmt -O out_fmt -o options fname out_fname

	Applies compression on the target disk image. Only `qcow` and `qcow2` formats support compression.
	The format of the source disk image. It is autodetected in most cases and can therefore be omitted.
	The format of the target disk image.
	Specify additional options relevant for the target image format. Use `-o ?` to view the list of options supported by the target image format:
	Path to the source disk image to be converted.
	Path to the converted target disk image.

tux@venus:~> qemu-img convert -O vmdk /images/sles11sp1.raw \
/images/sles11sp1.vmdk

tux@venus:~> ls -l /images/
-rw-r--r-- 1 tux users 4294967296 16. lis 10.50 sles11sp1.raw
-rw-r--r-- 1 tux users 2574450688 16. lis 14.18 sles11sp1.vmdk

To see a list of options relevant for the selected target image format, run the following command (replace with your image fomrmat):

tux@venus:~> qemu-img convert -O vmdk /images/sles11sp1.raw \
/images/sles11sp1.vmdk -o ?
Supported options:
size             Virtual disk size
backing_file     File name of a base image
compat6          VMDK version 6 image

12.2.2.3. qemu-img check¶

Use qemu-img check to check the existing disk image for errors. Not all disk image formats support this feature. The command uses the following syntax:

qemu-img check -f fmt fname

	The format of the source disk image. It is autodetected in most cases and can therefore be omitted.
	Path to the source disk image to be converted.

If no error is found, the command returns no output. Otherwise, the type and number of errors found is shown.

tux@venus:~> qemu-img check -f qcow2 /images/sles11sp1.qcow2
ERROR: invalid cluster offset=0x2af0000
[...]
ERROR: invalid cluster offset=0x34ab0000
378 errors were found on the image.

12.2.2.4. Increasing the Size of an Existing Disk Image¶

When creating a new image, you must specify its maximum size before the image is created (see Section 12.2.2.1, “qemu-img create”). After you install and run VM Guest for some time, the initial size of the image may no longer be sufficient and you need to add more space to it.

To increase the size of an existing disk image, follow these steps:

Create a new additional disk image with the raw format. It must be as big as the size by which you decided to increase your existing disk image (2 GB in our example).
```
tux@venus:~> qemu-img create -f raw /images/additional.raw 2G
Formatting '/images/additional.raw', fmt=raw size=2147483648
```
Convert your existing disk image from your native format into the raw one. If your disk image format already is raw, skip this step.
```
tux@venus:~> qemu-img convert -f vmdk -O raw /images/sles11sp1.vmdk \
/images/original.raw
```
Append the newly created disk image /images/additional.raw to your converted existing one /images/original.raw.
```
tux@venus:~> cat /images/additional.raw >> /images/original.raw
```
If the format of your existing image was not raw, convert it back to its original format.
```
tux@venus:~> qemu-img convert -f raw /images/original.raw -O vmdk \
/images/expanded.vmdk
```

View information about the new disk image.

tux@venus:~> qemu-img info /images/expanded.vmdk 
image: /images/expanded.vmdk
file format: vmdk
virtual size: 6.0G (6442450944 bytes)
disk size: 2.4G

The /images/expanded.vmdk image now contains an empty space of 2 GB after the final partition. You can resize the existing partitions or add new ones.

Figure 12.1. New 2GB Partition in Guest YaST Partitioner

12.2.3. Managing Snapshots of Virtual Machines with qemu-img Snapshot¶

Virtual machine snapshots are snapshots of the complete environment in which VM Guest is running. The snapshot includes the state of the processor (CPU), memory (RAM), devices, and all writable disks.

Snapshots are helpful when you need to save your virtual machine in a particular state. For example, after you configured network services on a virtualized server and want to quickly start the virtual machine in the same state you last saved it. Or you can create a snapshot after the virtual machine has been powered off to create a backup state before you try something experimental and possibly make VM Guest unstable. This section introduces the latter case, while the former is described in Chapter 14, Administrating Virtual Machines with QEMU Monitor.

To use snapshots, your VM Guest must contain at least one writable hard disk image in qcow2 format. This device is usually the first virtual hard disk.


Currently, only the `raw` disk image format is supported by Novell.

Virtual machine snapshots are created with the savevm command in the interactive QEMU monitor. You can assign a 'tag' to each snapshot which makes its identification easier. For more information on QEMU monitor, see Chapter 14, Administrating Virtual Machines with QEMU Monitor.

Once your qcow2 disk image contains saved snapshots, you can inspect them with the qemu-img snapshot command.


Do not create or delete virtual machine snapshots with the qemu-img snapshot command while the virtual machine is running. Otherwise, you can damage the disk image with the state of the virtual machine saved.

12.2.3.1. Listing Existing Snapshots¶

Use qemu-img snapshot -l disk_image to view a list of all existing snapshots saved in the disk_image image. You can get the list even while the VM Guest is running.

tux@venus:~> qemu-img snapshot -l /images/sles11sp1.qcow2 
Snapshot list:
ID       TAG               VM SIZE        DATE          VM CLOCK
1         booting                4.4M 2010-11-22 10:51:10   00:00:20.476
2         booted                 184M 2010-11-22 10:53:03   00:02:05.394
3         logged_in              273M 2010-11-22 11:00:25   00:04:34.843
4         ff_and_term_running    372M 2010-11-22 11:12:27   00:08:44.965

	Unique identification number of the snapshot. Usually auto-incremented.
	Unique description string of the snapshot. It is meant as a human readable version of the ID.
	The disk space occupied by the snapshot. Note that the more memory is consumed by running applications, the bigger the snapshot is.
	Time and date the snapshot was created.
	The current state of the virtual machine's clock.

12.2.3.2. Creating Snapshots of a Powered-Off Virtual Machine¶

Use qemu-img snapshot -c snapshot_title disk_image to create a snapshot of the current state of a virtual machine which was previously powered off.

tux@venus:~> qemu-img snapshot -c backup_snapshot /images/sles11sp1.qcow2

tux@venus:~> qemu-img snapshot -l /images/sles11sp1.qcow2 
Snapshot list:
ID        TAG                 VM SIZE                DATE       VM CLOCK
1         booting                4.4M 2010-11-22 10:51:10   00:00:20.476
2         booted                 184M 2010-11-22 10:53:03   00:02:05.394
3         logged_in              273M 2010-11-22 11:00:25   00:04:34.843
4         ff_and_term_running    372M 2010-11-22 11:12:27   00:08:44.965
5         backup_snapshot           0 2010-11-22 14:14:00   00:00:00.000

Once something breaks in your VM Guest and you need to restore the state of the saved snapshot (id 5 in our example), power off your VM Guest and do the following:

tux@venus:~> qemu-img snapshot -a 5 /images/sles11sp1.qcow2

Next time you run the virtual machine with qemu-kvm, it will be in the state of snapshot number 5.


The qemu-img snapshot -c command is not related to the `savevm` command of QEMU monitor (see Chapter 14, Administrating Virtual Machines with QEMU Monitor. For example, you cannot apply a snapshot with qemu-img snapshot -a on a snapshot created with `savevm` in QEMU's monitor.

12.2.3.3. Deleting Snapshots¶

Use qemu-img snapshot -d snapshot_id disk_image to delete old or unneeded snapshots of a virtual machine. This saves some disk space inside the qcow2 disk image as the space occupied by the snapshot data is restored:

tux@venus:~> qemu-img snapshot -d 2 /images/sles11sp1.qcow2

12.2.4. Disk Images Effectively¶

Imagine the following real-life situation: you are a server administrator who runs and manages a number of virtualized operating systems. One group of these systems are based on one specific distribution, while another group (or groups) is based on different versions of the distribution or even on a different (and maybe non-Unix) platform. And to make the case even more complex, individual virtual guest systems based on the same distribution usually differ according to the department and deployment: a file server typically uses different setup and services than a Web server does, while both may still be based on SUSE® Linux Enterprise Server 11 SP1.

With QEMU it is possible to create a 'base' disk images. You can use them as template virtual machines. These base images will save you plenty of time because you will never need to install the same operation system more than once.

12.2.4.1. Base and Derived Images¶

First, build a disk image as usual and install the target system on it. For more information, see Section 12.1, “Basic Installation with qemu-kvm” and Section 12.2.2, “Creating, Converting and Checking Disk Images”. Then build a new image while using the first one as a base image. The base image is also called a 'backing' file. After your new 'derived' image is built, never boot the base image again, but boot the derived image instead. Several derived images may depend on one base image at the same time. Therefore, changing the base image can damage the dependencies. While using your derived image, QEMU writes changes to it and uses the base image only for reading.

It is a good practice to create a base image from a freshly installed (and, if needed, registered) operating system with no patches applied and no additional applications installed or removed. Later on, you can create another base image with the latest patches applied and based on the original base image.

12.2.4.2. Creating Derived Images¶

Currently, Novell supports only the raw image format.

While you can use the raw format for base images, you cannot use it for derived images because the raw format does not support the backing_file option. Use the qcow2 format for the derived images.

For example, /images/sles11sp1_base.raw is the base image holding a freshly installed system.

tux@venus:~> qemu-img info /images/sles11sp1_base.raw 
image: /images/sles11sp1_base.raw
file format: raw
virtual size: 4.0G (4294967296 bytes)
disk size: 2.4G

The image's reserved size is 4 GB, the actual size is 2.4 GB, and its format is raw. Create an image derived from the /images/sles11sp1_base.raw base image with:

tux@venus:~> qemu-img create -f qcow2 /images/sles11sp1_derived.qcow2 \
-o backing_file=/images/sles11sp1_base.raw 
Formatting '/images/sles11sp1_derived.qcow2', fmt=qcow2 size=4294967296 \
backing_file='/images/sles11sp1_base.raw' encryption=off cluster_size=0

Look at the derived image details:

tux@venus:~> qemu-img info /images/sles11sp1_derived.qcow2 
image: /images/sles11sp1_derived.qcow2
file format: qcow2
virtual size: 4.0G (4294967296 bytes)
disk size: 140K
cluster_size: 65536
backing file: /images/sles11sp1_base.raw \
(actual path: /images/sles11sp1_base.raw)

Although the reserved size of the derived image is the same as the size of the base image (4 GB), the actual size is 140 kB only. The reason is that only changes made to the system inside the derived image are saved and the new image is in fact empty. Run the derived virtual machine, register it if needed, and apply the latest patches. Do any other changes in the system such as removing unneeded or installing new software packages. Then shut the VM Guest down and examine its details once more:

tux@venus:~> qemu-img info /images/sles11sp1_derived.qcow2
image: /images/sles11sp1_derived.qcow2
file format: qcow2
virtual size: 4.0G (4294967296 bytes)
disk size: 1.1G
cluster_size: 65536
backing file: /images/sles11sp1_base.raw \
(actual path: /images/sles11sp1_base.raw)

The disk size value has grown to 1.1 GB, which is the disk space occupied by the changes on the filesystem compared to the base image.

12.2.4.3. Rebasing Derived Images¶

Once you modify the derived image (apply patches, install specific applications, or change the environment settings etc.) into a satisfactory shape, at some point you probably want to create a new base image 'merged' from the base image and the derived one. Your first base image (/images/sles11sp1_base.raw) holds a freshly installed system and can be a template for new modified base images, while the new one can contain the same system as the first one plus all security and update patches applied, for example. After you created this new base image, you can use it as a template for more specialized derived images as well. The new base image becomes independent of the original one. The process of creating base images from derived ones is called 'rebasing':

tux@venus:~> qemu-img convert /images/sles11sp1_derived.qcow2 \
-O raw /images/sles11sp1_base2.raw

This command created the new base image /images/sles11sp1_base2.raw using the raw format.

tux@venus:~> qemu-img info /images/sles11sp1_base2.raw
image: /images/sles11sp1_base2.raw
file format: raw
virtual size: 4.0G (4294967296 bytes)
disk size: 2.8G

The new image is 0.4 gigabytes bigger than the original base image. It uses no backing file, which means it is independent and therefore a base image. You can create new derived images based upon it. This lets you create a sophisticated hierarchy of virtual disk images for your organization, saving a lot of time and work.

12.2.4.4. Mounting an Image on VM Host Server¶

Sometimes it is useful to mount a virtual disk image under the host system. For example, if VM Host Server does not have a network support, this can be the only way to transfer files in and out of VM Guest.

Linux systems can mount an internal partition of a raw disk image using a 'loopback' device. The first example procedure is more complex but more illustrative, while the second one is straightforward:

Procedure 12.1. Mounting Disk Image by Calculating Partition Offset

Set a loop device on the disk image whose partition you want to mount.
```
tux@venus:~> losetup /dev/loop0 /images/sles11sp1_base.raw
```

Find the sector size and the starting sector number of the partition you want to mount.

tux@venus:~> fdisk -lu /dev/loop0

Disk /dev/loop0: 4294 MB, 4294967296 bytes
255 heads, 63 sectors/track, 522 cylinders, total 8388608 sectors
Units = sectors of 1 * 512 = 512 bytes
Disk identifier: 0x000ceca8

       Device Boot      Start         End      Blocks   Id  System
/dev/loop0p1              63     1542239      771088+  82  Linux swap
/dev/loop0p2   *     1542240    8385929     3421845   83  Linux

	The disk sector size.
	The starting sector of the partition.

Calculate the partition start offset:
sector_size * sector_start = 512 * 1542240 = 789626880

Delete the loop and mount the partition inside the disk image with the calculated offset on a prepared directory.

tux@venus:~> losetup -d /dev/loop0
tux@venus:~> mount -o loop,offset=789626880 \
/images/sles11sp1_base.raw /mnt/sles11sp1/
tux@venus:~> ls -l /mnt/sles11sp1/
total 112
drwxr-xr-x   2 root root  4096 Nov 16 10:02 bin
drwxr-xr-x   3 root root  4096 Nov 16 10:27 boot
drwxr-xr-x   5 root root  4096 Nov 16 09:11 dev
[...]
drwxrwxrwt  14 root root  4096 Nov 24 09:50 tmp
drwxr-xr-x  12 root root  4096 Nov 16 09:16 usr
drwxr-xr-x  15 root root  4096 Nov 16 09:22 var

Copy a file or files on the mounted partition and unmount it when finished.

tux@venus:~> cp /etc/X11/xorg.conf /mnt/sles11sp1/root/tmp
tux@venus:~> ls -l /mnt/sles11sp1/root/tmp
tux@venus:~> umount /mnt/sles11sp1/

Procedure 12.2. Mounting Disk Image while Utilizing kpartx

Set a loop device on the disk image whose partition you want to mount.
```
tux@venus:~> losetup /dev/loop0 /images/sles11sp1_base.raw
```
Create a device map from the disk image's partitions.
```
tux@venus:~> kpartx -a /dev/loop0
```
Mount any partition of the disk image on a prepared mount point.
```
tux@venus:~> mount /dev/mapper/loop0p1 /mnt/p1
```
You can replace loop0p1 with the number of the partition you want to mount, for example loop0p3 to mount the third partition on the disk image.
Copy or move files or directories to and from the mounted partition as you like. Once you finish, unmount the partition and delete the loop.
```
tux@venus:~> umount /mnt/p1
```
```
tux@venus:~> losetup -d /dev/loop0
```


Never mount a partition of an image of a running virtual machine. This could corrupt the partition and break the whole VM Guest.