[libvirt-users] Is virsh blockcommit supported? Thanks a lot

[Eric Blake]

[dropping libvir-list - this is a usage question, not a development
question]

On 09/02/2013 11:29 PM, Guozhonghua wrote:
> I had test the command virsh blockcommit, but it failed, with the libvirt version 1.1.0, and qemu version 1.6.0.
> Is this feature being developing? Thanks

The feature is supported, but you have to use it correctly.  In
particular, your backing chain MUST label the backing format of all
backing files in the image metadata, or you must set
'allow_disk_format_probing' to 1 in /etc/libvirt/qemu.conf (be aware
that doing so is a security risk if you use any raw images and have
untrustworthy guests).

> root at cvk-31:/vms/images# virsh blockcommit Vmtest /vms/images/Vmtest1 --base /vms/image
> s/Vmtest1_base --top /vms/images/Vmtest1_base_1 --wait --verbose ;echo $?
> error: invalid argument: top '/vms/images/Vmtest1_base_1' in chain for '/vms/images/Vmtest1' has no backing file

Your command line looks correct, so I suspect that what happened is that
you failed to mark the format of Vmtest1_base_1 in Vmtest1, which means
that libvirt is treating it as raw rather than qcow2; and raw files do
not have backing images.

I _really_ need to add a command to virsh that will show the entire
backing chain, according to libvirt, as it would immensely help in
debugging such issues.

> root at cvk-31:/vms/images# qemu-img info --backing-chain /vms/images/Vmtest1
> image: /vms/images/Vmtest1
> file format: qcow2
> virtual size: 9.8G (10485760000 bytes)
> disk size: 140M
> cluster_size: 2097152
> backing file: /vms/images/Vmtest1_base_1

Yep, my suspicion is confirmed - libvirt is treating Vmtest1_base_1 as
raw instead of qcow2, because Vmtest1 has missing metadata.  When done
PROPERLY, this block would ALSO have the following line:

backing file format: qcow2

How are you creating your backing chain?  By hand with 'qemu-img
create'?  If so, be sure you pass the '-o backing_fmt=qcow2' option for
any file that wraps another qcow2 file.

> This e-mail and its attachments contain confidential information from H3C, which is

This list is publicly archived, rendering such a disclaimer
unenforceable.  It is considered poor netiquette to send from an
employer's account if they tack on such legalese, and you may want to
consider using a personal account instead.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 621 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/libvirt-users/attachments/20130903/5b88f66d/attachment.sig>