On 06/19/2009 05:23 PM, Jes Sorensen wrote:
libvirt currently does
fd = open("/dev/kvm")
r = ioctl(fd, KVM_CHECK_EXTENSION, KVM_CAP_NR_VCPUS);
to figure out what the maximum allowed vCPUs will be for KVM,
and currently it is returning 16 IIRC.
Interesting, this will need to be addressed as well. I have plans to
introduce a mechanism telling the kernel where the limit will be, in
order to allow it to allocate data structures in a reasonable manner.
I prefer to have the kernel adjust dynamically. The vcpu array wants 8
bytes per vcpu, so for 256 vcpus we're still a very reasonable 2K. For
(say) 4K vcpus, we'll need to reallocate the array dynamically, for
which rcu will be perfect or better.
This implies the limit (for x86 pc machine at least) is now 255. Is that
the correct interpretation on my part ?
Actually the 255 limit is tied to ACPI. Once we support ACPI 3.0 and
x2apic, it will get much worse. Be afraid, be very afraid :-) To be
honest, that is going to be a while before we get to that, but I hope
to get to it eventually.
I strongly recommend you try not to impose static limits within libvirt
for the number of vCPUs.
I guess it will become a tricky issue who is telling who what the limit
is. Ideally I would like to see the kernel limit becoming unlimited and
the restrictions being set by userland.
The kernel needs some kind of limit to avoid resource exhaustion. Could
be set quite high. Beyond that there should be additional setup.
Note for 4K vcpus you'll need to increase the maximum opened files
opened by a process, threads, etc.
--
error compiling committee.c: too many arguments to function
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
