[libvirt] virsh blockcommit tests (w/ libvirt & qemu git)

Hi, Here are a few tests I've done over the weekend to test blockcommit w/ Eric's block commit patches: - https://www.redhat.com/archives/libvir-list/2012-October/msg00091.html - https://www.redhat.com/archives/libvir-list/2012-October/msg00091.html Most of these are from an earlier disscussion from Eric. (1) (POSITIVE-TEST) Commit data from 3 backing image files into 'base' (top to base) using blockcommit, w/ base & resulting overlays as qcow2: actual state: [base] <-- [snap-1] <-- [snap-2] <-- [snap3] <-- [active-layer] desired state: [base] <-- [act-f17-base.qcow2] (resulting in invalidating snap1, snap2, snap3) #======================# [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]# #======================# [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 ~]# #======================# (2) (POSITIVE-TEST) Commit data from 2 backing image files into 'base' (top to base) using blockcommit, w/ base as raw & resulting overlays as qcow2: actual state: [base] <-- [snap-1] <-- [snap-2] <-- [snap3] <-- [active-layer] desired state: [base] <--- [snap-3] <--- [active-layer] (resulting in invalidating snap1, snap2) #======================# [root@moon qemu]# virsh blockcommit --domain test-f17base vda --wait --base /var/lib/libvirt/images/snap1-of-test-f17base.qcow2 --top /var/lib/ libvirt/images/snap3-of-test-f17base.qcow2 --verbose Block Commit: [100 %] Commit complete [root@moon qemu]# #======================# [root@moon qemu]# qemu-img info /var/lib/libvirt/images/snap4-of-test-f17base.qcow2 image: /var/lib/libvirt/images/snap4-of-test-f17base.qcow2 file format: qcow2 virtual size: 1.0G (1073741824 bytes) disk size: 2.3M cluster_size: 65536 backing file: /var/lib/libvirt/images/snap1-of-test-f17base.qcow2 [root@moon qemu]# #======================# (3) (NEGATIVE-TEST) Try blockcommit to a base image which is a 'raw' device - Question: I assume the below is expected, right? We cannot do blockcommit into a NON-qcow2 base file? #======================# [root@moon qemu]# virsh blockcommit --domain raw-base vda --wait --base /export/vmimgs2/raw-base.img --top /var/lib/libvirt/images/snap3-b-raw-base.qcow2 --verbose error: internal error unable to execute QEMU command 'block-commit': Could not open '/export/vmimgs2/raw-base.img' [root@moon qemu]# #======================# (4) (NEGATIVE-TEST) Try blockcommit while the guest is 'offline' #======================# [root@moon qemu]# virsh blockcommit --domain test-f17base vda --wait --base /var/lib/libvirt/images/snap1-of-test-f17-base.qcow2 --top /var/lib/libvirt/images/snap3-of-test-f17-base.qcow2 --verbose error: Requested operation is not valid: domain is not running #======================# (5) (NEGATIVE-TEST) Provide a non-existent file path for base or top(and both) #======================# [root@moon qemu]# virsh blockcommit --domain test-f17base vda --wait --base /var/lib/libvirt/images/snap1-of-test-f17base.qcow2 --top /var/lib/libvirt/images/snap3-of--f17base.qcow2 --verbose error: internal error unable to execute QEMU command 'block-commit': Top image file /var/lib/libvirt/images/snap3-of--f17base.qcow2 not found #======================# [root@moon qemu]# virsh blockcommit --domain test-f17base vda --wait --base /var/lib/libvirt/images/snap1-of--f17base.qcow2 --top /var/lib/libvirt/images/snap3-of-test-f17base.qcow2 --verbose error: internal error unable to execute QEMU command 'block-commit': Base '/var/lib/libvirt/images/snap1-of--f17base.qcow2' not found #======================# [root@moon qemu]# virsh blockcommit --domain test-f17base vda --wait --base /var/lib/libvirt/images/snap1-of--f17base.qcow2 --top /var/lib/libvirt/images/snap3-of--f17base.qcow2 --verbose error: internal error unable to execute QEMU command 'block-commit': Base '/var/lib/libvirt/images/snap1-of--f17base.qcow2' not found #======================# (6) (NEGATIVE-TEST) Provide --base & --top values out of order: #======================# [root@moon qemu]# virsh blockcommit --domain test-f17base vda --wait --base /var/lib/libvirt/images/snap3-of-test-f17base.qcow2 --top /var/lib/libvirt/images/snap1-of-test-f17base.qcow2 --verbose error: internal error unable to execute QEMU command 'block-commit': Base '/var/lib/libvirt/images/snap3-of-test-f17base.qcow2' not found [root@moon qemu]# #======================# NOTES: ----- (a) To quickly check differences between the snapshot image files, I added a text file in each of the snapshot images, just before taking a snapshot. And, when I do a commit operation, I just check w/ 'guestfish' on the relevant disk image if all the expected content reflect. $ 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 / file2.txt file3.txt file4.txt Is there a simpler way? (b) The snapshot-create command I use is something like below: # virsh snapshot-create-as --domain raw-base snap4 snap4-desc --disk-only --diskspec vda,snapshot=external,file=/var/lib/libvirt/images/snap4-b-raw-base.qcow2 --atomic Question: At this point in time, I guess 'snapshot-revert' command is not uhelpful for any practical purposes while dealing with external snapshots,right? - To rephrase, is there a way(in future?),a coherent way to use 'blockcommit'(or blockpull) in conjunction with 'snapshot-revert' command? Yet to test: (1) Use a raw block device(LVM, or direct block /dev/sda1) as backing file (2) Try testing the case of a backing file smaller than the top file being committed ( with data located at various offsets) + In-progress: I'm testing this by adding a 'virsh attach-device' Thanks -- /kashyap