On Mon, Aug 30, 2021 at 00:30:43 -0400, Masayoshi Mizuma wrote:
From: Masayoshi Mizuma <m.mizuma@jp.fujitsu.com>
<transient shareBacking='yes'/> option requires set-action capability if destroy action is set to all of the events configuration.
Signed-off-by: Masayoshi Mizuma <m.mizuma@jp.fujitsu.com> --- src/qemu/qemu_validate.c | 13 ++++++++++++- 1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/src/qemu/qemu_validate.c b/src/qemu/qemu_validate.c index 8906aa52d9..0d49512996 100644 --- a/src/qemu/qemu_validate.c +++ b/src/qemu/qemu_validate.c
[...]
@@ -2991,6 +2992,7 @@ qemuValidateDomainDeviceDefDiskBlkdeviotune(const virDomainDiskDef *disk,
static int qemuValidateDomainDeviceDefDiskTransient(const virDomainDiskDef *disk, + const virDomainDef *def, virQEMUCaps *qemuCaps)
{ @@ -3033,6 +3035,15 @@ qemuValidateDomainDeviceDefDiskTransient(const virDomainDiskDef *disk, }
if (disk->transientShareBacking == VIR_TRISTATE_BOOL_YES) { + if (!qemuProcessRebootAllowed(def) && + !virQEMUCapsGet(qemuCaps, QEMU_CAPS_SET_ACTION)) { + virReportError(VIR_ERR_CONFIG_UNSUPPORTED, + _("transient disk backing image sharing with destroy action of lifecycle " + "isn't supported by this QEMU binary (%s)"), + disk->dst); + return -1;
I didn't really consider this corner case worth worrying about. I'll exchange the two terms in the condition since I prefer when capability checks go first in such cases and put the error message on a single line for easier greppability and also add a better explanation of the specific scenario this is handling into the commit message. Series: Reviewed-by: Peter Krempa <pkrempa@redhat.com>