On Mon, Mar 19, 2012 at 10:09:22AM -0500, Anthony Liguori wrote: > This dumps the results of query-version, query-commands, and > query-config-capabilities into a single JSON object on stdout. > > Signed-off-by: Anthony Liguori <aligu...@us.ibm.com>
What about a mode where no machine and devices are initialized at all, but where config files are (optionally) loaded[1] and QMP commands can be run? It looks like too much work for 1.1, but I would like to see this eventually. This would be the starting point for the day we would be able to run an "empty" Qemu process, probe for features, set up everything using QMP, and then start the actual virtual machine. [1] I am asking for this specifically because I know libvirt will need to probe for some things _after_ loading the config files. This is the case for the cpudefs, but it may be true for other features and capabilities too (probing for machine-type info would need it too, if we moved them to config files some day). That leads to another question: would it be acceptable to include data that is depends on the loaded config files inside the -query-config-capabilities output? (for example, the list of CPU models) Or do you want to make -query-capabilities independent from the loaded config data? Let me try to explain the use case: some configuration options are high-level and enable and disable a feature as a whole, but management may want to know what are the low-level details that result from a specific configuration combination. -writeconfig could help, but it won't write that low-level data, it will write only the high-level config it had read. Example: you are going to ask Qemu to set up a specific CPU cores/threads topology using "-smp", but then you want to know how exactly the CPUID topology leafs will look like when you do that. You _could_ calculate the resulting bits yourself based on your "-smp" parameter (as the calculation is deterministic), but it would just duplicate the CPUID generation logic that's already inside Qemu. -- Eduardo
