)]}'
{"/PATCHSET_LEVEL":[{"author":{"_account_id":10058,"name":"Erlon R. Cruz","email":"erlon.rodrigues.cruz@canonical.com","username":"sombrafam"},"change_message_id":"78a1a03f446194ce6cd565174af762165c30ef16","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":5,"id":"9d7ff462_7309f21d","updated":"2026-10-02 15:27:06.000000000","message":"Hi @noonedeadpunk@gmail.com, can you describe the problem being solved here? I understood that we are using dd instead of qemu-img, for this scenario, but I would like to understand the difference (I suppose performance? How much??) between using those two methods. Also can you tell, in a practical scenarios how often this happens?\n\nThe other thing that I noticed for the situation is that, we are downloading the image, raw, and later we are copying it with dd. Since we are not doing any conversion, maybe the best thing to do would be to copy it directly to the volume file, but that would require a broader discussion and s strong argument for your use case and clear benefits gains.","commit_id":"9adf98f6ff33a77b0eadb82d42a4aa28ccb67cd9"}],"cinder/image/image_utils.py":[{"author":{"_account_id":36171,"name":"jayaanand borra","display_name":"jayaanand borra","email":"jayaanand.borra@netapp.com","username":"jayaanan","status":"netapp"},"change_message_id":"422e7fb3f79be03511f352abbb3f976bb2670ef4","unresolved":true,"context_lines":[{"line_number":1137,"context_line":"                % {\u0027fmt\u0027: fmt, \u0027backing_file\u0027: backing_file, })"},{"line_number":1138,"context_line":""},{"line_number":1139,"context_line":"        if fmt \u003d\u003d volume_format:"},{"line_number":1140,"context_line":"            copy_image_to_volume(tmp, dest, data.disk_size, blocksize)"},{"line_number":1141,"context_line":"            return"},{"line_number":1142,"context_line":""},{"line_number":1143,"context_line":"        disk_format \u003d fixup_disk_format(image_meta[\u0027disk_format\u0027])"}],"source_content_type":"text/x-python","patch_set":5,"id":"ea83b0e3_161d7f63","line":1140,"updated":"2026-10-02 16:01:22.000000000","message":"data.disk_size is qemu-img actual-size (allocated bytes), not the guest length. oslo.utils QemuImgInfo maps JSON \"virtual-size\" to virtual_size and \"actual-size\" to disk_size. The qcow2 fixture in test_image_utils.py is virtual_size\u003d1048576 and disk_size\u003d200704.\n\ncopy_image_to_volume() does math.ceil(size / MiB) and volume_utils.copy_volume() passes that to dd as count\u003d\u003cbytes\u003e with iflag\u003dcount_bytes. dd reads that many bytes from offset 0. It does not collect allocated blocks that sit further into the file. check_virtual_size() has already run, so an image that fits the volume still takes this path.\n\nA raw image whose actual-size is smaller than virtual-size (a sparse raw image, and Glance \u0027iso\u0027, which qemu-img reports as raw) is written as a prefix. The tail of an LVM LV or an attached SAN device is left as it was. On RBD, fetch_to_raw() fills a temp file, rbd import uses that file, and _resize() then grows the image to volume.size. The resize does not bring back the bytes dd never read. The same download is what _create_image_cache_volume_entry() clones when the cache is filled.\n\nThe no-qemu return at line 1115 passes image_meta[\u0027size\u0027] into this same helper. This return passes disk_size. If actual-size is absent, disk_size is None and float(None) raises TypeError, which the manager wraps as ImageCopyFailure.","commit_id":"9adf98f6ff33a77b0eadb82d42a4aa28ccb67cd9"}]}