On 10/08/2012 03:54 AM, Kashyap Chamarthy wrote: > > (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? It should work. It may be that you have found a problem in Jeff's qemu patches (I certainly found some over the weekend, where his patches currently mis-handle any backing file chain that used relative rather than absolute file names in the qcow2 file). By the way, using 'virsh snapshot-create[-as]' if you haven't already pre-created the chain gives absolute path names, so the only way to trigger the bugs with relative path names in the backing file is to use qemu-img instead of virsh to create the chain. > (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 Not implemented yet, so this failure is okay for now. > > (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? That's actually a rather decent way to do it! I had been messing with things like 'dd' in the guest to the disk treated as a raw block device (no file system on it), which was a bit tougher to handle. > > (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? Yep, once you start using the 'commit' operation, the snapshots that you took to create the backing chain have more or less been invalidated. Someday, I'd like to tie the code together, so that doing a commit that interferes with a snapshot will fail unless you pass a flag that acknowledges that snapshots will be lost, and which automatically cleans up any impacted snapshot (rewriting the snapshot metadata or deleting it altogether). There's also a need to have 'snapshot-revert' work for disk-only snapshots; Peter Krempa has been helping me work on some of that code, so look for some patches to hit the list later this month. > - To rephrase, is there a way(in future?),a coherent way to use 'blockcommit'(or > blockpull) in conjunction with 'snapshot-revert' command? Hopefully we get there, as we gain more experience about which sequences of operations are the most useful and need to be made easier to manage in libvirt. > > > 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 > -- Eric Blake eblake@xxxxxxxxxx +1-919-301-3266 Libvirt virtualization library http://libvirt.org
Attachment:
signature.asc
Description: OpenPGP digital signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list