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

Kashyap Chamarthy kchamart at redhat.com
Tue Oct 9 05:12:15 UTC 2012


On 10/09/2012 08:01 AM, Eric Blake wrote:
> 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 

OK, I'll bother him to see if he has more insights there.

> (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).

Yeah, noticed your feedback on the QAPI thread for block commit command on qemu-devel.

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

ah, noticed. at the moment, I'm just trying to get a working demonstration :) so, testing
everything with absolute names.

> 
>> (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
> 
> Not implemented yet, so this failure is okay for now.

fair enough.

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

I thought using 'guestfish' was simpler when demonstrating to someone.
:) I recall you suggested a similar 'dd' operation while testing hot-plugging devices &
doing dd inside the guest & then doing commit operations.

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

Thanks Eric, that's useful detail. And yes, I'm keeping an eye on the list for patches,
will test as soon as they land.

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


-- 
/kashyap




More information about the libvir-list mailing list