Re: [Qemu-devel] [Qemu-block] RFC: use case for adding QMP, block jobs & multiple exports to qemu-nbd ?

[Max Reitz <mreitz@redhat.com>]

[-- Attachment #1: Type: text/plain, Size: 2252 bytes --]

On 2017-11-02 13:02, Daniel P. Berrange wrote:
[...]
> One alternative approach to doing this would be to suggest that we should
> instead just spawn qemu-system-x86_64 with '--machine none' and use that
> as a replacement for qemu-nbd, since it already has a built-in NBD server
> which can do many exports at once and arbitrary block jobs.

As far as I know, we had wanted to add QMP support to qemu-nbd maybe one
or two years ago, but nobody ever did it.

I've had some discussions about this with Markus and Kevin at KVM Forum.
 They appeared to strongly prefer this approach.  I agree with them that
design-wise, a qemu with no machine at all (and not even -M none) and
early QMP is the way we want to go anyway, and then this would be the
correct tool to use.

> I'm concerned that this could end up being a be a game of whack-a-mole
> though, constantly trying to cut out/down all the bits of system emulation
> in the machine emulators to get its resource overhead to match the low
> overhead of standalone qemu-nbd.

However, I personally share your concern.  Especially, I think that
getting to a point where we can have no machine at all and early QMP
will take much longer than just adding QMP to qemu-nbd -- or adding a
qmp command to qemu-img (because you can add NBD exports through QMP, so
qemu-nbd's hardcoded focus on NBD exports seems kind of weird then)[1].

I'm very much torn here.  There are two approaches: Stripping fat qemu
down, or fattening lean qemu-img (?) up.  The latter is very simple.
The former is what we want anyway.

Markus says it's not too hard to strip down qemu.  If that is true,
there is no point in fattening qemu-img now.  I personally am not
convinced at all, but he knows the state of that project much better
than me, so I cannot reasonably disagree.

So my mail is more of a CC to Markus and Kevin -- but I think both are
on PTO right now.

I guess the main question is: If someone were to introduce a qemu-img
QMP subcommand -- would it be accepted? :-)

Max


[1] Also, adding QMP should trivially add block jobs and multiple
exports to whatever tool we are talking about (in fact, qemu-img already
does perform the mirror block job for committing).


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 512 bytes --]