[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [RFC] Intermediate block mirroring
From: |
Alberto Garcia |
Subject: |
Re: [Qemu-devel] [RFC] Intermediate block mirroring |
Date: |
Mon, 16 Apr 2018 16:59:40 +0200 |
User-agent: |
Notmuch/0.18.2 (http://notmuchmail.org) Emacs/24.4.1 (i586-pc-linux-gnu) |
On Fri 13 Apr 2018 04:23:07 PM CEST, Max Reitz wrote:
> 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. :-)
Something like blockdev-backup but without copying data from backing
files? blockdev-mirror already allows configuring that using the
MirrorSyncMode parameter.
> 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.
I can't think of any problem either. The important question is what to
do if the source node is read/write, but that's what blockdev-mirror is
already about. In all other cases the source node is going to be read
only, isn't 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).
Was there any discussion about this in the mailing list? (proposed name
for this function, features, etc.)
> 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.
Yes, it could be used for this.
Berto
- [Qemu-devel] [RFC] Intermediate block mirroring, Alberto Garcia, 2018/04/12
- Re: [Qemu-devel] [RFC] Intermediate block mirroring, Max Reitz, 2018/04/13
- Re: [Qemu-devel] [RFC] Intermediate block mirroring,
Alberto Garcia <=
- 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