About
Blog
Research
Services

Qemu Windows Guest: Introduction

By Dejan Lukan | Dec 26, 2013 | General Security |

In this article we'll present how we can use Qemu instead of Virtualbox/VMWare. Those products are all great, but sometimes we would just like to use something a little more lightweight, which is when Qemu comes into play.

Qemu can be used in one of the following ways:

  • Together with KVM/XEN: Qemu is used together with Type-I hypervisor like KVM or XEN, which results in faster performance.
  • Standalone: if Qemu is used in standalone mode without also using KVM/XEN, then it's running entirely in user-space, which results in slower performance.

We almost always want to choose to use Qemu with KVM/XEN, which will be quite faster than using it alone. In this example we'll be using underlying KVM. In order to do that our computer must support the virtualization technology, which we can check by executing "cat /proc/cpuinfo" and checking whether the cpuflags list vmx or svm flags in which case the virtualization is supported by our processor.

We won't go into installing the Qemu and KVM, because there are really a lot of resources out there that show us how to do that. Instead we'll start with an article supposing that we already installed them. After installation, where will be a number of Qemu-* binaries available on our computer, but we're mostly interested in the following:

  • Qemu-system-x86_64: this is a Qemu binary that emulates the virtual machines without using the underlying hardware virtualization features supported by our processor. By using emulation, Qemu will completely emulate the hardware as well as the software and won't use the actual hardware we have, which results in slower performance.
  • Qemu-kvm: this is a Qemu binary that takes advantage of using the underlying hardware virtualization features supported by our process and is the main reason we'll be using it. By using KVM, the Qemu won't emulate the hardware, but use the hardware we already have and build upon that. This is quite faster, but our processor must support it for Qemu to be able to use it.

The names of the executables on your system might be different and they might actually be symlinks to one another, so you should definitely check it out before using it. What I tried to emphasize above is the distinction when using emulated hardware versus the real hardware and the gain/loss of performance that go with it, rather than the actual names of the executables.

Creating the Image

What's quite different from Virtualbox/VMWare is the fact that we need to create the image with a command-line. In Virtualbox/VMWare we can do that easily with the graphical user interface, but in Qemu we have to do it by hand. Well there is a GUI for Qemu as well called virt-manager, but I didn't had good experience with it. But we should also know how to do it by hand and then switch to a GUI alternative, because this is a good way to actually learn something and possibly fix it when problems arise.

To create the image for our guest operating system, we must use the qemu-img executable, which uses the following format:

# qemu-img command [command options]

We should supply the command and appropriate command line options to the qemu-img. We can use the following commands with qemu-img:

  • check: perform a consitency check on the image.
  • create: create a new image.
  • commit: commit the changes from a file to the image.
  • compare: check if the two images have the same content.
  • convert: convert the image to another image.
  • info: print the information about the image.
  • snapshot: manage snapshots of the image.
  • rebase: change the backing file.
  • resize: change the size of the image.

To create the image, we must use the "qemu-img create" command, which has the following syntax:

# qemu-img create [-f fmt] [-o options] filename [size]

The -f option specifies the format of the image, which can be one of the following [1]:

  • raw: this is the default option and specifies raw disk image, where the holes in an image will not occupy any space in the underlying filesystem; this only works if the filesystem supports it.

  • host_device: similar to the raw format, where even the holes in an image occupy the space on the filesystem: this is mostly used for block devices.

  • cow: old qemu image format, which is still present for backward compatibility.

  • qcow: old qemu image format, which is still present for backward compatibility.

  • qcow2: new qemu image format, which supports some advances features like compression and encryption. There are multiple options we can use with qcow2 file format:

    • backing_file: file name of the base image.
    • backing_fmt: image format of the base image.
    • encryption: image encryption by using the AES format with 128-bit keys.
    • cluster_size: the cluster size, which can be between 512 and 2M, where the larger cluster size provides better performance, which results in larger image size.
    • preallocation: specifies which parts of the image are preallocated, where we can choose between: off, metadata and full values. The off value doesn't provide any preallocation, which results in the smallest image size, the metadata preallocates the metadata of the image, which improves performance when the image needs to grow and full preallocates the whole image filling every byte with zeros, which results in the biggest image size.

  • vdi: Virtualbox image format.

  • vmdk: Vmware image format.

  • vpc: VirtualPC image format.

  • cloop: Linux compressed loop image used for cdrom images.

Now we've presented every needed information that we need to actually create the image for the guest. The command below creates a 40GB windows7.img image by using the qcow2 file format, cluster size 2MB and metadata preallocation.

# qemu-img create -f qcow2 -o preallocation=metadata -o
cluster_size=2M Windows7.img 40G

This will result in preallocating the metadata information on the disk, which results in slightly larger disk size as we can see below.

# qemu-img info Windows7.img
image: Windows7.img
file format: qcow2
virtual size: 40G (42949672960 bytes)
disk size: 4.1M
cluster_size: 2097152

Now we've successfully created the image disk size that we'll use to install the operation system on. Remember that we basically did the same thing we normally do with a wizard when creating a new virtual machine in Virtualbox/VMWare. This might be confusing for new users of Qemu, since we must actually use two tools: the qemu-img to create the virtual machine and qemu-kvm to manage the virtual machine. We're essentially doing the same thing as with Virtualbox/VMware, except that with those products we have just one program (GUI) that does most of the work for us. If we look at the command line programs of Virtualbox we can quickly see that we can do the same things from the command-line as we can do with its graphical user interface.

Conclusion

In this article we've looked at the qemu-img command line tool and its configuration options. We've essentially created the virtual machine that we can play with. Once the image for the virtual machine is created, we can actually start to play with the virtual machines, give it devices, configure networking, etc.

In the next article, we'll take a look at how we can go about installing Windows 7 operating system on the created image.

References:

[1] Qemu-img man page, http://linux.die.net/man/1/qemu-img.

[2] Qemu-kvm man page, http://linux.die.net/man/1/qemu-kvm.

[3]Updating the guest initramfs with the virtio driver, http://www.linux-kvm.org/page/Boot_from_virtio_block_device#Windows_XP.

[4] Ebtables, http://ebtables.sourceforge.net/.

[5] Saying How To Mangle The Packets, http://www.netfilter.org/documentation/HOWTO/NAT-HOWTO-6.html. [5] Saying How To Mangle The Packets,

Comments

CONTACT US