[libvirt] [PATCH] virsh: report error if vcpu number exceed the guest maxvcpu number

[lhuang]

On 07/02/2015 06:28 PM, John Ferlan wrote:
>
> On 07/02/2015 05:46 AM, Pavel Hrdina wrote:
>
> ...
>
>>> diff --git a/tools/virsh-domain.c b/tools/virsh-domain.c
>>> index 27d62e9..334fd3a 100644
>>> --- a/tools/virsh-domain.c
>>> +++ b/tools/virsh-domain.c
>>> @@ -6497,6 +6497,19 @@ cmdVcpuPin(vshControl *ctl, const vshCmd *cmd)
>>>                goto cleanup;
>>>            }
>>>
>>> +        if (got_vcpu && vcpu >= ncpus) {
>>> +            if (flags & VIR_DOMAIN_AFFECT_LIVE ||
>>> +                (flags & VIR_DOMAIN_AFFECT_CURRENT &&
>>> virDomainIsActive(dom) == 1))
>>> +                vshError(ctl,
>>> +                         _("vcpu %d is out of range of live cpu count %d"),
>>> +                         vcpu, ncpus);
>>> +            else
>>> +                vshError(ctl,
>>> +                         _("vcpu %d is out of range of persistent cpu
>>> count %d"),
>>> +                         vcpu, ncpus);
>>> +            goto cleanup;
>>> +        }
>>> +
>>>            cpumaplen = VIR_CPU_MAPLEN(maxcpu);
>>>            cpumap = vshMalloc(ctl, ncpus * cpumaplen);
>>>            if ((ncpus = virDomainGetVcpuPinInfo(dom, ncpus, cpumap,
>>>
>> This modification is much better and correspond to the error messages while
>> setting the vcpu pinning.
>>
> I just pushed this now - it'd need a bz for a backport (ahem) since
> 1.2.17 was cut before the push...
>
>
> commit 848ab685f74afae102e265108518095942ecb293
> Author: Luyao Huang <lhuang at redhat.com>
> Date:   Mon Jun 29 10:10:15 2015 +0800
>
>      virsh: report error if vcpu number exceed the guest maxvcpu number

Okay, i will help to find a bz for this patch.

thanks a lot for your help and review, Pavel and John :)

> John

Luyao

>>>> Before I make that change for you - hopefully Pavel can take a look as
>>>> well to be sure I haven't missed something.
>>>>
>>>> With any luck we this could be addressed before the 1.2.17 release, but
>>>> if not since it's been a regression since 1.2.13 and no one's noticed,
>>>> then another release probably won't hurt.
>>> Right, if we can fix it in 1.2.17, it will be better :)
>>>
>>> Thanks a lot for your help and review.
>>>
>> ACK to the patch than John updated and proposed.
>>