Howto Qemu-kvm Debian 8

Table of Contents

In the world of virtualization, managing storage efficiently is a crucial task. One way to achieve this is by creating dynamic disks, which only use up the actual space used by the virtual machine, rather than the full specified size. In this article, we will take a deep dive into how to create dynamic disks in QEMU/KVM with .qcow2 format.

To create dynamic disks in QEMU/KVM with .qcow2 format, you can use the virt-manager tool. Simply open virt-manager, add storage hardware, choose the qcow2 format, specify the disk size, and uncheck the option to allocate the entire disk. Specify the location and name for the virtual disk file, and you’re done!

What is QEMU/KVM?

QEMU, short for Quick Emulator, is a free and open-source machine emulator and virtualizer. When used as a machine emulator, QEMU can run OSes and programs made for one machine on a different machine. When used as a virtualizer, QEMU achieves near-native performance by executing the guest code directly on the host CPU.

KVM, or Kernel-based Virtual Machine, is a full virtualization solution for Linux on x86 hardware containing virtualization extensions (Intel VT or AMD-V). It consists of a loadable kernel module, kvm.ko, that provides the core virtualization infrastructure and a processor-specific module, kvm-intel.ko or kvm-amd.ko.

What is. qcow2 Format?

Let’s look at the steps to create a dynamic disk in QEMU/KVM with .qcow2 format using virt-manager:

Open virt-manager

Virt-manager, or Virtual Machine Manager, is a graphical tool for managing KVM virtual machines. Open it and either create a new virtual machine or select an existing one.

Add Hardware

In the virtual machine settings, navigate to the “Add Hardware” section and choose “Storage”.

Choose Storage Type

Select “File disk image” and click “Forward”.

Specify Disk Size and Format

Choose the desired storage format, either “qcow2” or “raw”, and specify the disk size.

Create Dynamic Disk

Uncheck the option “Allocate entire disk now”. This creates a dynamic disk, also known as a sparse file, which only takes up the actual space used by the virtual machine.

Specify Location and Name

Specify the location and name for the virtual disk file and click “Finish” to create the disk.

Important Considerations

The ability to create dynamic disks depends on the file system of the target location where you copy the virtual disk. Some file systems may not support sparse files, resulting in the disk file taking up the full specified size even if it is created as a dynamic disk.

If you are copying the disk to a removable drive, ensure the file system on the drive supports sparse files. If you encounter issues with the disk file not being copied as a sparse file, you can try using different copy tools or copying the file to a different location on the same disk to ensure that the sparse file is retained.

Conclusion

QEMU is a machine emulator and virtualizer, while KVM is a full virtualization solution for Linux on x86 hardware. Q EMU can run OSes and programs made for one machine on a different machine, while KVM achieves near-native performance by executing guest code directly on the host CPU.

When creating dynamic disks, it’s important to consider the file system of the target location where you copy the virtual disk. Some file systems may not support sparse files, which could result in the disk file taking up the full specified size even if it is created as a dynamic disk. Ensure that the file system supports sparse files, especially if you are copying the disk to a removable drive.

If you encounter issues with the disk file not being copied as a sparse file, you can try using different copy tools or copying the file to a different location on the same disk. This can help ensure that the sparse file is retained.

Время на прочтение

В этом howto мы с вами просто и быстро, шаг за шагом, запустим гипервизор Qemu-KVM в debian 8.

aptitude install -y firmware-linux bridge-utils etckeeper

Check if our processor supports virtualization:

Enable forwarding, net.ipv4.ip_forward=1

Create bridge br0
Sample /etc/network/interfaces

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
#autoeth0
#allow-hotplug eth0
#iface eth0 inet dhcp

auto br0
iface br0 inet dhcp
bridge_ports eth0
bridge_stp off
bridge_fd 0
bridge_maxwait 0

Let’s check, it should look like «br0 8000.08608ee7dc58 no eth0»

Using the bridge, vnetX interfaces will be raised at the start of the virtual machine

tcpdump -i vnet0 -n

aptitude install qemu-kvm libvirt-bin

Add user to kvm groups:

Let’s allow access for spice and change the user under which everything will work:

By and large everything is ready to go.
Without running virtual machines, the host system occupies ~150 mb ram

Can be skipped — advanced option

GUI manager for performing basic tasks when working with kvm.
Create, start / stop, clone — almost 🙂 everything you need.

Install on another computer:

