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