On 04/09/13 15:06, Luiz Capitulino wrote:
On Mon, 08 Apr 2013 11:14:32 -0600
Eric Blake <ebl...@redhat.com> wrote:
On 04/08/2013 10:41 AM, Michal Novotny wrote:
Alter the query-machines QMP command to output information about
maximum number of CPUs for each machine type with default value
set to 1 in case the number of max_cpus is not set.
Signed-off-by: Michal Novotny <minov...@redhat.com>
---
qapi-schema.json | 4 +++-
vl.c | 1 +
2 files changed, 4 insertions(+), 1 deletion(-)
diff --git a/qapi-schema.json b/qapi-schema.json
index db542f6..689ca8d 100644
--- a/qapi-schema.json
+++ b/qapi-schema.json
@@ -2861,11 +2861,13 @@
#
# @default: #optional whether the machine is default
#
+# @cpu-max: maximum number of CPUs supported by the machine type
Typically, when adding a field in a later version than the original
introduction of the datatype, we add '(since 1.5)' to make it obvious
when to expect the field. However, as nothing (currently) enforces this
rule, I think such an addition is minor enough that it wouldn't
invalidate the use of my:
Oh, it turns out I was making some confusion with this patch and
didn't realize it was extending the query-machines command.
I don't mean there's anything wrong with it, but my question is: doesn't
this patch invalidates query-cpu-max?
Unfortunately, for libvirt query-cpu-max isn't really usable as it needs
us to start qemu with the correct machine type. This would increase
overhead as we would need to start the qemu process with a safe number
of cpus, use query-cpu-max and then restart the process.
The information added in the query-machines output can on the other hand
be cached (we are already doing this for the machine types) and used
later from the cache without increasing overhead.
So yes, I think it invalidates query-cpu-max and it can be removed in
case it wasn't released.
Peter
PS: I can add the '(since 1.5)' line myself.
Reviewed-by: Eric Blake <ebl...@redhat.com>
