On 5/18/21 3:12 PM, Pavel Hrdina wrote: > On Tue, May 18, 2021 at 03:02:55PM +0200, Ján Tomko wrote: >> On a Tuesday in 2021, 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 >> >> before that commit, if the user did not specify any of: >> config, live, current >> we used the old API. >> >> After this change, the new API will be used for those cases. > > The question is if we support using upstream virsh with old libvirt > where only non-flags API is available. If not we should drop the > non-flags API usage from virsh completely. I think in general we do. In this specific case, virDomainSetMemoryFlags() API was introduced in v0.9.0 release (which is 10 years ago). And since we dropped RHEL-7 support recently and the oldest QEMU we support is from late 2017 our attempt to be that backwards compatible is questionable IMO. But anyway - with this proposed patch the older API is called in more cases than it was before I touched the code => compatibility++. Michal