aptitude install ssh-askpass virt-manager virt-viewer spice-client-gtk

You can connect to the created virtual machine with a simple weaver with all the functionality that spice provides.
To do this, you need to find out the URI of the domain/virtual machine on kvm

virsh dom display corn

Run on the client:

The same with another weaver, which is spice-client-gtk:

spicy -h 10.1.1.8 -p 5905

How to make TLS friends is written here — habrahabr.ru/post/221693

We continue to configure as root

Determine the pools — where everything will be
storage configurations are stored in /etc/libvirt/storage/
by default there is default.xml — storage on the file system in /var/lib/libvirt/images
Add our qemu-test-storage:
*-as creates storage similar to default, i.e. the configuration is the same as in default.xml

Pool is not running by default, start:

virsh pool-start qemu-test-storage

Add the created pool to autostart:

virsh pool-autostart qemu-test-storage

View all pools:

virsh pool-list —all

virsh list —all

Register a domain (virtual machine) with the configuration described in the corn.xml file
It is easier to create an xml with a configuration (for example, for a template) through virt-manager than to describe each option in virt-install.
All virtual machine configurations are stored in /etc/libvirt/qemu/
In general, it is assumed that we have this file.

Add domain to autoload:

virsh autostart corn

Current domain configuration:

virsh dumpxml corn

virsh edit corn

We start the domain, look at the URI and connect in any way possible.

virsh start corn
virsh dom display corn

To install windows on a VirtIO partition, the installer needs a driver from the viostor folder of the virtio for windows driver set.
On linux-kvm.org there are sources, on fedoraproject.org you can find compiled virt-win.iso
After installation, you will most likely need spice windows guest tools

Now let’s expand the domain volume.
Let’s use qemu-img — QEMU disk image utility. In our case, the corn.qcow2 volume
Observation — windows 7 is not enough 10GB to download everything from the update center at once and install them correctly.
It can be useful to first install «Update for Windows 7 (KB2852386)» — at the very least (read, nothing) cleans C: Windowswinxsx through the standard «disk cleanup» and between reboots, and then use the update center.

The following is minimum sufficient:

qemu-img resize corn.qcow2 +10GB

Then we add the CD-ROM device, «insert gparted there» and everything is as usual. Russian language — 24.
For good, you should use libguestfs-tools or resize2fs

Windows 8.1 needs a wddm driver, QXL will be very slow, it’s better to forward the host video card
It is very well written about Windows OEM activation here — habrahabr.ru/post/247597

As you know, you need to make backups, moreover, you need to make them in such a way that later you can turn around from them. This is especially true for virtual machines (VMs). Consider how you can backup the virtual disks of a machine in a QCOW / KVM environment. There are two main problems here: firstly, you need to get a consistent (holistic) backup, i.e. if we have a DBMS or other software that actively uses its own write cache, then before backup it must be asked to reset the cache and freeze the write to disk, otherwise the data will get into the snapshot, but not the same, and when restoring the DBMS may not understand such a trick. The second question is the performance of the VM in snapshot mode, it would be nice if the VM would not slow down too much when we make a copy, and would not freeze when we delete the snapshot.

I will immediately give an answer to the first question — in order to get a consistent backup, you need to turn off the VM using the guest OS before creating the backup, then the backup will definitely turn out to be complete. If this situation suits you, you can stop reading the article. If not, I ask under cat.

So, to get a consistent backup without shutting down the VM, you need to use a guest agent for QEMU (not to be confused with a guest agent for QEMU SPICE and paravirtual drivers for QEMU in general). In the Debian Jessie repository this is the qemu-guest-agent package, in Wheezy the package is only available via wheezy-backports. Q EMU guest agent is a small utility that accepts commands from the host via a virio channel named org.qemu.guest_agent.0 and executes them in the guest context. On the hypervisor side, the channel ends with a unix socket, into which you can write text commands using the socat utility. Libvirt, however, likes to occupy this channel itself, so if you use Libvirt to control the hypervisor, you will have to communicate with the guest through the “virsh qemu-agent-command” command. QEMU guest agent can do different commands, for example, here is my list:

