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(a)redhat.com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
Attachments:
- signature.asc (application/pgp-signature — 617 bytes)