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