A brief description of the commands is in the qga/qapi-schema.josn file in the QEMU sources, and a complete one can be obtained by parsing the qga/commands-posix.c and qga/commands-win32.c files. From the analysis, you can, for example, find out that the guest-set-vcpus, guest-get-vcpus, guest-network-get-interfaces, guest-suspend-hybrid, guest-suspend-ram, guest-suspend-disk commands under Windows do not are supported, and the guest-fsfreeze-freeze/guest-fsfreeze-thaw commands try to use Volume Shadow Copy — VSS under Windows. However, since this article will focus on Linux as a guest, these subtleties will not concern us.

Among the entire list of commands, we are interested in guest-fsfreeze-freeze and guest-fsfreeze-thaw. As the name implies, the first one “freezes” the guest’s file system, while the second one “unfreezes” it. The command (more precisely IOCTL) fsfreeze is not a feature of QEMU, but the ability of the guest’s virtual file system, which appeared in the Linux kernel for a long time. That is, you can freeze a file system not only in a virtual environment, but also on real hardware, just use the fsfreeze utility from the util-linux package. The fsfreeze man says that Ext3/4, ReiserFS, JFS, XFS are supported, but I have fsfreeze frozen Btrfs as well. Before the actual “freeze”, but after all write streams have completed, sync () is called by the kernel code (file fs / super.c, line 1329), so you don’t have to worry about data integrity. In general, the “freezing” of the FS is needed by the kernel to obtain complete snapshots of LVM volumes, and not for dubious fun with virtualization systems.

So, we know that in order to get a complete snapshot, we need to call the guest-fsfreeze-freeze function from the guest using the QEMU guest agent. However, perhaps we are worrying in vain and this function will be called when creating a snapshot? Alas, for Libvirt (2.9), and for Proxmox (pvetest branch), and for Openstack this is not the case, which means that in order to automate the call to the guest-fsfreeze-freeze function, you need to edit the source codes of the corresponding products, which is beyond the scope of this article.

Libvirt can still freeze the guest FS

As the respected Infod suggests, the virsh shell from Libvirt can be passed the —quiesce parameter when creating a snapshot, which will call guest-fsfreeze-freeze when creating a snapshot:

virsh snapshot-create-as myvm snapshot1 «snapshot1 description» —disk-only —atomic —quiesce

Let’s say we found a way (for example, with a self-written script) to “freeze” the guest’s FS before taking a snapshot. Now we are faced with the next task — to notify the guest software just before the freeze. Q EMU guest agent supports the -F option, which says that before “freezing” and after “defrosting”, you need to call the /etc/qemu/fsfreeze-hook script with the freeze and thaw options, respectively. Therefore, in Debian, the agent launch script (/etc/init.d/qemu-guest-agent) will have to be corrected: DAEMON_ARGS=»-F». Keep in mind that if the script ends with an error, the file system will not be frozen.

For a MySQL server, the first script that comes to mind, but not working, might look something like this:

In fact, the lock from the base will be removed immediately upon completion of the command

due to the fact that all locks in MySQL work only while the user who set them is present in the system. For a correct backup, you will have to write an additional small service (for example, in Python) that will open the MySQL database and set a lock on the freeze command, and then not close the database and wait for the thaw command.

What about Windows as a guest?

I must say that for Windows and MS SQL, the same procedure does not require any body movements — QEMU guest agent automatically calls the appropriate function of the VSS volume shadow copy service, VSS informs all subscribers that the backup is about to start and it was not bad to “flush” to disk, etc.

So, we have locked MySQL tables and “frozen” the guest’s FS, it’s time to take a backup. Let’s assume that we store VM disk images in qcow2 format files, and not, for example, in the form of LVM volumes. Even in this case, we are offered many options, it would be nice to understand them.

An LVM volume snapshot will cause a drop in the write performance of the main volume, so it is better to use it when we are sure that the disk will not be written heavily during the lifetime of the snapshot.

The use of the BTRFS file system as a file system for storing disk images opens up great prospects, since in this case snapshots, compression and deduplication are provided by the FS architecture itself. Cons — Btrfs cannot be used as a shared file system in a clustered environment, besides, Btrfs is a relatively new file system and may be less reliable than a bunch of LVM and ext4.

The drive_backup method of getting backups is good because you can immediately create a backup copy on a mounted remote storage, but in this case it creates a large load on the network. For other methods, you can provide for the transfer of only changed blocks using rsync. Unfortunately, QEMU backup does not support the transfer of only “dirty” (changed since the last backup) blocks, as is implemented, for example, in the VMWare CBT mechanism. Both attempts to implement such a mechanism — livebackup and in-memory dirty bitmap were not accepted into the main branch of QEMU, apparently, the first one is due to the architecture (an extra daemon and a separate network protocol are added only for this operation), the second one is due to obvious limitations in use: the map of «dirty» blocks can only be stored in RAM.

