Apply the patches #======================# [kashyap@moon libvirt-k]$ git am -3 ~/libvirt-block-commit-patches/\[libvirt\]\ \[PATCH\ 1_2\]\ blockjob\:\ manage\ qemu\ block-commit\ monitor\ command.eml Applying: blockjob: manage qemu block-commit monitor command [kashyap@moon libvirt-k]$ git am -3 ~/libvirt-block-commit-patches/\[libvirt\]\ \[PATCH\ 2_2\]\ blockjob\:\ wire\ up\ online\ qemu\ block-commit.eml Applying: blockjob: wire up online qemu block-commit [kashyap@moon libvirt-k]$ #======================# [kashyap@moon qemu]$ ./configure --target-list=x86_64-softmmu --disable-werror --enable-debug ; make -j5 [kashyap@moon qemu]$ pwd /home/kashyap/projects/qemu [kashyap@moon qemu]$ #======================# If you've just built libvirt w/ some specific patches, and want #./run ./tools/virsh to use the just built 'libvirtd', then, #======================# [root@moon ~]# killall libvirtd [root@moon ~]# ps -ef | grep libvirtd root 426 362 0 16:39 pts/0 00:00:00 grep --color=auto libvirtd [root@moon ~]# #======================# [kashyap@moon libvirt-k]$ ./run ./tools/virsh define /var/tmp/f17-base.xml Domain f17-base defined from /var/tmp/f17-base.xml [kashyap@moon libvirt-k]$ #======================# [kashyap@moon libvirt-k]$ ps -ef | grep libvirtd kashyap 494 1 4 16:40 ? 00:00:00 /home/kashyap/projects/libvirt-k/daemon/.libs/lt-libvirtd --timeout=30 kashyap 589 11303 0 16:40 pts/15 00:00:00 grep --color=auto libvirtd [kashyap@moon libvirt-k]$ #======================# [kashyap@moon libvirt-k]$ pwd /home/kashyap/projects/libvirt-k [kashyap@moon libvirt-k]$ #======================# [kashyap@moon libvirt-k]$ ./run ./tools/virsh list --all Id Name State ---------------------------------------------------- - f17-base shut off - reg-guest1 shut off #======================# ================================================================================================================ == Test w/ the RPMs installed locally after 'make rpm': == Env: #======================# - Create a guest w/ -- http://kashyapc.fedorapeople.org/virt/jeos-guest-create.bash - - The base-image is 'qcow2' file -- (w/ metadata=preallocation, and fallocate when creating the disk image) - Fedora 18 - Compiled latest qemu-git (as of 6-OCT-2012) - Compiled latest libvirt(w/ a bump in spec-file, so that local rpms can upgrade smoothly) from git (as of 6-OCT-2012), and applied Eric's blockcommit patches. - https://www.redhat.com/archives/libvir-list/2012-October/msg00091.html - https://www.redhat.com/archives/libvir-list/2012-October/msg00091.html - do a 'make rpm', & install 'those' rpms #======================# #======================# [kashyap@moon libvirt-k]$ rpm -q libvirt-daemon-kvm libvirt-daemon-kvm-0.10.2-4.fc18.x86_64 [kashyap@moon libvirt-k]$ #======================# 1/ f17-base has plain Fedora-17 jeos #======================# [root@moon ~]# virsh list Id Name State ---------------------------------------------------- 7 f17-base running [root@moon ~]# #======================# 2/ Check the label of our disk, and qemu-img info of it #======================# [root@moon ~]# virsh domblklist f17-base Target Source ------------------------------------------------ vda /export/vmimgs2/f17-base.qcow2 [root@moon ~]# #======================# [root@moon ~]# qemu-img info /export/vmimgs2/f17-base.qcow2 image: /export/vmimgs2/f17-base.qcow2 file format: qcow2 virtual size: 2.0G (2147483648 bytes) disk size: 2.0G cluster_size: 65536 [root@moon ~]# #======================# 3/ Let's create 3 snapshots 3.1/ Where snap1 was taken, 'after' 'passwd' command has been installed on top of f17-base #======================# [root@moon ~]# virsh snapshot-create-as f17-base snap1 snap1-desc --diskspec vda,file=/export/vmimgs2/snap1-f17-base.qcow2 --disk-only Domain snapshot snap1 created [root@moon ~]# #======================# [root@moon ~]# virsh snapshot-list f17-base Name Creation Time State ------------------------------------------------------------ snap1 2012-10-06 20:37:11 +0530 disk-snapshot [root@moon ~]# #======================# - Now, before taking 'snap2', do a #mkdir /export ; touch /export/file2.txt ; echo foo > /export/file2.txt inside the running OS from, logged in via a serial console #======================# [root@dhcp201-210 ~]# touch /export/file2.txt ; echo foo > /export/file2.txt #======================# [root@moon libvirt]# virsh snapshot-create-as f17-base snap2 snap2-desc --diskspec vda,file=/export/vmimgs2/snap2-f17-base.qcow2 --disk-only Domain snapshot snap2 created [root@moon libvirt]# #======================# NOTE: I had to do a 644 for snap1-f17-base.qcow2 because, it didn't have 'read' permission for 'others' #======================# [root@moon libvirt]# ls -al /export/vmimgs2/ total 2098772 drwxr-xr-x. 2 kashyap kashyap 4096 Oct 6 20:37 . drwxr-xr-x. 34 kashyap kashyap 4096 Oct 6 16:07 .. -rw-r--r--. 1 root root 2148073472 Oct 6 20:36 f17-base.qcow2 -rw-------. 1 root root 1114112 Oct 6 23:27 snap1-f17-base.qcow2 [root@moon libvirt]# chmod 644 /export/vmimgs2/snap1-f17-base.qcow2 [root@moon libvirt]# #======================# #======================# [kashyap@moon libvirt-k]$ virt-cat -a /export/vmimgs2/snap1-f17-base.qcow2 /export/file2.txt foo [kashyap@moon libvirt-k]$ #======================# [kashyap@moon libvirt-k]$ virt-cat -a /export/vmimgs2/snap2-f17-base.qcow2 /export/file2.txt foo #======================# [kashyap@moon libvirt-k]$ virt-cat -a /export/vmimgs2/f17-base.qcow2 /export/file2.txt libguestfs: error: download: /export/file2.txt: No such file or directory [kashyap@moon libvirt-k]$ #======================# What just happened? -- We created files in the running OS -- while snap1.qcow2 was the 'active-layer', so, once we took 'snap2', the changes(the dir/file adds) are visible in both snap1.qcow2(because this was the 'active layer' when we were creating the dir/files.) & snap2.qcow2(because this is the _snapshot_ of the contents of 'active-layer' once the files were written 'to' it.) 3.2/ Now, before taking 'snap3', do a touch /export/file3.txt ; echo foo > /export/file3.txt inside the running OS from, logged in via a serial console #======================# [root@dhcp201-210 ~]# touch /export/file3.txt ; echo foo > /export/file3.txt #======================# [root@moon libvirt]# virsh snapshot-create-as f17-base snap3 snap3-desc --diskspec vda,file=/export/vmimgs2/snap3-f17-base.qcow2 --disk-only Domain snapshot snap3 created [root@moon libvirt]# #======================# #======================# [kashyap@moon libvirt-k]$ virt-cat -a /export/vmimgs2/snap3-f17-base.qcow2 /export/file3.txt foo [kashyap@moon libvirt-k]$ virt-cat -a /export/vmimgs2/snap2-f17-base.qcow2 /export/file3.txt foo [kashyap@moon libvirt-k]$ virt-cat -a /export/vmimgs2/snap1-f17-base.qcow2 /export/file3.txt libguestfs: error: download: /export/file3.txt: No such file or directory [kashyap@moon libvirt-k]$ #======================# It can be seen clearly that snap3-f17-base.qcow2 is the active-layer #======================# [root@moon libvirt]# virsh domblklist f17-base Target Source ------------------------------------------------ vda /export/vmimgs2/snap3-f17-base.qcow2 [root@moon libvirt]# #======================# 3.3/ Now, before taking 'snap4'/active-layer, do a # touch /export/file4.txt ; echo foo > /export/file4.txt inside the running OS from, logged in via a serial console #======================# [root@moon libvirt]# virsh snapshot-create-as f17-base snap4 snap4-desc --diskspec vda,file=/export/vmimgs2/act-f17-base.qcow2 --disk-only Domain snapshot snap4 created [root@moon libvirt]# #======================# Let's see in which files 'file4' is visible:(ideally active-layer & snap3) #======================# [kashyap@moon libvirt-k]$ virt-cat -a /export/vmimgs2/act-f17-base.qcow2 /export/file4.txt foo [kashyap@moon libvirt-k]$ #======================# [kashyap@moon libvirt-k]$ virt-cat -a /export/vmimgs2/snap3-f17-base.qcow2 /export/file4.txt foo [kashyap@moon libvirt-k]$ #======================# [kashyap@moon libvirt-k]$ virt-cat -a /export/vmimgs2/snap2-f17-base.qcow2 /export/file4.txt libguestfs: error: download: /export/file4.txt: No such file or directory [kashyap@moon libvirt-k]$ #======================# snapshot-list #======================# [root@moon libvirt]# virsh snapshot-list f17-base Name Creation Time State ------------------------------------------------------------ snap1 2012-10-06 20:37:11 +0530 disk-snapshot snap2 2012-10-06 23:56:02 +0530 disk-snapshot snap3 2012-10-07 00:10:39 +0530 disk-snapshot snap4 2012-10-07 00:49:25 +0530 disk-snapshot [root@moon libvirt]# #======================# ==> Backing File sequence BEFORE 'blockcommit <== #======================# [root@moon libvirt]# qemu-img info /export/vmimgs2/f17-base.qcow2 image: /export/vmimgs2/f17-base.qcow2 file format: qcow2 virtual size: 2.0G (2147483648 bytes) disk size: 2.0G cluster_size: 65536 #======================# [root@moon libvirt]# qemu-img info /export/vmimgs2/snap1-f17-base.qcow2 image: /export/vmimgs2/snap1-f17-base.qcow2 file format: qcow2 virtual size: 2.0G (2147483648 bytes) disk size: 1.8M cluster_size: 65536 backing file: /export/vmimgs2/f17-base.qcow2 [root@moon libvirt]# #======================# [root@moon libvirt]# qemu-img info /export/vmimgs2/snap2-f17-base.qcow2 image: /export/vmimgs2/snap2-f17-base.qcow2 file format: qcow2 virtual size: 2.0G (2147483648 bytes) disk size: 1.1M cluster_size: 65536 backing file: /export/vmimgs2/snap1-f17-base.qcow2 [root@moon libvirt]# #======================# [root@moon libvirt]# qemu-img info /export/vmimgs2/snap3-f17-base.qcow2 image: /export/vmimgs2/snap3-f17-base.qcow2 file format: qcow2 virtual size: 2.0G (2147483648 bytes) disk size: 712K cluster_size: 65536 backing file: /export/vmimgs2/snap2-f17-base.qcow2 [root@moon libvirt]# #======================# [root@moon libvirt]# qemu-img info /export/vmimgs2/act-f17-base.qcow2 image: /export/vmimgs2/act-f17-base.qcow2 file format: qcow2 virtual size: 2.0G (2147483648 bytes) disk size: 200K cluster_size: 65536 backing file: /export/vmimgs2/snap3-f17-base.qcow2 [root@moon libvirt]# #======================# The CURRENT 'active' layer is act-f17-base.qcow2 #======================# [root@moon libvirt]# virsh domblklist f17-base Target Source ------------------------------------------------ vda /export/vmimgs2/act-f17-base.qcow2 [root@moon libvirt]# #======================# # BEFORE 'blockcommit' #======================# [kashyap@moon qemu]$ guestfish --ro -i -a /export/vmimgs2/f17-base.qcow2 Welcome to guestfish, the libguestfs filesystem interactive shell for editing virtual machine filesystems. Type: 'help' for help on commands 'man' to read the manual 'quit' to quit the shell Operating system: Fedora release 17 (Beefy Miracle) /dev/sda1 mounted on / > ls /export libguestfs: error: ls0: opendir: /export: No such file or directory > #======================# ==> Try 'blockcommit' now: <== Test: Merge data from 3 backing image files into 'base' (top to base) using blockcommit This is the current state: [base] <-- [snap-1] <-- [snap-2] <-- [snap3] <-- [act-f17-base.qcow2] Let's flatten the above image chain into the below -- once the blockcommit operation is completed, snap1, snap2, snap3 are merged into the 'base' image (and thus, rightfully invalidating snap1, snap2 & snap3)]. And, the [act-f17-base.qcow2] should now point its backing file to [base] (instead of [snap3-base.qcow2] [base] <-- [act-f17-base.qcow2] Let's run the actual 'blockcommit' command: #======================# [root@moon libvirt]# virsh blockcommit --domain f17-base vda --wait --base /export/vmimgs2/f17-base.qcow2 --top /export/vmimgs2/snap3-f17-base.qcow2 --verbose Block Commit: [100 %] Commit complete [root@moon libvirt]# #======================# RESULT: ------- Now, let's check the backing file of [act-f17-base.qcow2], it is now 'f17-base' instead of 'snap3' , which is a SUCCESS (for comparision, check the backing file of [act-f17-base.qcow2] _before_ blockcommit from previous commands) #======================# [root@moon ~]# qemu-img info /export/vmimgs2/act-f17-base.qcow2 image: /export/vmimgs2/act-f17-base.qcow2 file format: qcow2 virtual size: 2.0G (2147483648 bytes) disk size: 648K cluster_size: 65536 backing file: /export/vmimgs2/f17-base.qcow2 [root@moon ~]# #======================# - So, the backing-chain is succesfully FLATTENED to [f17-base.qcow2] <-- [act-f17-base.qcow2] . All of it, while the guest is UP and RUNNING. Also, let's check the contents of original backing file. Now, it's quite clear that content from snap1, snap2 and snap3 are now merged into the base image. #======================# [kashyap@moon qemu]$ guestfish --ro -i -a /export/vmimgs2/f17-base.qcow2 Welcome to guestfish, the libguestfs filesystem interactive shell for editing virtual machine filesystems. Type: 'help' for help on commands 'man' to read the manual 'quit' to quit the shell Operating system: Fedora release 17 (Beefy Miracle) /dev/sda1 mounted on / > ls /export file2.txt file3.txt file4.txt > #======================# Couple of questions: [1] Now, the snapshot-list is here (it's invalid, obviously and should be updated somehow. Probably, using '--delete' can be helpful here?) #======================# - [root@moon ~]# virsh snapshot-list f17-base Name Creation Time State ------------------------------------------------------------ snap1 2012-10-06 20:37:11 +0530 disk-snapshot snap2 2012-10-06 23:56:02 +0530 disk-snapshot snap3 2012-10-07 00:10:39 +0530 disk-snapshot snap4 2012-10-07 00:49:25 +0530 disk-snapshot [root@moon ~]# virsh snapshot-list f17-base --tree snap1 | +- snap2 | +- snap3 | +- snap4 [root@moon ~]# #======================# (OR is the above valid because, it's just reflecting the IMAGE-CHAIN, and not SNAPSHOT-CHAIN? ) [2] What about snap1, snap2, snap3 files? Can they be left behind, can they be used as 'backing' files for different images? (since I can still boot into them using 'qemu-kvm -smp 2 -m 2048 /export/vmimgs2/snap3-f17-base.qcow2 -nographic' just fine [2.1] Clairification needed: "the fact that you did a commit may make it harder to use any snapshots you created via 'virsh snapshot-create --disk-only' to create the long chain in the first place." -- yeah, what can we do / how can we 'clean-up' the 'snapshot- [2.3] I guess 'snapshot-revert' is useless in this case yet. [3] Permission issues -- The new snapshot file is created with 600 permissions. I had to chmod 644 /export/vmimgs2/snap1-f17-base.qcow2 , so that I can use guestfish to read the disk images. Or is it for 'security' reasons? [4] Question for 'snapshot-create-as' does the --diskspec takes 'snapshot=external' by default? when the 'snapshot' attribute is not specified?