Hide Forgot
Description of problem: During a live snapshot (snapshot_blkdev) if the target qcow image already exists it is re-initialized by qemu-kvm overriding any previous configuration. This is a problem for VDSM that is preparing the VM images on the SPM configuring the backing file path (where needed) to a relative path. Version-Release number of selected component (if applicable): qemu-kvm-0.12.1.2-2.221.el6.x86_64 How reproducible: 100% Steps to Reproduce: # qemu-img create -f qcow2 /tmp/vmdisk1.qcow2 4G Formatting '/tmp/vmdisk1.qcow2', fmt=qcow2 size=4294967296 encryption=off cluster_size=65536 # qemu-img create -f qcow2 -b vmdisk1.qcow2 /tmp/vmdisk1-snap1.qcow2 4G Formatting '/tmp/vmdisk1-snap1.qcow2', fmt=qcow2 size=4294967296 backing_file='vmdisk1.qcow2' encryption=off cluster_size=65536 # qemu-img info /tmp/vmdisk1-snap1.qcow2 | grep backing backing file: vmdisk1.qcow2 (actual path: /tmp/vmdisk1.qcow2) # /usr/libexec/qemu-kvm -hda /tmp/vmdisk1.qcow2 -monitor stdio -vnc :5900 QEMU 0.12.1 monitor - type 'help' for more information (qemu) snapshot_blkdev ide0-hd0 /tmp/vmdisk1-snap1.qcow2 Formatting '/tmp/vmdisk1-snap1.qcow2', fmt=qcow2 size=4294967296 backing_file='/tmp/vmdisk1.qcow2' backing_fmt='qcow2' encryption=off cluster_size=65536 (qemu) quit Actual results: The backing file is an absolute path: # qemu-img info /tmp/vmdisk1-snap1.qcow2 | grep backing backing file: /tmp/vmdisk1.qcow2 (actual path: /tmp/vmdisk1.qcow2) Expected results: The backing file must be the relative path configured at the beginning: # qemu-img info /tmp/vmdisk1-snap1.qcow2 | grep backing backing file: vmdisk1.qcow2 (actual path: /tmp/vmdisk1.qcow2) Additional info: An initial patch for this issue was proposed in: http://lists.gnu.org/archive/html/qemu-devel/2011-10/msg00234.html The patch was rejected since it was completely avoiding the re-initialization of the new image. A good compromise would be to re-initialize the new image re-using the same backing file path (when the image is already present and the path is correct). Pseudocode: def snapshot_blkdev(device, new_image_file): img_backfile = get_device_file(device) if image_exists(new_image_file): tmp_backfile = get_image_backing_file(new_image_file) if same_path(img_backfile, tmp_backfile): img_backfile = tmp_backfile else: fail(wrong_backing_file) [...]
According to Paolo libvirt works around it. Federico, can we close the issue?
Test on 267rhev: ------------------- 1. sn1 does not exist w/ absolute-paths: { "execute": "blockdev-snapshot-sync", "arguments": { "device": "drive-virtio-disk0", "snapshot-file": "/root/sn1", "format": "qcow2", "mode": "absolute-paths" } } [root@shu ~]# qemu-img info sn1 image: sn1 file format: qcow2 virtual size: 20G (21474836480 bytes) disk size: 3.4M cluster_size: 65536 backing file: /root/RHEL-Server-6.3-64-virtio.qcow2 (actual path: /root/RHEL-Server-6.3-64-virtio.qcow2) 2. sn1 exists w/ absolute-paths: [root@shu ~]# qemu-img info sn1 image: sn1 file format: qcow2 virtual size: 20G (21474836480 bytes) disk size: 136K cluster_size: 65536 backing file: base (actual path: base) { "execute": "blockdev-snapshot-sync", "arguments": { "device": "drive-virtio-disk0", "snapshot-file": "/root/sn1", "format": "qcow2", "mode": "absolute-paths" } } [root@shu ~]# qemu-img info sn1 image: sn1 file format: qcow2 virtual size: 20G (21474836480 bytes) disk size: 1.5M cluster_size: 65536 backing file: /root/RHEL-Server-6.3-64-virtio.qcow2 (actual path: /root/RHEL-Server-6.3-64-virtio.qcow2) 3. sn1 exists w/ existing: [root@shu ~]# qemu-img info sn1 image: sn1 file format: qcow2 virtual size: 20G (21474836480 bytes) disk size: 136K cluster_size: 65536 backing file: base (actual path: base) { "execute": "blockdev-snapshot-sync", "arguments": { "device": "drive-virtio-disk0", "snapshot-file": "/root/sn1", "format": "qcow2", "mode": "existing" } } [root@shu ~]# qemu-img info sn1 image: sn1 file format: qcow2 virtual size: 20G (21474836480 bytes) disk size: 136K cluster_size: 65536 backing file: base (actual path: base) 4. sn1 exists w/ no-backing-file: [root@shu ~]# qemu-img info sn1 image: sn1 file format: qcow2 virtual size: 20G (21474836480 bytes) disk size: 136K cluster_size: 65536 backing file: base (actual path: base) { "execute": "blockdev-snapshot-sync", "arguments": { "device": "drive-virtio-disk0", "snapshot-file": "/root/sn1", "format": "qcow2", "mode": "no-backing-file" } } [root@shu ~]# qemu-img info sn1 image: sn1 file format: qcow2 virtual size: 20G (21474836480 bytes) disk size: 2.0M cluster_size: 65536 Conclusion: ------------ 1.QMP works fine. 2.HMP has no "no-backing-file" option, i assume the [-n] is the equivalence to existing/absolute-paths: snapshot_blkdev [-n] device [new-image-file] [format] -- initiates a live snapshot of device. If a new image file is specified, the new image file will become the new root image. If format is specified, the snapshot file will be created in that format. Otherwise the snapshot will be internal! (currently unsupported). The default format is qcow2. The -n flag requests QEMU to reuse the image found in new-image-file, instead of recreating it from scratch. 3.above tests base on my understand of the patch, if no more test is needed and HMP issue is not a problem, i am willing to verify this bug.
no-backing-file is used only with mirroring, so snapshot_blkdev does not have it. Testing looks good, thanks!
Technical note added. If any revisions are required, please edit the "Technical Notes" field accordingly. All revisions will be proofread by the Engineering Content Services team. New Contents: No documentation needed
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. http://rhn.redhat.com/errata/RHBA-2012-1017.html