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.
- first, we need to have original image, no matter in what format it is (let say, we have Debian Jessie installed in jessie.raw)
[root@localhost vm2]# qemu-img info jessie.raw
image: jessie.raw
file format: raw
virtual size: 20G (21474836480 bytes)
disk size: 13G
- than, create our testing node, it must be in qcow2 (for example, funny)
[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
- That's all. Now, create VM using libvirt/virt-manager as usually, or just start it:
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