From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:49293) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fTOPr-0001D4-VF for qemu-devel@nongnu.org; Thu, 14 Jun 2018 05:19:41 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fTOPq-0002Xc-SN for qemu-devel@nongnu.org; Thu, 14 Jun 2018 05:19:39 -0400 Date: Thu, 14 Jun 2018 11:19:26 +0200 From: Kevin Wolf Message-ID: <20180614091926.GC8564@localhost.localdomain> References: <20180613154711.12977-1-dplotnikov@virtuozzo.com> <20180613154711.12977-3-dplotnikov@virtuozzo.com> <20180614090055.GB8564@localhost.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Subject: Re: [Qemu-devel] [PATCH v0 2/2] qmp: add block-set-copy-on-read command List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alberto Garcia Cc: Max Reitz , Eric Blake , Denis Plotnikov , qemu-block@nongnu.org, armbru@redhat.com, famz@redhat.com, stefanha@redhat.com, jcody@redhat.com, qemu-devel@nongnu.org, den@virtuozzo.com, rkagan@virtuozzo.com Am 14.06.2018 um 11:03 hat Alberto Garcia geschrieben: > On Thu 14 Jun 2018 11:00:55 AM CEST, Kevin Wolf 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 > >> >> --- > >> > > >> > 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