On Fri, Dec 14, 2018 at 12:52:34PM +0000, De Backer, Fred (Nokia - BE/Antwerp) wrote: > >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.
It's really nothing at all like that case. Kevin is right the only sensible thing to do is to zero-extend the image to the full size of the target (in the absence of the user instructing qemu-img to do something else). Rich. > >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 -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into KVM guests. http://libguestfs.org/virt-v2v