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

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.

“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.)

> 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.)