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
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list