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
