On Fri, Jan 31, 2025 at 10:50:47AM +0100, Kevin Wolf wrote: > Add an option in BlockExportOptions to allow creating an export on an > inactive node without activating the node. This mode needs to be > explicitly supported by the export type (so that it doesn't perform any > operations that are forbidden for inactive nodes), so this patch alone > doesn't allow this option to be successfully used yet. > > Signed-off-by: Kevin Wolf <kw...@redhat.com> > --- > qapi/block-export.json | 10 +++++++++- > include/block/block-global-state.h | 3 +++ > include/block/export.h | 3 +++ > block.c | 4 ++++ > block/export/export.c | 31 ++++++++++++++++++++---------- > 5 files changed, 40 insertions(+), 11 deletions(-) > > diff --git a/qapi/block-export.json b/qapi/block-export.json > index ce33fe378d..117b05d13c 100644 > --- a/qapi/block-export.json > +++ b/qapi/block-export.json > @@ -372,6 +372,13 @@ > # cannot be moved to the iothread. The default is false. > # (since: 5.2) > # > +# @allow-inactive: If true, the export allows the exported node to be > inactive. > +# If it is created for an inactive block node, the node remains > inactive. If > +# the export type doesn't support running on an inactive node, an error > is > +# returned. If false, inactive block nodes are automatically activated > before > +# creating the export and trying to inactivate them later fails. > +# (since: 10.0; default: false)
Exposing activation in the API is ugly but I don't see a cleaner option given that we cannot change block-export-add's existing behavior of activating the node by default. :( Ideally block-export-add would not modify active/inactive and leave it up to user to provide a node in the desired state. Reviewed-by: Stefan Hajnoczi <stefa...@redhat.com>
signature.asc
Description: PGP signature
