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
