Re: [Qemu-devel] [Qemu-block] Request for clarification on qemu-img convert behavior zeroing target host_device

[De Backer, Fred (Nokia - BE/Antwerp)]

>Of course, we should also think about the other problem you mentioned, related 
>to copying a smaller image to a larger block device. Does this require zeroing 
>the parts after the image or should we leave them alone?
>
>I'd tend to say that since you're passing the whole block device as a target 
>to 'qemu-img convert', and the whole block device will be visible to a guest 
>run with the same block device configuration, we should indeed zero out the 
>whole device. But then we would declare the F27 behaviour buggy and this case 
>would stay slow (it would become slightly faster because we avoid the double 
>writes, but we wouldn't save the writes to the unused space).

As long as it's outside the region of the source image I think you can leave it 
alone. Similar to deleting a file on a disk also doesn't zero out the sectors 
that were used to store that file before.

>Or we could just refuse to convert if source and target aren't the same size. 
>Then you would have to use a raw filter driver to select a part from the 
>target image with the offset/size options. But this would break backwards 
>compatibility, and its use is not very intuitive either.

Going that path would certainly break the way Openstack Ironic project uses 
qemu-img via the ironic-python-agent to image baremetal servers. And I can 
imagine there are other cases out there using qemu-img to write out disk images 
to blockdevices.

Fred