[PATCH 0/4] qemu: fix block jobs when copy_on_read is enabled
pkrempa at redhat.com
Fri Jan 24 12:39:05 UTC 2020
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:
> 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:
> 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!
More information about the libvir-list