Re: [Qemu-devel] [multiprocess RFC PATCH 35/37] multi-process: QMP/HMP commands to resize block device on remote process

["Dr. David Alan Gilbert" <dgilbert@redhat.com>]

* Kevin Wolf (kwolf@redhat.com) wrote:
> Am 07.03.2019 um 08:22 hat elena.ufimtseva@oracle.com geschrieben:
> > From: Jagannathan Raman <jag.raman@oracle.com>
> > 
> > Adds rblock_resize QMP/HMP commands to resize block devices on the remote
> > process.
> > 
> > Signed-off-by: John G Johnson <john.g.johnson@oracle.com>
> > Signed-off-by: Jagannathan Raman <jag.raman@oracle.com>
> > Signed-off-by: Elena Ufimtseva <elena.ufimtseva@oracle.com>
> 
> 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?

Yeh I was noticing something similar; in a way it feels like you
should be able to do something like make this a property of a bus - i.e.
adding a drive to the bus that's on the remote controller routes it over
to the remote process rather than needing a special command.

Dave

> Kevin
--
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK