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@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 / > >> <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 -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list