[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Plans to bring QMP 'x-blockdev-reopen' out of experimental?
From: |
Alberto Garcia |
Subject: |
Re: Plans to bring QMP 'x-blockdev-reopen' out of experimental? |
Date: |
Tue, 20 Oct 2020 13:53:11 +0200 |
User-agent: |
Notmuch/0.18.2 (http://notmuchmail.org) Emacs/24.4.1 (i586-pc-linux-gnu) |
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 :)).
> 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.
Berto