[libvirt] [RFC PATCH] Cannot set persistent config mem/vcpu above live maxmem/maxvcpu

[Geoff Franks]

On Jan 24, 2014, at 12:24 PM, Eric Blake <eblake at redhat.com> wrote:
> Thanks.  You may also want to wrap long lines, and/or use 'git
> send-email' to make the patches easier to use, but for a first time
> submission, this is enough to let us start review.

Thanks, I’ll keep that in mind for next time.

> I'd rather see us check both limits and reject the operation up front if
> we can't meet both limits, than to lower the checks down into the
> live/persistent branches but risk failure with live modified when the
> persistent branch finally detects failure.
> 
> It also has the benefit of being a smaller diffstat:
> 
> diff --git i/src/qemu/qemu_driver.c w/src/qemu/qemu_driver.c
> index a7ef209..82d29c4 100644
> --- i/src/qemu/qemu_driver.c
> +++ w/src/qemu/qemu_driver.c
> @@ -2242,8 +2242,16 @@ static int qemuDomainSetMemoryFlags(virDomainPtr
> dom, unsigned long newmem,
> 
>     } else {
>         /* resize the current memory */
> +        unsigned long oldmax = 0;
> 
> -        if (newmem > vm->def->mem.max_balloon) {
> +        if (flags & VIR_DOMAIN_AFFECT_LIVE)
> +            oldmax = vm->def->mem.max_balloon;
> +        if (flags & VIR_DOMAIN_AFFECT_CONFIG) {
> +            if (!oldmax || oldmax > persistentDef->mem.max_balloon)
> +                oldmax = persistentDef->mem.max_balloon;
> +        }
> +
> +        if (newmem > oldmax) {
>             virReportError(VIR_ERR_INVALID_ARG, "%s",
>                            _("cannot set memory higher than max memory"));
>             goto endjob;
> 
>> @@ -4207,11 +4214,12 @@ qemuDomainSetVcpusFlags(virDomainPtr dom, unsigned int nvcpus,
>>         goto endjob;
>>     }
>> 
>> -    if (!maximum && nvcpus > vm->def->maxvcpus) {
>> +    maxvcpus = (flags & VIR_DOMAIN_AFFECT_LIVE) ? vm->def->maxvcpus : persistentDef->maxvcpus;
> 
> Long line.  Also, I think it suffers from the same problem - if both
> _LIVE and _CONFIG are given at once, then we want to cap things at the
> lower of the two limits, rather than using just the live max as the limit.

This looks like it would work for my purposes.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20140124/e7d84726/attachment-0001.htm>