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:

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.

[Warning]

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 create1 -f raw2 /images/sles11/hda3 8G4

1

The subcommand create tells qemu-img to create a new image.

2

Specify the disk's format with the -f parameter. Currently, only the raw disk format is supported by Novell.

3

The full path to the image file.

4

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"1 -M pc-0.122 -m 7683 \
-smp 24 -boot d5 \
-drive file=/images/sles11/hda,if=virtio,index=0,media=disk,format=raw6 \
-drive file=/isos/SLES-11-SP1-DVD-x86_64-GM-DVD1.iso,index=1,media=cdrom7 \
-net nic,model=virtio,macaddr=52:54:00:05:11:118 \
-vga cirrus9 -balloon virtio10
   

1

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.

2

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.

3

Maximum amount of memory for the virtual machine.

4

Defines an SMP system with two processors.

5

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.

6

Defines the first (index=0) hard disk. It will be accessed as a paravirtualized (if=virtio) drive in raw format.

7

The second (index=1) image drive will act as a CD-ROM.

8

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.

9

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.

10

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 fmt1 -o options2 fname3 size4

1

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.

2

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.

3

Path to the target disk image to be created.

4

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 -c1 -f fmt2 -O out_fmt3 -o options4 fname5 out_fname6

1

Applies compression on the target disk image. Only qcow and qcow2 formats support compression.

2

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

3

The format of the target disk image.

4

Specify additional options relevant for the target image format. Use -o ? to view the list of options supported by the target image format:

5

Path to the source disk image to be converted.

6

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 fmt1 fname2

1

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

2

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:

  1. 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
  2. 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
  3. 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
  4. 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
  5. 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

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.

[Note]

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.

[Warning]

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:
ID1       TAG2               VM SIZE3        DATE4          VM CLOCK5
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

1

Unique identification number of the snapshot. Usually auto-incremented.

2

Unique description string of the snapshot. It is meant as a human readable version of the ID.

3

The disk space occupied by the snapshot. Note that the more memory is consumed by running applications, the bigger the snapshot is.

4

Time and date the snapshot was created.

5

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.

[Note]

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

[Note]

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

  1. Set a loop device on the disk image whose partition you want to mount.

    tux@venus:~> losetup /dev/loop0 /images/sles11sp1_base.raw
  2. 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 = 5121 bytes
    Disk identifier: 0x000ceca8
    
           Device Boot      Start         End      Blocks   Id  System
    /dev/loop0p1              63     1542239      771088+  82  Linux swap
    /dev/loop0p2   *     15422402    8385929     3421845   83  Linux

    1

    The disk sector size.

    2

    The starting sector of the partition.

  3. Calculate the partition start offset:

    sector_size * sector_start = 512 * 1542240 = 789626880

  4. 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
    
  5. 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

  1. Set a loop device on the disk image whose partition you want to mount.

    tux@venus:~> losetup /dev/loop0 /images/sles11sp1_base.raw
  2. Create a device map from the disk image's partitions.

    tux@venus:~> kpartx -a /dev/loop0
  3. 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.

  4. 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
[Warning]

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