[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@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@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
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ libvirt-users mailing list libvirt-users@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvirt-users