Finally, let’s consider a situation in which a VM has several mounted disk images. Obviously, for such a VM, you need to create snapshots of all disks at the same time. If you use Libvirt, then you have nothing to worry about — the library takes care of snapshot synchronization. But, if you want to perform this operation on a “pure” QEMU, then there are two ways to do this: stop the VM with the stop command, get snapshots, and then continue executing the VM with the cont command, or use the transactional command execution mechanism available in QEMU. You cannot use only the QEMU guest agent and the guest-fsfreeze-freeze / guest-fsfreeze-thaw commands for this purpose, since although the agent “freezes” all mounted FS in one command, it does this not simultaneously, but sequentially, so desynchronization is possible between volumes.

Make backups, gentlemen!

Have you ever reduced the size of the qcow2 disk image used in KVM-QEMU virtual machines? As you know, the process of increasing the size of an image is quite simple and fast, but what about reducing it?

In this article, I will talk about the situation when you need to reduce the qcow2 image of a KVM virtual machine as quickly as possible.

Block device format — qcow2

But, nevertheless, this scheme can be done with raw images, it is enough to convert it to qcow2. In general, the instruction will be relevant for everything that is converted to qcow2.

An easy way to shrink a disk on a KVM is as follows:

Host: CentOS 7 + QEMU 2.12 + LIBVIRT 4.5.0 + Kernel UEK5 v. 4.14
VM: CentOS 7 + 80GB HDD + Kernel std v. 3.10
The donor will be a CentOS 7 virtual machine with an 80GB hard disk image, actually occupied by 20GB and physically 80GB. We will reduce to 40GB.

What is the difference between image size, actual and physical size?
Let’s say the qcow2 image is 80GB in size and we know about it. During operation, the image was clogged with data, some data was deleted. If in general terms — due to the peculiarities of the process of writing and deleting data, for the OS, the deleted data does not seem to exist, but remains recorded in the image until they are overwritten by other data. Accordingly, even though in the OS you will see 20GB of actually occupied data, the KVM host will show such a wonderful picture (we use the qemu-img utility to get information):

qemu-img info qcow2_image.img
image:qcow2_image.img
file format: qcow2
virtual size: 80G (85899345920 bytes)
disk size: 80G
cluster_size: 65536
Format specific information:
compat: 0.10
refcount bits: 16

You can see that virtual size = disk size, as well as du -sh of the image will show that it takes real 80G:

du -sh qcow2_image.img
80G qcow2_image.img

And since we need to reduce the size of the image to 40GB, let’s start the process.

Stage 1 — Block device (image) compression

Before starting the disk reduction procedure, you need to make sure that the space occupied inside the OS is less than the volume to which the disk will be reduced anyway.

df -h /
Filesystem Size Used Avail Use% Mounted on
/dev/vda2 80G 18G 63G 22% /

As we can see, 18GB is occupied, which is less than 40GB. Turn off the VM with the command

shutdown -h now

And go to the host machine, check:

# qemu-img info qcow_shrink
image: qcow_shrink
file format: qcow2
virtual size: 80G (85899345920 bytes)
disk size: 80G
cluster_size: 65536
Format specific information:
compat: 0.10
refcount bits: 16
# virt-df -h qcow_shrink
du -sh Filesystem Size Used Available Use%
qcow_shrink:/dev/sda1 488M 101M 351M 21%
qcow_shrink:/dev/sda2 79G 17G 62G 22%
# du -sh qcow_shrink
80G qcow_shrink

To compress an image, we need a simple virt-sparsify utility. Make sure that the VM is not running and execute the command in the directory along with the disk image (Important note: before starting virt-sparsify, make sure that there is enough free space in /tmp and in the image storage to complete the operation)

virt-sparsify qcow_shrink qcow_shrink-new

The result of the successful completion of the operation will be the following output:

Then we do a disk replacement (move qcow_shrink somewhere to the side, for example qcow_shrink-old, and qcow_shrink-new in its place — qcow_shrink).

mv qcow_shrink qcow_shrink-old && mv qcow_shrink-new qcow_shrink

Start the VM. If everything started, we extinguish the VM and continue to work.

Stage 2 — Making a smaller disc

