[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