qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [Qemu-block] Request for clarification on qemu-img conv


From: Richard W.M. Jones
Subject: Re: [Qemu-devel] [Qemu-block] Request for clarification on qemu-img convert behavior zeroing target host_device
Date: Fri, 14 Dec 2018 13:10:11 +0000
User-agent: Mutt/1.5.21 (2010-09-15)

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]