Re: [PATCH v2 1/1] qemu-img: do not erase destination file in qemu-img dd command

[Eric Blake]

On Tue, Oct 31, 2023 at 03:33:52PM +0100, Hanna Czenczek wrote:
> Personally, and honestly, I see no actual use for qemu-img dd at all,
> because we’re trying to mimic a subset of an interface of a rather complex
> program that has been designed to do what it does. We can only fail at
> that.  Personally, whenever I need dd functionality, I use
> qemu-storage-daemon’s fuse export, and then use the actual dd program on
> top.  Alternatively, qemu-img convert is our native interface;
> unfortunately, its feature set is lacking when compared to qemu-img dd, but
> I think it would be better to improve that rather than working on qemu-img
> dd.

I also agree that 'qemu-img dd' is not where we should focus; we have
a two-way feature gap (dd can do things convert can't, and convert can
do things dd can't), where the IDEAL world would be convert can do
everything and then dd is then a thin wrapper that calls into convert
under the hood.  Otherwise, we will forever be chasing bugs between
two similar but divergent implementations, and the one that gets more
testing (convert) will be the only one that gets timely fixes.

I should have objected much harder when 'qemu-img dd' was first
proposed.  Oh well.

Here's at least one prior discussion on the mailing list, in 2016(!),
where we proposed enhancing qemu-img dd to add at least seek=; but the
patch was never accepted.  I know there are other bugs lurking in dd
(being unable to choose different offsets for the input and output
file, via skip= vs. seek=, makes it hard to use compared to regular
dd); which backs up my claim that qemu-img dd is low priority.

https://lists.gnu.org/archive/html/qemu-devel/2016-08/msg03896.html

And to some extent, with some convoluted JSON or --image-opts (I
recommend trying it with qemu-storage-daemon, rather than directly in
qemu-img), you CAN open subsets of any other image by layering a raw
BDS with offset/size clamps on top of anything else.  It's just that
we don't have many written examples stating how to do that, although
we DO have such an example in the qemu-nbd documentation:

| Start a long-running server listening with encryption on port 10810,
| and allow clients with a specific X.509 certificate to connect to
| a 1 megabyte subset of a raw file, using the export name 'subset':
| 
| ::
| 
|   qemu-nbd \
|     --object tls-creds-x509,id=tls0,endpoint=server,dir=/path/to/qemutls \
|     --object 'authz-simple,id=auth0,identity=CN=laptop.example.com,,\
|               O=Example Org,,L=London,,ST=London,,C=GB' \
|     --tls-creds tls0 --tls-authz auth0 \
|     -t -x subset -p 10810 \
|     --image-opts 
driver=raw,offset=1M,size=1M,file.driver=file,file.filename=file.raw

> 
> Summary: If we do this under a new conv=notrunc, fine with me.  I just don’t
> think qemu-img dd is something that should be used at all.

I'm not even sure it is worth adding anything to qemu-img dd.  At this
point, that would just be increasing its technical debt; we're better
off putting lipstick on a pig.

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.
Virtualization:  qemu.org | libguestfs.org