[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [RFC] Intermediate block mirroring
From: |
Max Reitz |
Subject: |
Re: [Qemu-devel] [RFC] Intermediate block mirroring |
Date: |
Fri, 13 Apr 2018 16:23:07 +0200 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 |
On 2018-04-12 19:07, Alberto Garcia wrote:
> Hello,
>
> I mentioned this some time ago, but I'd like to retake it now: I'm
> checking how to copy arbitrary nodes on a backing chain, so if I have
> e.g.
>
> [A] <- [B] <- [C] <- [D]
>
> I'd like to end up with
>
> [A] <- [E] <- [C] <- [D]
>
> where [E] is a copy of [B]. The most obvious use case is to move [B]
> to a different storage backend.
>
> At the moment we can already copy [B] into [E] (outside QEMU) and then
> do
>
> change-backing-file device=[D] image-node-name=[C] backing-file=[E]
>
> However this only changes the image on disk and the bs->backing_file
> string in memory. QEMU keeps using the [B] BlockDriverState, and we
> need to make it switch to [E].
>
> One possible way to do this would be to modify blockdev-mirror so the
> source image can be located anywhere on a chain. Currently there's
> bs->backing_blocker preventing that, plus qmp_blockdev_mirror()
> refuses to take any non-root source node. Other than permission
> changes I don't think the algorithm itself needs any additional
> modification, although I suppose we'd like to change the backing file
> as part of the same job, and that would require API changes.
Another way would be to write blockdev-copy. :-)
I don't think there should be a limitation which nodes can be used as
the source of blockdev-mirror, and I think the hardest part about
lifting that limitation is about thinking what might break... Maybe we
should just drop the limitation and deal with the fallout later? I
can't imagine a single node configuration where we'd want to disallow
copying off a node, so I suppose if that breaks in some edge case that
wouldn't be something we'd have to disallow again but we'd just have to
fix it.
> One other way is to have a more generic replace-node command which
> would call bdrv_replace_node(), but I don't know if we want to expose
> that and I don't have any other use case for it at the moment.
I think we do want to expose that. As far as I'm informed, for graph
manipulation we want a command that can replace nodes (including
replacing nothing by a new node or replacing an existing node by
nothing, if the parent supports that).
Also, well, there is blockdev-mirror already has a @replaces parameter,
right? That was supposed to work with quorum, but it seems obvious to
use it here, too.
Max
- [Qemu-devel] [RFC] Intermediate block mirroring, Alberto Garcia, 2018/04/12
- Re: [Qemu-devel] [RFC] Intermediate block mirroring,
Max Reitz <=
- Re: [Qemu-devel] [RFC] Intermediate block mirroring, Alberto Garcia, 2018/04/16
- Re: [Qemu-devel] [RFC] Intermediate block mirroring, Max Reitz, 2018/04/16
- Re: [Qemu-devel] [RFC] Intermediate block mirroring, Alberto Garcia, 2018/04/18
- Re: [Qemu-devel] [RFC] Intermediate block mirroring, Max Reitz, 2018/04/20
- Re: [Qemu-devel] [RFC] Intermediate block mirroring, Alberto Garcia, 2018/04/25
- Re: [Qemu-devel] [RFC] Intermediate block mirroring, Max Reitz, 2018/04/25
- Re: [Qemu-devel] [RFC] Intermediate block mirroring, Alberto Garcia, 2018/04/25
- Re: [Qemu-devel] [RFC] Intermediate block mirroring, Max Reitz, 2018/04/25