Re: Clarification regarding new qemu-img convert --target-is-zero flag

[Sam Eiderman]

Hi,

My target format is a Persistent Disk on GCP.
https://cloud.google.com/persistent-disk

And my use case is converting VMDKs to PDs so I'm just using qemu-img
for the conversion (not using qemu as a hypervisor).

Luckily PDs are zeroed out when allocated but I was asking to
understand the restrictions of qemu-img convert.

It could be useful for qemu-img convert to not zero out the disk, but
do write allocated zeroes, I'm imagining cloud scenarios where instead
of virtual disks the customer receives an attached physical SSD device
that is not zeroed out beforehand (only encryption key changed, for
privacy/security sake) so reads will return garbage.

Sam

On Wed, Jun 10, 2020 at 9:16 AM Vladimir Sementsov-Ogievskiy
<vsementsov@virtuozzo.com> wrote:
>
> Hi Sam!
>
> 10.06.2020 08:28, Sam Eiderman wrote:
> > Hi,
> >
> > 168468fe19c8 ("qemu-img: Add --target-is-zero to convert") has added a
> > nice functionality for cloud scenarios:
> >
> > * Create a virtual disk
>
> What is the format of your target?
>
> > * Convert a sparse image (qcow2, vmdk) to the virtual disk using
> > --target-is-zero
> > * Use the virtual disk
> >
> > This saves many unnecessary writes - a qcow2 with 1MB of allocated
> > data but with 100GB virtual size will be converted efficiently.
> >
> > However, does this pose a problem if the virtual disk is not zero 
> > initialized?
> >
> > Theoretically - if all unallocated blocks contain garbage - this
> > shouldn't matter, however what about allocated blocks of zero? Will
> > convert skip copying allocated zero blocks in the source image to the
> > target since it assumes that the target is zeroed out first thing?
> >
>
> Yes, the feature is only for really zero-initialized target, it will skip 
> "allocated" zeroes as well.
>
> What you want - copying only allocated blocks of backing-supporting format - 
> looks like "top" mode of
> mirror and backup block jobs. Didn't you considered using qemu itself (in 
> stopped mode, i.e. cpus are
> not running) or new qemu-storage-daemon instead of qemu-img? With this 
> approach you'll have the whole
> power of QMP commands to manage block-layer, including block-jobs.
>
> --
> Best regards,
> Vladimir