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: >>Hi, >> >>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 >> >> >>Cons: >>----- >>- ~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.