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