qemu-block
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-block] [RFC] Intermediate block mirroring


From: Max Reitz
Subject: Re: [Qemu-block] [RFC] Intermediate block mirroring
Date: Wed, 2 May 2018 16:12:49 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0

On 2018-05-02 15:07, Alberto Garcia wrote:
> On Wed 25 Apr 2018 04:03:22 PM CEST, Max Reitz wrote:
>>>> But the question stands whether we need simple node replacement when
>>>> we want bdrv_reopen() anyway.  In addition, we don't need just
>>>> replacement, we also need addition and removal (e.g. for backing
>>>> files or quorum children) -- and especially in the case of quorum,
>>>> that is going to be a pain (mostly naming the children).
>>>>
>>>> With bdrv_reopen(), we can just require the user to respecify all
>>>> children, so we don't run into the issue of how to name things at
>>>> least.
>>>
>>> So in this example, if you want to replace [B] with [E] you would
>>> reopen [C] specifying the new backing file?
>>>
>>>    [A] <- [B] <- [C] <- [D]
>>>
>>>           [E]
>>
>> You can just use child node name references like in blockdev-add.
> 
> Were the (more or less) exact requirements of QMP blockdev-reopen
> discussed? How is it different from qemu-io's "reopen" command? What are
> the options that you can and can not change?

I can't quite remember, I'm afraid.  I think it was supposed to be
pretty much qemu-io's reopen (so just bdrv_reopen()).  I suppose you
cannot change the driver (obviously) or probably the node name, because
either would result in the node being replaced by a completely new one.

Other than that, it probably depends on what the block driver supports,
but ideally you should be able to change everything.

> Also, you could replace an element in the backing chain using reopen,
> but can you replace a node that is not a backing image of another one?

Node replacement only makes sense if the node is used as the child of
something.  Otherwise it's just a blockdev-add + blockdev-del.

But it doesn't have to be in a backing chain, of course.  It would work
for Quorum children, too.

> With QMP blockdev-replace you could use the existing blockdev-add
> command and create an arbitrary tree and then simply do blockdev-replace
> so I suppose that for some use cases at least it would be pretty
> straightforward.

You can do the same with reopen.  Just use a reference for the child name.

Say you have a qcow2 node "overlay" with a backing child.  Now you want
to replace that with a different child "new-backing".

For both blockdev-replace and reopen the first thing you can do is
blockdev-add the new child.  Then it depends:

blockdev-replace: You call it with parent=overlay, child=backing,
node=new-backing.

reopen: You call it like blockdev-add, that is:
    { "node-name": "overlay",
      "backing": "new-backing" }
In theory every option you do not specify is unchanged, so I suppose you
can leave out e.g. the "driver" option here.

Sure, with reopen you can also respecify the whole tree if you so desire
(so you can get away without blockdev-add'ing new-backing before), but
you don't have to.

Max

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

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