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