A simple procedure that includes just one command:

qemu-img create -f qcow2 -o preallocation=metadata qcow_shrinked 40G

qcow_shrinked — new image name
40G — new size

Stage 3 — connecting gparted

Since sometimes admins prefer easier ways to solve an issue, the tambourine is put aside (kpartx) and ISO and VNC come in its place. Fortunately, in KVM it is not very difficult to connect it.

What we do:

How to do this, I will omit from this article, since it is assumed that doing all this already knows how to do this, but the result will be the following:

Start the VM and see the GParted boot screen:

Select the first item and follow the instructions on the screen. I usually press enter until the end.

Having seen GParted himself, let’s get down to business. We quickly check what partition table / dev / vda has — msdos or gpt. This is important:

Switch to the second disk /dev/vdb and create a partition table:

When creating a table, select the type msdos as we learned earlier.

Then we switch back to /dev/vda and sequentially, from the first disks, we start copying partitions, switching between vda and vdb:

End result will be:

Press Apply and wait for the result to complete:

Which already looks like the truth. But since we have done some manipulations that will change the UUID of the disks, we will potentially not boot into the OS. Why? CentOS 7 uses disk UUIDs in fstab, Grub2 uses disk UUIDs, so jump to the console and do some black magic.

Gparted runs initially as a user, so we jump as root with the command sudo su — root:

Let’s do blkid to make sure the UUID of partitions has changed

It can be seen that UUID vda1 = vdb1, while it has changed for vdb2. It’s okay — you can live with it.

Mount vdb completely, including /boot partition, and mount some partitions for our convenience.

mkdir vdb2
mount /dev/vdb2 vdb2
mount /dev/vdb1 vdb2/boot
cd vdb2
mount —bind /dev dev
mount —bind /sys sys
mount —bind /proc proc
root.

Let’s start with fstab — since typing UUID in VNC is not very convenient, we will replace it with the usual device name.

specify /dev/vdb2 if the old disk is not planned to be disconnected
specify /dev/vda2 if the old disk will be disabled

Since we disconnect the old disk before loading the OS, we write /dev/vda2

Next, we will change the bootloader, put it in order. Let’s assume that everything is in /boot/grub2, grub.cfg is in the same place, but efi is not (msdos table, which efi 🙂 ):

grub2-install /dev/vdb
cd /boot/grub2
grub2-mkconfig -o grub.cfg

On this, you can be happy for yourself and by disabling gparted, boot into the OS.

Stage 4 — OS boot

Before booting the OS, I still recommend disconnecting the old disk from the server. Therefore, at the previous stage, it was necessary to register vda2 in fstab, but if you are an attentive PC user and did not disable anything, then there should be no problems. With an old disk, it is likely to boot from it.

There were no problems during the download process, the server booted up as expected. Check it out:

We see that /boot and / are needed, the size is 40GB, the OS is working. Happiness, nothing else!

Bonus

Something that you will have to face in some situations.

Most likely, when everything was done in gparted or another environment, the kernel version of this environment was too new, in which xfs is slightly changed, namely, the metadata and their version are different. As a result, xfs made in the new kernel turns into a pumpkin in the old one. What we are doing is booting back into rescue gparted, raising the network in this rescue environment and installing the freshest possible kernel in the OS. I installed 5.x on CentOS 7, maybe 4.x is also suitable, I didn’t check it, but in the end everything worked. And, without any problems.

That’s it!

As you can see, there is nothing complicated about it. Of course, you can use LVM, resize2fs and other things, but still qcow2 is used somewhere else and even needed by someone.

If you know an even simpler way, write about it in the comments.

How to create a KVM Image File

dd if=/dev/zero of=raw-nonsparce.img bs=1M count=8196 #8G
dd if=/dev/zero of=raw-nonsparce.img bs=1M count=40980 #40G
dd if=/dev/zero of=raw-nonsparce.img bs=1M count=51225 #50G

Raw(sparse)

qemu-img create -f raw raw-sparce.img 8G

qemu-img create -f qcow2 qcow2.img 8G

TIPS

Last modified: 2019/06/06 by

How to change Image Files

qemu-img convert -O raw SRC.img DST.img

Raw (sparse, non-sparse) -> qcow2

qemu-img convert -O qcow2 SRC.img DST.img

Raw (sparse) -> raw (non-spase)

cp —sparse=never SRC.img DST.img