[libvirt] [PATCH] qemu: Remove limit enforcing when setting processor count

Peter Krempa pkrempa at redhat.com
Mon Sep 10 09:26:50 UTC 2012


On 09/10/12 11:11, Daniel P. Berrange wrote:
> On Fri, Sep 07, 2012 at 11:07:43AM -0600, Eric Blake wrote:
>> On 09/07/2012 09:13 AM, Daniel P. Berrange wrote:
>>> On Fri, Sep 07, 2012 at 02:51:00PM +0200, Peter Krempa wrote:
>>>> When setting processor count for a domain using the API libvirt enforced
>>>> a maximum processor count that was determined using an IOCTL on
>>>> /dev/kvm. Unfortunately this value isn't representative enough and qemu
>>>> happily accepts and starts with values greater than the reported value.
>>>
>>> Really ?  If KVM is accepting a greater vCPU count than it reports
>>> via /dev/kvm, then we should fix the latter
>>
>> Why?  We already allow oversubscription (you can run 3 guests with 1
>> vcpu each on a 2-cpu machine); we also allow pinning a 2-vcpu guest to 1
>> host cpu; so why can't we allow oversubscription from within a single
>> VM?  Sure, performance will be lousier, but that doesn't mean the
>> request is invalid.
>
> This isn't anything todo with oversubscription. This check is validating
> that the user did not request more vCPUs than the hypervisor is able to
> support, regardless of physical CPU count.

Yes. But the problem is that even if /dev/kvm reports that it supports 
160 CPUs you can start guests with 230 processors with any problem. 
(Maybe apart from that it will consume a lot of CPU time).

$ virsh maxvcpus kvm
160

$ virsh vcpuinfo test
VCPU:           0
CPU:            0
State:          running
CPU time:       10.3s
CPU Affinity:   yyyy

VCPU:           1
CPU:            2
State:          running
CPU time:       0.3s
CPU Affinity:   yyyy

....

VCPU:           228
CPU:            0
State:          running
CPU time:       0.2s
CPU Affinity:   yyyy

VCPU:           229
CPU:            2
State:          running
CPU time:       0.2s
CPU Affinity:   yyyy

and it will eventualy boot successfuly after some crunching.


>
> Daniel
>




More information about the libvir-list mailing list