May 25, 2014 · kvm virtualization qemu testing linux

Useful things about backing file in qemu/kvm

One of the most important thing in development/hacking testing is to have untouched/original environment for fallback if something going wrong.

We may using snapshots (in lvm, qcow2 or on file system level), but sometimes it's too slow.

The other (and more interesting) way to fallback in our original environment is using backing file feature in qemu.

How it works:
It's just another way to snapshots. With backing file, you can create many virtual machines based one on another, and so on. The are no limitations on how many levels of backing do you using. But after creation VM, based on another image, this image must be untouched during such time as we need this VM, otherwise all based on original image VM's will be broken.

[root@localhost vm2]# qemu-img info jessie.raw 
image: jessie.raw  
file format: raw  
virtual size: 20G (21474836480 bytes)  
disk size: 13G
[root@localhost vm2]# qemu-img create -f qcow2 -b jessie.raw funny.qcow2 20G
Formatting 'funny.qcow2', fmt=qcow2 size=21474836480 backing_file='jessie.raw' encryption=off cluster_size=65536  

or

[root@localhost vm2]# qemu-img create -f qcow2 -o backing_file=jessie.raw funny.qcow2 20G
Formatting 'funny.qcow2', fmt=qcow2 size=21474836480 backing_file='precise.raw' encryption=off cluster_size=65536k  

this will create a 20G sparce image, based on our Debian Jessie

[root@localhost vm2]# qemu-img info funny.qcow2 
image: funny.qcow2  
file format: qcow2  
virtual size: 20G (21474836480 bytes)  
disk size: 196K  
cluster_size: 65536  
backing file: jessie.raw  
kvm -m 2048 -hdd funny.qcow2  

After this point all changes will be affect only our new VM, the original image will be and must be keep untouched.
This is very important: you can create many VM's based on one original, and run all simultaneously, but don't do any changes to original image. Backing file feature works on the block level, so any changes to original image will broke all virtual machines based on it.
In this scheme, rails2.qcow2 is based on rails.qcow2 wich based on funny3.qcow2 and so on. In this case, any changes to funny.qcow2 will broke all other VM's, exluding jessie.raw.

+----------------+     +----------------+                     
|   jessie.raw   |+---+|  funny.qcow2   |                
+----------------+     +-------+--------+                     
                                        |                              
                                +-------+--------+                     
                                |  funny_2.qcow2 |                     
                                +-------+--------+                     
                                        |                              
                                +-------+--------+    +--------------+ 
                                |  funny_3.qcow2 +--+ | rails.qcow2  | 
                                +----------------+    +-------+------+ 
                                                              |        
                                                              |        
                                                      +-------+------+
                                                      |rails_2.qcow2 |
                                                      +--------------+

So, better is create VM's in this way:

                +------------------+                  
              +-+  jessie.raw      ++                 
              | +---------+--------++                 
              |           |         |                 
+-------------+    +------+------+  | +--------------+
|funny.qcow2  |    |funny_2.qcow2|  +-+ rails.qcow2  |
+-------------+    +-------------+    +--------------+

All new VM's are based on jessie.raw, but are independent from each other.

Want more?

About snapshots
About libvirt
ACII schemes was created by asciiflow.com

  • LinkedIn
  • Tumblr
  • Reddit
  • Google+
  • Pinterest
  • Pocket
Comments powered by Disqus