Re: Plans to bring QMP 'x-blockdev-reopen' out of experimental?

[Kevin Wolf <kwolf@redhat.com>]

Am 20.10.2020 um 13:53 hat Alberto Garcia geschrieben:
> On Tue 20 Oct 2020 10:23:33 AM CEST, Kevin Wolf wrote:
> >> >    https://lists.gnu.org/archive/html/qemu-block/2020-02/msg00601.html
> >> 
> >> I forgot to add, we still don't support changing bs->file with this
> >> command, so I guess that would be one blocker?
> >> 
> >> There's no other way of inserting filter nodes, or is there?
> >
> > Not that I'm aware of.
> >
> > So yes, changing bs->file is the one thing I had in mind for
> > implementing before we mark it stable.
> 
> Note that you can still open a new bs with a different bs->file and
> replace the original one (as long as the original one is the backing
> file of an existing bs, that is :)).

You can't open the same image twice, so this won't always work.

> > I'm not entirely sure if we should make some restrictions or allow
> > arbitrary changes. If it's only about filters, we could check that the
> > node returned by bdrv_skip_filters() stays the same. This would be
> > almost certainly safe (if the chain is not frozen, of course).
> >
> > If people want to dynamically insert non-filters (maybe quorum?), it
> > might be more restrictive than necessary, though.
> 
> You mean replacing bs->file with a Quorum node? Quorum itself does not
> use bs->file, it has the 'children' attribute.

Yes, replaying bs->file with a Quorum node that has the old bs->file as
one of its children. Or removing a Quorum node so that one of it's
children replaces it.

But this is probably not a very important use case, so I think the
restriction is not a problem. Lifting restrictions later is easier than
adding new ones.

Kevin