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

Re: [libvirt] [RFC] Per machine type qemu capability detection

On 04/04/13 18:22, Daniel P. Berrange wrote:
On Thu, Apr 04, 2013 at 06:20:05PM +0200, Peter Krempa wrote:

qemu recently added a qmp/hmp command ("get-cpu-max") to determine
maximum number of supported CPUs for a VM. The output of this
command depends on the machine type that is used when it is called.
The problem here is that libvirt uses "-M none" while detecting
capabilities and with that machine type the get-cpu-max command
returns always 1.

My question is: Is it worthwhile to do per machine type capability
detection? It definitely isn't worth doing just for the get-cpu-max
support, but it might be needed for Q35 or other stuff that may
depend on the actual machine type used.

Pros of this approach:
- (possibly) more accurate capabilities

- ~10x more qemus started on libvirtd startup (one per machine type)

That "con" simply rules it out entirely, not matter what "pro"
points there may be I'm afraid.

Yes, that's why I'm asking if there isn't a better use case that could justify the overhead.

For your example here though, why do we need a capabiltiy for that?
Can't we just call get-cpu-max from the specific libvirt API calls
that actually want that info.

I planed to use it to validate configuration when parsing domain XMLs where it would come handy to have the data pre-cached. Also I don't think it's wise to invoke a qemu when a domain XML is being parsed to find out if the configuration is valid.

Other than validating XML config, this information can only be meaningfully used with CPU hotplug. Other use cases aren't really useful as qemu either checks the number directly at start of the guest or simply isn't running at the time the information is required.



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