On Thu, Apr 04, 2013 at 06:30:08PM +0200, Peter Krempa wrote:

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.

I think it is preferrable to *not* do such validation at parse / load time, but rather only when starting the guest or invoking some API on a running guest. You have todo the validation when starting the guest anyway, since you can't assume you still have the same QEMU installed as was available when virDomainDefine was invoked. Doing validation at parse time based on QEMU capabilities already causes some pain. For example, if you temporarily uninstall QEMU, then libvirt will fail to load any XML files since it can't validate the machine types from the QEMU capabilities. This rather sucks - it should really only fail if you actually tried to start the VM, not merely loading the config. So I think it is better not to add more of this time of validation at parse time, and even possibly remove what we already have. Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|

On 04/04/2013 01:13 PM, Viktor Mihajlovski wrote:

...

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. I am very sympathetic there because for s390 the machine type defines

On 04/04/2013 06:20 PM, Peter Krempa wrote: the bus type and thus has an considerable impact on the device configuration options. On the other hand QEMU unfortunately fails to offer per-machine device capabilities today. See also https://www.redhat.com/archives/libvir-list/2013-February/msg00537.html and Dan's concerns with that approach. In a better world the QMP interface might allow to query per machine type (one can always dream...)

At one time we requested that of qemu, and learned that, due to the way qemu is internally organized, that would be next to impossible to provide (it turns out that type of information isn't available in a data table, but is constructed on the fly as a machine is instantiated, and one a machine is instantiated, qemu can't tear it down and instantiate a new/different machine without completely shutting down). However, as Dan pointed out in a previous message, relying on such information for definition-time validation would be flawed anyway, because there is no guarantee that what was available in the qemu binary at the time of definition (on the host where the definition is done) would be the same as what was available at runtime. Now that pkrempa's patches to support domain post-parse callback functions are going in, we can add in qemu-specific callbacks that do extra validation of devices depending on the setting of machinetype. This will be a big win not only for s390, but also for ARM and q35; we'll be able to remove all of the x86 (i.e. "pc") specific stuff that's automatically added to domains from the generic parser, and put it in a callback to only be added for pc-* machine types. Likewise you'll be able to do the same thing for any devices/controllers specific to s390. It won't allow *exact* validation for exactly what is supported by the binary on the current machine, but it will at least allow getting extremely close, and any final minute differences can be handled when the guest is actually started up.