1] What is a QCOW2 file? + A versatile disk image format which support smaller disk images, interesting features like snapshots -- this format stores only the _actual_ size occupied by the VM(in raw, entire disk is allocated) + In essence, the COW(copy on write) gives you an ability to create a base-image, and create several 'disposable' copy-on-write disk images. VERY useful in development & test environment + Say, I've create a minimal F17 virtual machine (and made a copy of the disk image, so that we can use it as our 'base' image -- which has a freshly installed Fedora-17 OS on it #-----------------------------------------------# [root@localhost ~]# qemu-img info /home/kashyap/vmimages/base-f17.qcow2 image: /home/kashyap/vmimages/base-f17.qcow2 file format: qcow2 virtual size: 5.0G (5368709120 bytes) disk size: 5.0G cluster_size: 65536 [root@localhost ~]# #-----------------------------------------------# To see if it's working, we can do a quick check: #-----------------------------------------------# # qemu-kvm -enable-kvm -m 1024 base-f17.qcow2 -nographic #-----------------------------------------------# 2] Backing file + Our above base-f17.qcow2 is the backing file(also called as template base-image). Let's see 'how' it becomes a backing-file by seeing it in action: + Now, let’s make use of the above F17 base image and try to instantiate 2 more Fedora 17 virtual machines, quickly. #-----------------------------------------------# [root@localhost qemu]# qemu-img create -b /home/kashyap/vmimages/base-f17.qcow2 -f qcow2 /home/kashyap/vmimages/f17vm4-with-b.qcow2 Formatting '/home/kashyap/vmimages/f15vm3-with-b.qcow2', fmt=qcow2 size=5368709120 backing_file='/home/kashyap/vmimages/base-f17.qcow2' encryption=off cluster_size=65536 lazy_refcounts=off [root@localhost qemu]# #-----------------------------------------------# NOTE: From this point on, your base-image will be 'read-only' and any 'writes'/changes will go into the 'new' image while preserving the state of your backing file. Let's see the size of our 'new' qcow2 file #-----------------------------------------------# [root@localhost ~]# ls -lash /home/kashyap/vmimages/f17vm4-with-b.qcow2 15M -rw-r--r--. 1 root root 15M Oct 4 06:30 /home/kashyap/vmimages/f17vm4-with-b.qcow2 [root@localhost ~]# #-----------------------------------------------# We can verify or boot into this guest in two ways: #-----------------------------------------------# [root@localhost ~]# qemu-kvm -enable-kvm -m 1024 f17vm4-with-b.qcow2 -nographic #-----------------------------------------------# More, traditionally/officially, we should define an XML for it, and use 'virsh' to take advantage of management capabilities: So, edit the xml file, and update the name, uuid, disk path, mac-address attributes inside the xml and define it #-----------------------------------------------# [root@localhost ~]# vim /etc/libvirt/qemu/f17vm4-with-b.xml #-----------------------------------------------# [root@localhost qemu]# virsh define f17vm4-with-b.xml #-----------------------------------------------# [root@localhost qemu]# virsh start f17vm4-with-b --console #-----------------------------------------------# - We can instantiate another(or any number of them) VM(f17vm5-with-b) by using the same backing file (base-f17.qcow2) 3] Thin Provisiong: ------------------- It's just an optimized way of managing your existing storage. So, now, we have two 'thin-provisioned' guests, both using a disk with a chain of depth 2: - guest vm3 uses base-f17 <- f17vm5-with-b - guest vm4 uses base-f17 <- f17vm4-with-b [root@localhost ~]# qemu-img info f17vm5-with-b.qcow2 [root@localhost ~]# qemu-img info f17vm4-with-b.qcow2 4/ Conclusions: --------------- - A single base-image(read-only) can serve as a backing file for multiple clone-images. ) - You can optimize your disk storage, by having a single base-image (with Fedora 5/ Other: --------- - What if I want to create 'new' guests with F17 OS updates, but 'still' using the original base-image(which has plain Fedora-17 on it) - We can do that via a chain : [base-f17] <- [base-f17-new] <- newguest - (where base-f17-new has the OS updates, and the 'newguest' has the further changes beyond there. So that we can now have multiple new guests(with OS updates, all pulling off from the same 'base-f17-new' - Ground-rule to remember: Once we have a chain with a depth of more than 1, the ONLY file we can safely edit is the 'leaf' image in the chain - We can also create a 'diff' of images: -- userful when you have copied or cloned a guest, and you want to get back to a thin image on top of a template or base image References: [1] https://kashyapc.wordpress.com/ [2] http://kashyapc.fedorapeople.org/virt/img-diff-test.txt