Re: [PATCH v2] Get the maxvcpus from both the qemuCaps and /dev/kvm

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, 2016-05-04 at 10:44 -0400, Cole Robinson wrote:
> > Hmm, I think it is a very bad idea to limit the CPUs according to
> > something which is hidden and you cannot influence. In other words, the
> > API itself is not able to report the maximum depending on emulator
> > binary, machine type, whatever so it shouldn't do that at all. Using
> > default emulator and machine type is even more confusing that reporting
> > just the kernel limits.
> 
> Is it not confusing that MaxVCPUs will return a value that no VM can actually
> support, because it hits qemu limits? That was the original complaint.
> 
> Maybe instead we do MIN(kvm_vcpus, max_vcpus_supported_by_any_qemu_machine)
> 
> Even if we don't change the logic, the API documentation could use some work
> to clarify the existing behavior
> 
> > The virConnectGetDomainCapabilities API seems like a much better place
> > for reporting maximum number of usable CPUs as it can get kvm/qemu,
> > arch, emulator binary, and machine type as optional parameters so that
> > the user gets the answer they want rather than just (in various ways)
> > random number reported by virConnectGetMaxVcpus.
> 
> I agree the proper place for reporting fully accurate info is in domcapabilities

How about something like

  <vcpus max='255'>
    <kvm>
      <soft_limit>96</soft_limit>
      <hard_limit>2048</hard_limit>
    </kvm>
    <qemu>
      <hard_limit>255</hard_limit>
    </qemu>
  </vcpus>

Hopefully someone can come up with a better XML than that, but
you get the idea :)

This would include one bit of information that AFAIK we're
currently missing, which is the recommended number of vCPUs;
the maximum value would of course be the smallest amoung all
hard limits.

And of course we can't change virConnectGetMaxVcpus() because
it's public API, but we can extend 'virsh maxvcpus' to accept
the same options as 'virsh domcapabilities' and actually use
the domcapabilities XML behind the scenes.

That, and update the API documentation for
virConnectGetMaxVcpus() to notify applications developers that
they should really use the domcapabilities XML instead.

-- 
Andrea Bolognani
Software Engineer - Virtualization Team

--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list




[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]