In my commit of v7.1.0-rc1~376 I've simplified the logic of
handling @flags. My assumption back then was that calling
virDomainSetMemory() is equivalent to
virDomainSetMemoryFlags(flags = 0). But that is not the case,
because it is equivalent to virDomainSetMemoryFlags(flags =
VIR_DOMAIN_AFFECT_LIVE). Fix the condition that calls the old
API.

Fixes: b5e267e8c59a257652f88d034cb1e0ce1ed4b58a
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1961118
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
---
 tools/virsh-domain.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/virsh-domain.c b/tools/virsh-domain.c
index 0825f82522..bd9325a1d8 100644
--- a/tools/virsh-domain.c
+++ b/tools/virsh-domain.c
@@ -9025,7 +9025,7 @@ cmdSetmem(vshControl *ctl, const vshCmd *cmd)
     }
     kibibytes = VIR_DIV_UP(bytes, 1024);
 
-    if (flags == 0) {
+    if (flags == VIR_DOMAIN_AFFECT_LIVE) {
         if (virDomainSetMemory(dom, kibibytes) != 0)
             ret = false;
     } else {
-- 
2.26.3

On Tue, May 18, 2021 at 02:30:06PM +0200, Michal Privoznik wrote:
> In my commit of v7.1.0-rc1~376 I've simplified the logic of
> handling @flags. My assumption back then was that calling
> virDomainSetMemory() is equivalent to
> virDomainSetMemoryFlags(flags = 0). But that is not the case,
> because it is equivalent to virDomainSetMemoryFlags(flags =
> VIR_DOMAIN_AFFECT_LIVE). Fix the condition that calls the old
> API.
> 
> Fixes: b5e267e8c59a257652f88d034cb1e0ce1ed4b58a
> Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1961118
> Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
> ---
>  tools/virsh-domain.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

I would add a comment in the code as well to help other developers
understand the logic without looking up the commit message.

Reviewed-by: Pavel Hrdina <phrdina@redhat.com>