[libvirt-users] maxvcpus

[Laszlo Hornyak]

Hi Michal,

Thank you for the answer, I understand now!
Indeed we haven't met for a long while, I hope I will have a chance to talk
to you at the Brno developer conference.

Best regards,
Laszlo

On Thu, Nov 20, 2014 at 10:24 AM, Michal Privoznik <mprivozn at redhat.com>
wrote:

> On 20.11.2014 09:12, Laszlo Hornyak wrote:
>
>> Hi list,
>>
>
> Hey Laszlo, long time no see!
>
>
>> According to the libvirt documentation [1]
>>
>> "Show maximum number of virtual CPUs for guest domains on this connection"
>>
>> This may not be a complete definition.
>>
>> My first guess from the above was that this returns the number of
>> virtual CPUs that can exist at the same time on the host, either one or
>> several VMs. In fact it returned 16 in my fedora 20 desktop running with
>> KVM, while this is not the real limit of vCPUs. I can define a VM with
>> more than 16 vCPUs (which does not really make sense when I have only
>> two cores, but it looks cool) and  also I can have well over 16 virtual
>> machines running on the host. I looked into the implementation and now I
>> understand that each driver returns different values, but I do not
>> understand the constants. Can you guys give me some hints how should I
>> understand the output of the command?
>>
>>
> Well, qemu drivers serves both virt types: kvm and bare qemu. While the
> latter has no real limit (it's just an userland process without hw
> acceleration), the former involves KVM in kernel and thus has some
> limitation on maximal number of machines (inherited from KVM limitation).
> So, unless you specify which virt type you want to use, libvirt blindly
> returns 16 (arbitrary meaningless value). But if you specify kvm you'll get
> sensible value:
>
> virsh # maxvcpus
> 16
>
> virsh # maxvcpus --type kvm
> 255
>
>
> Hope this shed more light in.
>
> Michal
>



-- 

EOF
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/libvirt-users/attachments/20141120/8e9eb167/attachment.htm>