qemu-block
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-block] RFC: use case for adding QMP, block jobs & multiple exp


From: Stefan Hajnoczi
Subject: Re: [Qemu-block] RFC: use case for adding QMP, block jobs & multiple exports to qemu-nbd ?
Date: Fri, 3 Nov 2017 09:59:41 +0000
User-agent: Mutt/1.9.1 (2017-09-22)

On Thu, Nov 02, 2017 at 10:38:16PM +0100, Max Reitz wrote:
> 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.

BenoƮt Canet worked on this in 2014:
https://lists.gnu.org/archive/html/qemu-devel/2014-08/msg02533.html

> 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? :-)

I'm in favor of the -machine none approach since it seems inevitable
that both qemu-img and qemu-nbd will become QMP interfaces.  qemu-io has
already become a monitor interface...

> [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: signature.asc
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]