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

[Kashyap Chamarthy]

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 at 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 at moon libvirt]#
#======================#
[root at 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 at 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 at 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 at moon qemu]#
#======================#
[root at 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 at 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 at 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 at moon qemu]#
#======================#



(4) (NEGATIVE-TEST) Try blockcommit while the guest is 'offline'
#======================#
[root at 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 at 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 at 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 at 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 at 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 at 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 /

><fs> ls /export
file2.txt
file3.txt
file4.txt
><fs>

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