[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

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

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 redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

Attachment: signature.asc
Description: OpenPGP digital signature

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]