[PATCH 0/4] qemu: fix block jobs when copy_on_read is enabled

[Peter Krempa]

On Fri, Jan 24, 2020 at 11:23:46 +0100, Max Reitz wrote:
> On 23.01.20 16:57, Peter Krempa wrote:
> > QEMU requires us to pass the topmost node(-name) in the backing chain as
> > the 'device' argument for the blockdev-mirror/block-commit commands.
> > Otherwise QEMU complains:
> > 
> >  "Need a root block node"
> > 
> > Since libvirt always puts the copy-on-read driver on top of the backing
> > chain, blockjobs on disks which use "copy_on_read" fail.
> > 
> > The series below fixes that by passing the proper node. This fixes it
> > just fine for the mirror, but for block-commit we still get another
> > error due to a bug in qemu:
> > 
> >  "'libvirt-4-format' is not in this backing file chain"
> > 
> > Additionally one weird thing happens with block-stream (blockpull). If I
> > pass the layer below the copy-on-read as 'device', everything works.
> > This is kind of weird as the documentation for that is the same. If I
> > pass the nodename of copy-on-read.
> 
> It isn’t.  block-stream says:
> > # @device: the device or node name of the top image
> block-commit says:
> > # @device:  the device name or node-name of a root node
> blockdev-mirror says:
> > # @device: The device name or node-name of a root node whose writes should be
> > #          mirrored.
> 
> Note the subtle difference: “top” != “root”.  “top” is meant just as
> part of the job: There’s a base image, and a top image.  The top image
> is the target (for stream, that is), the base is the first image in the
> chain that will be kept.

Ah, right. The distinction was too subtle for me to detect :)

> 
> “root node” means actually a root node in the graph.
> 
> Hence, stream doesn’t require @device to point to a root node.  (Before
> qemu commit 554b6147650 it did, but that commit relaxed block-stream.)

Cool, thanks for the version info. Since we use this only starting from
qemu-4.2 we are safe to always use it.


> > Max, Kevin, could you please comment on the block-stream part and
> > possibly also on the plans to fix the issue with block-commit?
> 
> The plans are to fix it.  The latest version of the series is here:
> 
> https://lists.nongnu.org/archive/html/qemu-block/2019-08/msg00350.html
> 
> It’s from August because it’s an extreme churn to work on new versions.
>  It touches basically everything in the block layer, so rebasing it
> alone takes time.  And then there are facts like reviews leading to new
> prerequesite series, namely:
> 
> https://lists.nongnu.org/archive/html/qemu-block/2019-11/msg00370.html
> https://lists.nongnu.org/archive/html/qemu-block/2019-11/msg00908.html
> 
> So in total, there are 96 patches.  The churn for each version is hard.
>  Finding willing reviewers is even harder.
> 
> (I actually have basically no reviews for one of those prerequisite
> series (“block: Introduce real BdrvChildRole”) yet, so there’s little
> point in working on v7 of the main series.)

Thanks for the info. Unfortunately I'm not too familiar with qemu to
warant a review for this :(

Thank you for the information!