[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [multiprocess RFC PATCH 35/37] multi-process: QMP/HMP c
From: |
Kevin Wolf |
Subject: |
Re: [Qemu-devel] [multiprocess RFC PATCH 35/37] multi-process: QMP/HMP commands to resize block device on remote process |
Date: |
Thu, 7 Mar 2019 15:11:25 +0100 |
User-agent: |
Mutt/1.11.3 (2019-02-01) |
Am 07.03.2019 um 08:22 hat address@hidden geschrieben:
> From: Jagannathan Raman <address@hidden>
>
> Adds rblock_resize QMP/HMP commands to resize block devices on the remote
> process.
>
> Signed-off-by: John G Johnson <address@hidden>
> Signed-off-by: Jagannathan Raman <address@hidden>
> Signed-off-by: Elena Ufimtseva <address@hidden>
Up to this patch, I thought that maybe the block layer related things
would only need a few changes, like:
* Have -rblockdev instead of -rdrive
* Add QMP version for HMP-only only commands
But this one got me thinking. If I understand this correctly, the
current design means that we have to duplicate every single QMP command
to have a remote variant. This just doesn't scale.
I'm not entirely sure what the final design should look like, but I
think we need to have a separate QMP connection to the process that owns
the block device so that the normal existing QMP commands can be used to
managed it.
In the long run, I think you'll want to separate the block backends from
the device emulation anyway. The thing I have in mind is the storage
daemon idea that was occasionally mentioned here and there; and the
process that owns the device would connect to the backend process, maybe
using the vhost-user protocol (or an extension of it with more
management stuff). For the start, that separate process could in fact be
the main process.
For a limited prototype, maybe we could even use NBD, which is already
existing (both server and client parts), but will obviously impact
performance. Then we'd need a way to configure the remote device process
to connect to either an external NBD server (e.g. qemu-nbd) or to the
main process, which would manage the real storage and export it to the
remote processes over NBD.
In a second step, we could switch it over to a different protocol that
is more feature complete and can provide better performance.
This probably needs some more thought, but what do you think in general?
Kevin