Re: [Qemu-devel] [Qemu-block] [PATCH RFC] qemu-io: Prefer stderr for error messages

[Eric Blake]

On 12/13/18 11:44 AM, Nir Soffer wrote:

> > The things is, qemu-io was never meant to be used by other
> > applications that need to process the results, it's a tool for testing
> > and debugging. If we had meant it to be used by other programs, we would
> > have given it a machine-friendly interface.
> >
> > The machine-friendly interface to the QEMU block layer is qemu-nbd.
>
> nbd is awesome, but much more complicated to use for testing. You need to:
>
> 1. start qemu-nbd
> 2. wait until it is ready
> 3. use nbd client (we have one now), or connect the qemu-nbd to /dev/ndbX,
> which on
>    Fedora 28 leaves stale /dev/nbdX devices after disconnection
>    (I reported this few month ago here).

Is that true even when you use 'qemu-nbd -d /dev/nbdX' after you are done?

> 4. finally disconnect and wait until qemu-nbd terminates
>
> qemu-io is so much easier to use, we need to make it more machine friendly.

Or rather, if there is something that a machine needs to drive, we 
should figure out if qemu-img can be taught to do it instead of hacking 
around the issue with qemu-io.  When it comes to extracting portions of 
a disk, qemu-img convert coupled with the raw driver's offset/length 
gets us quite a bit of functionality - even if it's clunky to come up 
with the command line, it can be programmed, and doesn't suffer from 
having to post-process arbitrary qemu-io output changes.

> > The human interface of qemu-io is honestly just not the right tool for
> > the job, and adding one-off tweaks to make it a little bit less horrible
> > to use for machines isn't the right approach because it's still not a
> > proper machine protocol.
>
> Add --output json?

Who's volunteering to do it? I've got too much else going on to spend 
time on such a project.

--
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3266
Virtualization:  qemu.org | libvirt.org