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 <mpriv...@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
_______________________________________________ libvirt-users mailing list libvirt-users@redhat.com https://www.redhat.com/mailman/listinfo/libvirt-users
