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