Re: [Qemu-devel] [PATCH v0 2/2] qmp: add block-set-copy-on-read command

[Kevin Wolf <kwolf@redhat.com>]

Am 14.06.2018 um 11:03 hat Alberto Garcia geschrieben:
> On Thu 14 Jun 2018 11:00:55 AM CEST, Kevin Wolf <kwolf@redhat.com> wrote:
> > Am 13.06.2018 um 18:41 hat Max Reitz geschrieben:
> >> On 2018-06-13 18:02, Eric Blake wrote:
> >> > On 06/13/2018 10:47 AM, Denis Plotnikov wrote:
> >> >> The command enables/disables copy-on-read mode for VM's disk while
> >> >> VM is running.
> >> >>
> >> >> This is needed when using external disk readers to shape access pattern
> >> >> to the disk backend.
> >> >>
> >> >> Signed-off-by: Denis Plotnikov <dplotnikov@virtuozzo.com>
> >> >> ---
> >> > 
> >> > Deferring thoughts on the actual design for later;
> >> 
> >> But why? ;-)
> >> 
> >> This patch would definitely be superseded by a block reconfiguration
> >> command (i.e. presumably one that makes reopen accessible over QMP).
> >> With such a command, you could insert or remove a copy-on-read filter
> >> node at any point in time.
> >> 
> >> Since we definitely want block graph configuration, I don't think we
> >> want to add special commands now.
> >
> > I agree, and it seems that we get more and more use cases for a block
> > reconfiguration commands. Only yesterday we talked about the "true"
> > blockdev way for libvirt to implement I/O throttling. The result was
> > that without reopen, we still need to use the old QMP command to set
> > BlockBackend-based I/O throttling instead of using a filter node.
> >
> > So I'm eagerly awaiting Berto's promised patches for it.
> 
> They're coming, it's just a bit tricker than I initially though. I'll
> probably send the first series as an RFC if I don't manage to fix all
> problems, so we can discuss them a bit.

Sounds good to me. It's not completely surprising that there are some
tricky spots there, we've been postponing this for a reason...

Kevin