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

[Kashyap Chamarthy]

On 10/08/2012 03:24 PM, Kashyap Chamarthy wrote:
> 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?), to use 'blockcommit'(or
> blockpull) in conjunction with 'snapshot-revert' command?

Just to note, I understand that, at the moment, to use revert, shutting the guest off, do
qemu-img(revert?) manipulation (and later do: virsh edit $dom ; virsh snapshot-edit $dom
snapname or virsh snapshot-delete --metadata, so tha libvirt reflects the new reality) .
Is it right?

> 
> 
> 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