qemu-devel
[Top][All Lists]
Advanced

[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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]