Re: [PATCH for 5.2 1/1] qemu-io: add -V flag for read sub-command

[Vladimir Sementsov-Ogievskiy]

10.08.2020 17:20, Eric Blake wrote:
> On 8/10/20 7:35 AM, Denis V. Lunev wrote:
> > The problem this patch is trying to address is libguestfs behavior on the
> > appliance startup. It starts supporting to use root=UUID definition in
> > the kernel command line of its root filesystem using
> >      file --  /usr/lib64/guestfs/appliance/root
> > This works fine with RAW image, but we are using QCOW2 as a storage to
> > save a bit of file space and in this case we get
> >      QEMU QCOW Image (v3), 1610612736 bytes
> > instead of UUID of the root filesystem.
> >
> > The solution is very simple - we should dump first 256k of the image file
> > like the follows
> >      qemu-io -c "read -V 0 256k" appliance | file -
> > which will provide correct result for all possible types of the appliance
> > storage.
>
> Is 'appliance' a qcow2 file?  If so, another way to accomplish this could 
> include:
>
> nbdkit streaming --run 'qemu-img convert --image-opts 
> driver=raw,size=256,file.driver=qcow2,file.file.driver=file,file.file.filename=appliance 
> "$uri"' | file -

This adds a dependency on nbdkit streaming plugin, not installed by default in 
our RH-based distributive. Probably the simplest thing is just create a 
temporary file for qemu-img convert (or dd) target, and then call file command 
on it.

> which says to use qemu-img to open a length-limited view of the file, and 
> stream the entire thing to an NBD server, where nbdkit then provides a way to 
> convert that to a pipeline to feed into file (since qemu's NBD server doesn't 
> directly like writing into a pipe).
>
> I'm also wondering if the 'nbdcopy' program (not yet released in a stable 
> version, but available in libnbd.git) could be put to use on this front, with 
> some way to quickly combine it with qemu-nbd serving appliance.qcow2.
>
> > Unfortunately, additional option for qemu-io is the only and the simplest
> > solution as '-v' creates very specific output, which requires to be
> > parsed. 'qemu-img dd of=/dev/stdout' does not work and the fix would be
> > much more intrusive.
>
> 'qemu-img dd' _should_ be merely syntactic sugar for 'qemu-img convert', but it 
> isn't yet.  Until we rectify that feature parity (there are things that dd 
> can't do like better output control and skipping, and there are things that 
> convert can't do like length limiting and offset selection), hacking up 
> 'qemu-io' (which is for debugging use only) is a tolerable short-term solution; 
> but qemu-io was NEVER intended for stable use cases.  If adding this makes 
> debugging qemu easier, then go for it; but if the real problem is that qemu-img 
> is missing functionality, we should instead be focusing on fixing qemu-img.

Thanks for clarifying this!

If we are going to improve qemu-img at some point, I'm not sure that convert or 
dd is correct places to do it, as they want target to be a block node. But how 
to create a block-node on top of /dev/stdout? Detect it and behave another way 
in img_dd function? Or may be better create another command qemu-img dump, for 
dumping the contents to stdout?

--
Best regards,
Vladimir