On Mon, Sep 10, 2012 at 11:26:50AM +0200, Peter Krempa wrote: > 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). As I said earlier, if that is correct, then it is a KVM bug that should be fixed. We should not ignore the limit KVM reports to us just because it appears to work with more vCPUs. We need to ask the KVM guys to explain what's going on here. Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list