qemu-e2k/qapi/stats.json

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

272 lines
6.4 KiB
JSON
Raw Normal View History

qmp: Support for querying stats Gathering statistics is important for development, for monitoring and for performance measurement. There are tools such as kvm_stat that do this and they rely on the _user_ knowing the interesting data points rather than the tool (which can treat them as opaque). The commands introduced in this commit introduce QMP support for querying stats; the goal is to take the capabilities of these tools and making them available throughout the whole virtualization stack, so that one can observe, monitor and measure virtual machines without having shell access + root on the host that runs them. query-stats returns a list of all stats per target type (only VM and vCPU to start); future commits add extra options for specifying stat names, vCPU qom paths, and providers. All these are used by the HMP command "info stats". Because of the development usecases around statistics, a good HMP interface is important. query-stats-schemas returns a list of stats included in each target type, with an option for specifying the provider. The concepts in the schema are based on the KVM binary stats' own introspection data, just translated to QAPI. There are two reasons to have a separate schema that is not tied to the QAPI schema. The first is the contents of the schemas: the new introspection data provides different information than the QAPI data, namely unit of measurement, how the numbers are gathered and change (peak/instant/cumulative/histogram), and histogram bucket sizes. There's really no reason to have this kind of metadata in the QAPI introspection schema (except possibly for the unit of measure, but there's a very weak justification). Another reason is the dynamicity of the schema. The QAPI introspection data is very much static; and while QOM is somewhat more dynamic, generally we consider that to be a bug rather than a feature these days. On the other hand, the statistics that are exposed by QEMU might be passed through from another source, such as KVM, and the disadvantages of manually updating the QAPI schema for outweight the benefits from vetting the statistics and filtering out anything that seems "too unstable". Running old QEMU with new kernel is a supported usecase; if old QEMU cannot expose statistics from a new kernel, or if a kernel developer needs to change QEMU before gathering new info from the new kernel, then that is a poor user interface. The framework provides a method to register callbacks for these QMP commands. Most of the work in fact is done by the callbacks, and a large majority of this patch is new QAPI structs and commands. Examples (with KVM stats): - Query all VM stats: { "execute": "query-stats", "arguments" : { "target": "vm" } } { "return": [ { "provider": "kvm", "stats": [ { "name": "max_mmu_page_hash_collisions", "value": 0 }, { "name": "max_mmu_rmap_size", "value": 0 }, { "name": "nx_lpage_splits", "value": 148 }, ... ] }, { "provider": "xyz", "stats": [ ... ] } ] } - Query all vCPU stats: { "execute": "query-stats", "arguments" : { "target": "vcpu" } } { "return": [ { "provider": "kvm", "qom_path": "/machine/unattached/device[0]" "stats": [ { "name": "guest_mode", "value": 0 }, { "name": "directed_yield_successful", "value": 0 }, { "name": "directed_yield_attempted", "value": 106 }, ... ] }, { "provider": "kvm", "qom_path": "/machine/unattached/device[1]" "stats": [ { "name": "guest_mode", "value": 0 }, { "name": "directed_yield_successful", "value": 0 }, { "name": "directed_yield_attempted", "value": 106 }, ... ] }, ] } - Retrieve the schemas: { "execute": "query-stats-schemas" } { "return": [ { "provider": "kvm", "target": "vcpu", "stats": [ { "name": "guest_mode", "unit": "none", "base": 10, "exponent": 0, "type": "instant" }, { "name": "directed_yield_successful", "unit": "none", "base": 10, "exponent": 0, "type": "cumulative" }, ... ] }, { "provider": "kvm", "target": "vm", "stats": [ { "name": "max_mmu_page_hash_collisions", "unit": "none", "base": 10, "exponent": 0, "type": "peak" }, ... ] }, { "provider": "xyz", "target": "vm", "stats": [ ... ] } ] } Signed-off-by: Mark Kanda <mark.kanda@oracle.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2022-02-15 16:04:31 +01:00
# -*- Mode: Python -*-
# vim: filetype=python
#
# Copyright (c) 2022 Oracle and/or its affiliates.
#
# This work is licensed under the terms of the GNU GPL, version 2 or later.
# See the COPYING file in the top-level directory.
#
# SPDX-License-Identifier: GPL-2.0-or-later
##
# = Statistics
##
##
# @StatsType:
#
# Enumeration of statistics types
#
# @cumulative: stat is cumulative; value can only increase.
#
qmp: Support for querying stats Gathering statistics is important for development, for monitoring and for performance measurement. There are tools such as kvm_stat that do this and they rely on the _user_ knowing the interesting data points rather than the tool (which can treat them as opaque). The commands introduced in this commit introduce QMP support for querying stats; the goal is to take the capabilities of these tools and making them available throughout the whole virtualization stack, so that one can observe, monitor and measure virtual machines without having shell access + root on the host that runs them. query-stats returns a list of all stats per target type (only VM and vCPU to start); future commits add extra options for specifying stat names, vCPU qom paths, and providers. All these are used by the HMP command "info stats". Because of the development usecases around statistics, a good HMP interface is important. query-stats-schemas returns a list of stats included in each target type, with an option for specifying the provider. The concepts in the schema are based on the KVM binary stats' own introspection data, just translated to QAPI. There are two reasons to have a separate schema that is not tied to the QAPI schema. The first is the contents of the schemas: the new introspection data provides different information than the QAPI data, namely unit of measurement, how the numbers are gathered and change (peak/instant/cumulative/histogram), and histogram bucket sizes. There's really no reason to have this kind of metadata in the QAPI introspection schema (except possibly for the unit of measure, but there's a very weak justification). Another reason is the dynamicity of the schema. The QAPI introspection data is very much static; and while QOM is somewhat more dynamic, generally we consider that to be a bug rather than a feature these days. On the other hand, the statistics that are exposed by QEMU might be passed through from another source, such as KVM, and the disadvantages of manually updating the QAPI schema for outweight the benefits from vetting the statistics and filtering out anything that seems "too unstable". Running old QEMU with new kernel is a supported usecase; if old QEMU cannot expose statistics from a new kernel, or if a kernel developer needs to change QEMU before gathering new info from the new kernel, then that is a poor user interface. The framework provides a method to register callbacks for these QMP commands. Most of the work in fact is done by the callbacks, and a large majority of this patch is new QAPI structs and commands. Examples (with KVM stats): - Query all VM stats: { "execute": "query-stats", "arguments" : { "target": "vm" } } { "return": [ { "provider": "kvm", "stats": [ { "name": "max_mmu_page_hash_collisions", "value": 0 }, { "name": "max_mmu_rmap_size", "value": 0 }, { "name": "nx_lpage_splits", "value": 148 }, ... ] }, { "provider": "xyz", "stats": [ ... ] } ] } - Query all vCPU stats: { "execute": "query-stats", "arguments" : { "target": "vcpu" } } { "return": [ { "provider": "kvm", "qom_path": "/machine/unattached/device[0]" "stats": [ { "name": "guest_mode", "value": 0 }, { "name": "directed_yield_successful", "value": 0 }, { "name": "directed_yield_attempted", "value": 106 }, ... ] }, { "provider": "kvm", "qom_path": "/machine/unattached/device[1]" "stats": [ { "name": "guest_mode", "value": 0 }, { "name": "directed_yield_successful", "value": 0 }, { "name": "directed_yield_attempted", "value": 106 }, ... ] }, ] } - Retrieve the schemas: { "execute": "query-stats-schemas" } { "return": [ { "provider": "kvm", "target": "vcpu", "stats": [ { "name": "guest_mode", "unit": "none", "base": 10, "exponent": 0, "type": "instant" }, { "name": "directed_yield_successful", "unit": "none", "base": 10, "exponent": 0, "type": "cumulative" }, ... ] }, { "provider": "kvm", "target": "vm", "stats": [ { "name": "max_mmu_page_hash_collisions", "unit": "none", "base": 10, "exponent": 0, "type": "peak" }, ... ] }, { "provider": "xyz", "target": "vm", "stats": [ ... ] } ] } Signed-off-by: Mark Kanda <mark.kanda@oracle.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2022-02-15 16:04:31 +01:00
# @instant: stat is instantaneous; value can increase or decrease.
#
qmp: Support for querying stats Gathering statistics is important for development, for monitoring and for performance measurement. There are tools such as kvm_stat that do this and they rely on the _user_ knowing the interesting data points rather than the tool (which can treat them as opaque). The commands introduced in this commit introduce QMP support for querying stats; the goal is to take the capabilities of these tools and making them available throughout the whole virtualization stack, so that one can observe, monitor and measure virtual machines without having shell access + root on the host that runs them. query-stats returns a list of all stats per target type (only VM and vCPU to start); future commits add extra options for specifying stat names, vCPU qom paths, and providers. All these are used by the HMP command "info stats". Because of the development usecases around statistics, a good HMP interface is important. query-stats-schemas returns a list of stats included in each target type, with an option for specifying the provider. The concepts in the schema are based on the KVM binary stats' own introspection data, just translated to QAPI. There are two reasons to have a separate schema that is not tied to the QAPI schema. The first is the contents of the schemas: the new introspection data provides different information than the QAPI data, namely unit of measurement, how the numbers are gathered and change (peak/instant/cumulative/histogram), and histogram bucket sizes. There's really no reason to have this kind of metadata in the QAPI introspection schema (except possibly for the unit of measure, but there's a very weak justification). Another reason is the dynamicity of the schema. The QAPI introspection data is very much static; and while QOM is somewhat more dynamic, generally we consider that to be a bug rather than a feature these days. On the other hand, the statistics that are exposed by QEMU might be passed through from another source, such as KVM, and the disadvantages of manually updating the QAPI schema for outweight the benefits from vetting the statistics and filtering out anything that seems "too unstable". Running old QEMU with new kernel is a supported usecase; if old QEMU cannot expose statistics from a new kernel, or if a kernel developer needs to change QEMU before gathering new info from the new kernel, then that is a poor user interface. The framework provides a method to register callbacks for these QMP commands. Most of the work in fact is done by the callbacks, and a large majority of this patch is new QAPI structs and commands. Examples (with KVM stats): - Query all VM stats: { "execute": "query-stats", "arguments" : { "target": "vm" } } { "return": [ { "provider": "kvm", "stats": [ { "name": "max_mmu_page_hash_collisions", "value": 0 }, { "name": "max_mmu_rmap_size", "value": 0 }, { "name": "nx_lpage_splits", "value": 148 }, ... ] }, { "provider": "xyz", "stats": [ ... ] } ] } - Query all vCPU stats: { "execute": "query-stats", "arguments" : { "target": "vcpu" } } { "return": [ { "provider": "kvm", "qom_path": "/machine/unattached/device[0]" "stats": [ { "name": "guest_mode", "value": 0 }, { "name": "directed_yield_successful", "value": 0 }, { "name": "directed_yield_attempted", "value": 106 }, ... ] }, { "provider": "kvm", "qom_path": "/machine/unattached/device[1]" "stats": [ { "name": "guest_mode", "value": 0 }, { "name": "directed_yield_successful", "value": 0 }, { "name": "directed_yield_attempted", "value": 106 }, ... ] }, ] } - Retrieve the schemas: { "execute": "query-stats-schemas" } { "return": [ { "provider": "kvm", "target": "vcpu", "stats": [ { "name": "guest_mode", "unit": "none", "base": 10, "exponent": 0, "type": "instant" }, { "name": "directed_yield_successful", "unit": "none", "base": 10, "exponent": 0, "type": "cumulative" }, ... ] }, { "provider": "kvm", "target": "vm", "stats": [ { "name": "max_mmu_page_hash_collisions", "unit": "none", "base": 10, "exponent": 0, "type": "peak" }, ... ] }, { "provider": "xyz", "target": "vm", "stats": [ ... ] } ] } Signed-off-by: Mark Kanda <mark.kanda@oracle.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2022-02-15 16:04:31 +01:00
# @peak: stat is the peak value; value can only increase.
#
qmp: Support for querying stats Gathering statistics is important for development, for monitoring and for performance measurement. There are tools such as kvm_stat that do this and they rely on the _user_ knowing the interesting data points rather than the tool (which can treat them as opaque). The commands introduced in this commit introduce QMP support for querying stats; the goal is to take the capabilities of these tools and making them available throughout the whole virtualization stack, so that one can observe, monitor and measure virtual machines without having shell access + root on the host that runs them. query-stats returns a list of all stats per target type (only VM and vCPU to start); future commits add extra options for specifying stat names, vCPU qom paths, and providers. All these are used by the HMP command "info stats". Because of the development usecases around statistics, a good HMP interface is important. query-stats-schemas returns a list of stats included in each target type, with an option for specifying the provider. The concepts in the schema are based on the KVM binary stats' own introspection data, just translated to QAPI. There are two reasons to have a separate schema that is not tied to the QAPI schema. The first is the contents of the schemas: the new introspection data provides different information than the QAPI data, namely unit of measurement, how the numbers are gathered and change (peak/instant/cumulative/histogram), and histogram bucket sizes. There's really no reason to have this kind of metadata in the QAPI introspection schema (except possibly for the unit of measure, but there's a very weak justification). Another reason is the dynamicity of the schema. The QAPI introspection data is very much static; and while QOM is somewhat more dynamic, generally we consider that to be a bug rather than a feature these days. On the other hand, the statistics that are exposed by QEMU might be passed through from another source, such as KVM, and the disadvantages of manually updating the QAPI schema for outweight the benefits from vetting the statistics and filtering out anything that seems "too unstable". Running old QEMU with new kernel is a supported usecase; if old QEMU cannot expose statistics from a new kernel, or if a kernel developer needs to change QEMU before gathering new info from the new kernel, then that is a poor user interface. The framework provides a method to register callbacks for these QMP commands. Most of the work in fact is done by the callbacks, and a large majority of this patch is new QAPI structs and commands. Examples (with KVM stats): - Query all VM stats: { "execute": "query-stats", "arguments" : { "target": "vm" } } { "return": [ { "provider": "kvm", "stats": [ { "name": "max_mmu_page_hash_collisions", "value": 0 }, { "name": "max_mmu_rmap_size", "value": 0 }, { "name": "nx_lpage_splits", "value": 148 }, ... ] }, { "provider": "xyz", "stats": [ ... ] } ] } - Query all vCPU stats: { "execute": "query-stats", "arguments" : { "target": "vcpu" } } { "return": [ { "provider": "kvm", "qom_path": "/machine/unattached/device[0]" "stats": [ { "name": "guest_mode", "value": 0 }, { "name": "directed_yield_successful", "value": 0 }, { "name": "directed_yield_attempted", "value": 106 }, ... ] }, { "provider": "kvm", "qom_path": "/machine/unattached/device[1]" "stats": [ { "name": "guest_mode", "value": 0 }, { "name": "directed_yield_successful", "value": 0 }, { "name": "directed_yield_attempted", "value": 106 }, ... ] }, ] } - Retrieve the schemas: { "execute": "query-stats-schemas" } { "return": [ { "provider": "kvm", "target": "vcpu", "stats": [ { "name": "guest_mode", "unit": "none", "base": 10, "exponent": 0, "type": "instant" }, { "name": "directed_yield_successful", "unit": "none", "base": 10, "exponent": 0, "type": "cumulative" }, ... ] }, { "provider": "kvm", "target": "vm", "stats": [ { "name": "max_mmu_page_hash_collisions", "unit": "none", "base": 10, "exponent": 0, "type": "peak" }, ... ] }, { "provider": "xyz", "target": "vm", "stats": [ ... ] } ] } Signed-off-by: Mark Kanda <mark.kanda@oracle.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2022-02-15 16:04:31 +01:00
# @linear-histogram: stat is a linear histogram.
#
qmp: Support for querying stats Gathering statistics is important for development, for monitoring and for performance measurement. There are tools such as kvm_stat that do this and they rely on the _user_ knowing the interesting data points rather than the tool (which can treat them as opaque). The commands introduced in this commit introduce QMP support for querying stats; the goal is to take the capabilities of these tools and making them available throughout the whole virtualization stack, so that one can observe, monitor and measure virtual machines without having shell access + root on the host that runs them. query-stats returns a list of all stats per target type (only VM and vCPU to start); future commits add extra options for specifying stat names, vCPU qom paths, and providers. All these are used by the HMP command "info stats". Because of the development usecases around statistics, a good HMP interface is important. query-stats-schemas returns a list of stats included in each target type, with an option for specifying the provider. The concepts in the schema are based on the KVM binary stats' own introspection data, just translated to QAPI. There are two reasons to have a separate schema that is not tied to the QAPI schema. The first is the contents of the schemas: the new introspection data provides different information than the QAPI data, namely unit of measurement, how the numbers are gathered and change (peak/instant/cumulative/histogram), and histogram bucket sizes. There's really no reason to have this kind of metadata in the QAPI introspection schema (except possibly for the unit of measure, but there's a very weak justification). Another reason is the dynamicity of the schema. The QAPI introspection data is very much static; and while QOM is somewhat more dynamic, generally we consider that to be a bug rather than a feature these days. On the other hand, the statistics that are exposed by QEMU might be passed through from another source, such as KVM, and the disadvantages of manually updating the QAPI schema for outweight the benefits from vetting the statistics and filtering out anything that seems "too unstable". Running old QEMU with new kernel is a supported usecase; if old QEMU cannot expose statistics from a new kernel, or if a kernel developer needs to change QEMU before gathering new info from the new kernel, then that is a poor user interface. The framework provides a method to register callbacks for these QMP commands. Most of the work in fact is done by the callbacks, and a large majority of this patch is new QAPI structs and commands. Examples (with KVM stats): - Query all VM stats: { "execute": "query-stats", "arguments" : { "target": "vm" } } { "return": [ { "provider": "kvm", "stats": [ { "name": "max_mmu_page_hash_collisions", "value": 0 }, { "name": "max_mmu_rmap_size", "value": 0 }, { "name": "nx_lpage_splits", "value": 148 }, ... ] }, { "provider": "xyz", "stats": [ ... ] } ] } - Query all vCPU stats: { "execute": "query-stats", "arguments" : { "target": "vcpu" } } { "return": [ { "provider": "kvm", "qom_path": "/machine/unattached/device[0]" "stats": [ { "name": "guest_mode", "value": 0 }, { "name": "directed_yield_successful", "value": 0 }, { "name": "directed_yield_attempted", "value": 106 }, ... ] }, { "provider": "kvm", "qom_path": "/machine/unattached/device[1]" "stats": [ { "name": "guest_mode", "value": 0 }, { "name": "directed_yield_successful", "value": 0 }, { "name": "directed_yield_attempted", "value": 106 }, ... ] }, ] } - Retrieve the schemas: { "execute": "query-stats-schemas" } { "return": [ { "provider": "kvm", "target": "vcpu", "stats": [ { "name": "guest_mode", "unit": "none", "base": 10, "exponent": 0, "type": "instant" }, { "name": "directed_yield_successful", "unit": "none", "base": 10, "exponent": 0, "type": "cumulative" }, ... ] }, { "provider": "kvm", "target": "vm", "stats": [ { "name": "max_mmu_page_hash_collisions", "unit": "none", "base": 10, "exponent": 0, "type": "peak" }, ... ] }, { "provider": "xyz", "target": "vm", "stats": [ ... ] } ] } Signed-off-by: Mark Kanda <mark.kanda@oracle.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2022-02-15 16:04:31 +01:00
# @log2-histogram: stat is a logarithmic histogram, with one bucket
# for each power of two.
qmp: Support for querying stats Gathering statistics is important for development, for monitoring and for performance measurement. There are tools such as kvm_stat that do this and they rely on the _user_ knowing the interesting data points rather than the tool (which can treat them as opaque). The commands introduced in this commit introduce QMP support for querying stats; the goal is to take the capabilities of these tools and making them available throughout the whole virtualization stack, so that one can observe, monitor and measure virtual machines without having shell access + root on the host that runs them. query-stats returns a list of all stats per target type (only VM and vCPU to start); future commits add extra options for specifying stat names, vCPU qom paths, and providers. All these are used by the HMP command "info stats". Because of the development usecases around statistics, a good HMP interface is important. query-stats-schemas returns a list of stats included in each target type, with an option for specifying the provider. The concepts in the schema are based on the KVM binary stats' own introspection data, just translated to QAPI. There are two reasons to have a separate schema that is not tied to the QAPI schema. The first is the contents of the schemas: the new introspection data provides different information than the QAPI data, namely unit of measurement, how the numbers are gathered and change (peak/instant/cumulative/histogram), and histogram bucket sizes. There's really no reason to have this kind of metadata in the QAPI introspection schema (except possibly for the unit of measure, but there's a very weak justification). Another reason is the dynamicity of the schema. The QAPI introspection data is very much static; and while QOM is somewhat more dynamic, generally we consider that to be a bug rather than a feature these days. On the other hand, the statistics that are exposed by QEMU might be passed through from another source, such as KVM, and the disadvantages of manually updating the QAPI schema for outweight the benefits from vetting the statistics and filtering out anything that seems "too unstable". Running old QEMU with new kernel is a supported usecase; if old QEMU cannot expose statistics from a new kernel, or if a kernel developer needs to change QEMU before gathering new info from the new kernel, then that is a poor user interface. The framework provides a method to register callbacks for these QMP commands. Most of the work in fact is done by the callbacks, and a large majority of this patch is new QAPI structs and commands. Examples (with KVM stats): - Query all VM stats: { "execute": "query-stats", "arguments" : { "target": "vm" } } { "return": [ { "provider": "kvm", "stats": [ { "name": "max_mmu_page_hash_collisions", "value": 0 }, { "name": "max_mmu_rmap_size", "value": 0 }, { "name": "nx_lpage_splits", "value": 148 }, ... ] }, { "provider": "xyz", "stats": [ ... ] } ] } - Query all vCPU stats: { "execute": "query-stats", "arguments" : { "target": "vcpu" } } { "return": [ { "provider": "kvm", "qom_path": "/machine/unattached/device[0]" "stats": [ { "name": "guest_mode", "value": 0 }, { "name": "directed_yield_successful", "value": 0 }, { "name": "directed_yield_attempted", "value": 106 }, ... ] }, { "provider": "kvm", "qom_path": "/machine/unattached/device[1]" "stats": [ { "name": "guest_mode", "value": 0 }, { "name": "directed_yield_successful", "value": 0 }, { "name": "directed_yield_attempted", "value": 106 }, ... ] }, ] } - Retrieve the schemas: { "execute": "query-stats-schemas" } { "return": [ { "provider": "kvm", "target": "vcpu", "stats": [ { "name": "guest_mode", "unit": "none", "base": 10, "exponent": 0, "type": "instant" }, { "name": "directed_yield_successful", "unit": "none", "base": 10, "exponent": 0, "type": "cumulative" }, ... ] }, { "provider": "kvm", "target": "vm", "stats": [ { "name": "max_mmu_page_hash_collisions", "unit": "none", "base": 10, "exponent": 0, "type": "peak" }, ... ] }, { "provider": "xyz", "target": "vm", "stats": [ ... ] } ] } Signed-off-by: Mark Kanda <mark.kanda@oracle.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2022-02-15 16:04:31 +01:00
#
# Since: 7.1
##
{ 'enum' : 'StatsType',
'data' : [ 'cumulative', 'instant', 'peak', 'linear-histogram',
'log2-histogram' ] }
##
# @StatsUnit:
#
# Enumeration of unit of measurement for statistics
#
# @bytes: stat reported in bytes.
#
qmp: Support for querying stats Gathering statistics is important for development, for monitoring and for performance measurement. There are tools such as kvm_stat that do this and they rely on the _user_ knowing the interesting data points rather than the tool (which can treat them as opaque). The commands introduced in this commit introduce QMP support for querying stats; the goal is to take the capabilities of these tools and making them available throughout the whole virtualization stack, so that one can observe, monitor and measure virtual machines without having shell access + root on the host that runs them. query-stats returns a list of all stats per target type (only VM and vCPU to start); future commits add extra options for specifying stat names, vCPU qom paths, and providers. All these are used by the HMP command "info stats". Because of the development usecases around statistics, a good HMP interface is important. query-stats-schemas returns a list of stats included in each target type, with an option for specifying the provider. The concepts in the schema are based on the KVM binary stats' own introspection data, just translated to QAPI. There are two reasons to have a separate schema that is not tied to the QAPI schema. The first is the contents of the schemas: the new introspection data provides different information than the QAPI data, namely unit of measurement, how the numbers are gathered and change (peak/instant/cumulative/histogram), and histogram bucket sizes. There's really no reason to have this kind of metadata in the QAPI introspection schema (except possibly for the unit of measure, but there's a very weak justification). Another reason is the dynamicity of the schema. The QAPI introspection data is very much static; and while QOM is somewhat more dynamic, generally we consider that to be a bug rather than a feature these days. On the other hand, the statistics that are exposed by QEMU might be passed through from another source, such as KVM, and the disadvantages of manually updating the QAPI schema for outweight the benefits from vetting the statistics and filtering out anything that seems "too unstable". Running old QEMU with new kernel is a supported usecase; if old QEMU cannot expose statistics from a new kernel, or if a kernel developer needs to change QEMU before gathering new info from the new kernel, then that is a poor user interface. The framework provides a method to register callbacks for these QMP commands. Most of the work in fact is done by the callbacks, and a large majority of this patch is new QAPI structs and commands. Examples (with KVM stats): - Query all VM stats: { "execute": "query-stats", "arguments" : { "target": "vm" } } { "return": [ { "provider": "kvm", "stats": [ { "name": "max_mmu_page_hash_collisions", "value": 0 }, { "name": "max_mmu_rmap_size", "value": 0 }, { "name": "nx_lpage_splits", "value": 148 }, ... ] }, { "provider": "xyz", "stats": [ ... ] } ] } - Query all vCPU stats: { "execute": "query-stats", "arguments" : { "target": "vcpu" } } { "return": [ { "provider": "kvm", "qom_path": "/machine/unattached/device[0]" "stats": [ { "name": "guest_mode", "value": 0 }, { "name": "directed_yield_successful", "value": 0 }, { "name": "directed_yield_attempted", "value": 106 }, ... ] }, { "provider": "kvm", "qom_path": "/machine/unattached/device[1]" "stats": [ { "name": "guest_mode", "value": 0 }, { "name": "directed_yield_successful", "value": 0 }, { "name": "directed_yield_attempted", "value": 106 }, ... ] }, ] } - Retrieve the schemas: { "execute": "query-stats-schemas" } { "return": [ { "provider": "kvm", "target": "vcpu", "stats": [ { "name": "guest_mode", "unit": "none", "base": 10, "exponent": 0, "type": "instant" }, { "name": "directed_yield_successful", "unit": "none", "base": 10, "exponent": 0, "type": "cumulative" }, ... ] }, { "provider": "kvm", "target": "vm", "stats": [ { "name": "max_mmu_page_hash_collisions", "unit": "none", "base": 10, "exponent": 0, "type": "peak" }, ... ] }, { "provider": "xyz", "target": "vm", "stats": [ ... ] } ] } Signed-off-by: Mark Kanda <mark.kanda@oracle.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2022-02-15 16:04:31 +01:00
# @seconds: stat reported in seconds.
#
qmp: Support for querying stats Gathering statistics is important for development, for monitoring and for performance measurement. There are tools such as kvm_stat that do this and they rely on the _user_ knowing the interesting data points rather than the tool (which can treat them as opaque). The commands introduced in this commit introduce QMP support for querying stats; the goal is to take the capabilities of these tools and making them available throughout the whole virtualization stack, so that one can observe, monitor and measure virtual machines without having shell access + root on the host that runs them. query-stats returns a list of all stats per target type (only VM and vCPU to start); future commits add extra options for specifying stat names, vCPU qom paths, and providers. All these are used by the HMP command "info stats". Because of the development usecases around statistics, a good HMP interface is important. query-stats-schemas returns a list of stats included in each target type, with an option for specifying the provider. The concepts in the schema are based on the KVM binary stats' own introspection data, just translated to QAPI. There are two reasons to have a separate schema that is not tied to the QAPI schema. The first is the contents of the schemas: the new introspection data provides different information than the QAPI data, namely unit of measurement, how the numbers are gathered and change (peak/instant/cumulative/histogram), and histogram bucket sizes. There's really no reason to have this kind of metadata in the QAPI introspection schema (except possibly for the unit of measure, but there's a very weak justification). Another reason is the dynamicity of the schema. The QAPI introspection data is very much static; and while QOM is somewhat more dynamic, generally we consider that to be a bug rather than a feature these days. On the other hand, the statistics that are exposed by QEMU might be passed through from another source, such as KVM, and the disadvantages of manually updating the QAPI schema for outweight the benefits from vetting the statistics and filtering out anything that seems "too unstable". Running old QEMU with new kernel is a supported usecase; if old QEMU cannot expose statistics from a new kernel, or if a kernel developer needs to change QEMU before gathering new info from the new kernel, then that is a poor user interface. The framework provides a method to register callbacks for these QMP commands. Most of the work in fact is done by the callbacks, and a large majority of this patch is new QAPI structs and commands. Examples (with KVM stats): - Query all VM stats: { "execute": "query-stats", "arguments" : { "target": "vm" } } { "return": [ { "provider": "kvm", "stats": [ { "name": "max_mmu_page_hash_collisions", "value": 0 }, { "name": "max_mmu_rmap_size", "value": 0 }, { "name": "nx_lpage_splits", "value": 148 }, ... ] }, { "provider": "xyz", "stats": [ ... ] } ] } - Query all vCPU stats: { "execute": "query-stats", "arguments" : { "target": "vcpu" } } { "return": [ { "provider": "kvm", "qom_path": "/machine/unattached/device[0]" "stats": [ { "name": "guest_mode", "value": 0 }, { "name": "directed_yield_successful", "value": 0 }, { "name": "directed_yield_attempted", "value": 106 }, ... ] }, { "provider": "kvm", "qom_path": "/machine/unattached/device[1]" "stats": [ { "name": "guest_mode", "value": 0 }, { "name": "directed_yield_successful", "value": 0 }, { "name": "directed_yield_attempted", "value": 106 }, ... ] }, ] } - Retrieve the schemas: { "execute": "query-stats-schemas" } { "return": [ { "provider": "kvm", "target": "vcpu", "stats": [ { "name": "guest_mode", "unit": "none", "base": 10, "exponent": 0, "type": "instant" }, { "name": "directed_yield_successful", "unit": "none", "base": 10, "exponent": 0, "type": "cumulative" }, ... ] }, { "provider": "kvm", "target": "vm", "stats": [ { "name": "max_mmu_page_hash_collisions", "unit": "none", "base": 10, "exponent": 0, "type": "peak" }, ... ] }, { "provider": "xyz", "target": "vm", "stats": [ ... ] } ] } Signed-off-by: Mark Kanda <mark.kanda@oracle.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2022-02-15 16:04:31 +01:00
# @cycles: stat reported in clock cycles.
#
# @boolean: stat is a boolean value.
qmp: Support for querying stats Gathering statistics is important for development, for monitoring and for performance measurement. There are tools such as kvm_stat that do this and they rely on the _user_ knowing the interesting data points rather than the tool (which can treat them as opaque). The commands introduced in this commit introduce QMP support for querying stats; the goal is to take the capabilities of these tools and making them available throughout the whole virtualization stack, so that one can observe, monitor and measure virtual machines without having shell access + root on the host that runs them. query-stats returns a list of all stats per target type (only VM and vCPU to start); future commits add extra options for specifying stat names, vCPU qom paths, and providers. All these are used by the HMP command "info stats". Because of the development usecases around statistics, a good HMP interface is important. query-stats-schemas returns a list of stats included in each target type, with an option for specifying the provider. The concepts in the schema are based on the KVM binary stats' own introspection data, just translated to QAPI. There are two reasons to have a separate schema that is not tied to the QAPI schema. The first is the contents of the schemas: the new introspection data provides different information than the QAPI data, namely unit of measurement, how the numbers are gathered and change (peak/instant/cumulative/histogram), and histogram bucket sizes. There's really no reason to have this kind of metadata in the QAPI introspection schema (except possibly for the unit of measure, but there's a very weak justification). Another reason is the dynamicity of the schema. The QAPI introspection data is very much static; and while QOM is somewhat more dynamic, generally we consider that to be a bug rather than a feature these days. On the other hand, the statistics that are exposed by QEMU might be passed through from another source, such as KVM, and the disadvantages of manually updating the QAPI schema for outweight the benefits from vetting the statistics and filtering out anything that seems "too unstable". Running old QEMU with new kernel is a supported usecase; if old QEMU cannot expose statistics from a new kernel, or if a kernel developer needs to change QEMU before gathering new info from the new kernel, then that is a poor user interface. The framework provides a method to register callbacks for these QMP commands. Most of the work in fact is done by the callbacks, and a large majority of this patch is new QAPI structs and commands. Examples (with KVM stats): - Query all VM stats: { "execute": "query-stats", "arguments" : { "target": "vm" } } { "return": [ { "provider": "kvm", "stats": [ { "name": "max_mmu_page_hash_collisions", "value": 0 }, { "name": "max_mmu_rmap_size", "value": 0 }, { "name": "nx_lpage_splits", "value": 148 }, ... ] }, { "provider": "xyz", "stats": [ ... ] } ] } - Query all vCPU stats: { "execute": "query-stats", "arguments" : { "target": "vcpu" } } { "return": [ { "provider": "kvm", "qom_path": "/machine/unattached/device[0]" "stats": [ { "name": "guest_mode", "value": 0 }, { "name": "directed_yield_successful", "value": 0 }, { "name": "directed_yield_attempted", "value": 106 }, ... ] }, { "provider": "kvm", "qom_path": "/machine/unattached/device[1]" "stats": [ { "name": "guest_mode", "value": 0 }, { "name": "directed_yield_successful", "value": 0 }, { "name": "directed_yield_attempted", "value": 106 }, ... ] }, ] } - Retrieve the schemas: { "execute": "query-stats-schemas" } { "return": [ { "provider": "kvm", "target": "vcpu", "stats": [ { "name": "guest_mode", "unit": "none", "base": 10, "exponent": 0, "type": "instant" }, { "name": "directed_yield_successful", "unit": "none", "base": 10, "exponent": 0, "type": "cumulative" }, ... ] }, { "provider": "kvm", "target": "vm", "stats": [ { "name": "max_mmu_page_hash_collisions", "unit": "none", "base": 10, "exponent": 0, "type": "peak" }, ... ] }, { "provider": "xyz", "target": "vm", "stats": [ ... ] } ] } Signed-off-by: Mark Kanda <mark.kanda@oracle.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2022-02-15 16:04:31 +01:00
#
# Since: 7.1
##
{ 'enum' : 'StatsUnit',
'data' : [ 'bytes', 'seconds', 'cycles', 'boolean' ] }
qmp: Support for querying stats Gathering statistics is important for development, for monitoring and for performance measurement. There are tools such as kvm_stat that do this and they rely on the _user_ knowing the interesting data points rather than the tool (which can treat them as opaque). The commands introduced in this commit introduce QMP support for querying stats; the goal is to take the capabilities of these tools and making them available throughout the whole virtualization stack, so that one can observe, monitor and measure virtual machines without having shell access + root on the host that runs them. query-stats returns a list of all stats per target type (only VM and vCPU to start); future commits add extra options for specifying stat names, vCPU qom paths, and providers. All these are used by the HMP command "info stats". Because of the development usecases around statistics, a good HMP interface is important. query-stats-schemas returns a list of stats included in each target type, with an option for specifying the provider. The concepts in the schema are based on the KVM binary stats' own introspection data, just translated to QAPI. There are two reasons to have a separate schema that is not tied to the QAPI schema. The first is the contents of the schemas: the new introspection data provides different information than the QAPI data, namely unit of measurement, how the numbers are gathered and change (peak/instant/cumulative/histogram), and histogram bucket sizes. There's really no reason to have this kind of metadata in the QAPI introspection schema (except possibly for the unit of measure, but there's a very weak justification). Another reason is the dynamicity of the schema. The QAPI introspection data is very much static; and while QOM is somewhat more dynamic, generally we consider that to be a bug rather than a feature these days. On the other hand, the statistics that are exposed by QEMU might be passed through from another source, such as KVM, and the disadvantages of manually updating the QAPI schema for outweight the benefits from vetting the statistics and filtering out anything that seems "too unstable". Running old QEMU with new kernel is a supported usecase; if old QEMU cannot expose statistics from a new kernel, or if a kernel developer needs to change QEMU before gathering new info from the new kernel, then that is a poor user interface. The framework provides a method to register callbacks for these QMP commands. Most of the work in fact is done by the callbacks, and a large majority of this patch is new QAPI structs and commands. Examples (with KVM stats): - Query all VM stats: { "execute": "query-stats", "arguments" : { "target": "vm" } } { "return": [ { "provider": "kvm", "stats": [ { "name": "max_mmu_page_hash_collisions", "value": 0 }, { "name": "max_mmu_rmap_size", "value": 0 }, { "name": "nx_lpage_splits", "value": 148 }, ... ] }, { "provider": "xyz", "stats": [ ... ] } ] } - Query all vCPU stats: { "execute": "query-stats", "arguments" : { "target": "vcpu" } } { "return": [ { "provider": "kvm", "qom_path": "/machine/unattached/device[0]" "stats": [ { "name": "guest_mode", "value": 0 }, { "name": "directed_yield_successful", "value": 0 }, { "name": "directed_yield_attempted", "value": 106 }, ... ] }, { "provider": "kvm", "qom_path": "/machine/unattached/device[1]" "stats": [ { "name": "guest_mode", "value": 0 }, { "name": "directed_yield_successful", "value": 0 }, { "name": "directed_yield_attempted", "value": 106 }, ... ] }, ] } - Retrieve the schemas: { "execute": "query-stats-schemas" } { "return": [ { "provider": "kvm", "target": "vcpu", "stats": [ { "name": "guest_mode", "unit": "none", "base": 10, "exponent": 0, "type": "instant" }, { "name": "directed_yield_successful", "unit": "none", "base": 10, "exponent": 0, "type": "cumulative" }, ... ] }, { "provider": "kvm", "target": "vm", "stats": [ { "name": "max_mmu_page_hash_collisions", "unit": "none", "base": 10, "exponent": 0, "type": "peak" }, ... ] }, { "provider": "xyz", "target": "vm", "stats": [ ... ] } ] } Signed-off-by: Mark Kanda <mark.kanda@oracle.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2022-02-15 16:04:31 +01:00
##
# @StatsProvider:
#
# Enumeration of statistics providers.
#
# @kvm: since 7.1
#
# @cryptodev: since 8.0
#
qmp: Support for querying stats Gathering statistics is important for development, for monitoring and for performance measurement. There are tools such as kvm_stat that do this and they rely on the _user_ knowing the interesting data points rather than the tool (which can treat them as opaque). The commands introduced in this commit introduce QMP support for querying stats; the goal is to take the capabilities of these tools and making them available throughout the whole virtualization stack, so that one can observe, monitor and measure virtual machines without having shell access + root on the host that runs them. query-stats returns a list of all stats per target type (only VM and vCPU to start); future commits add extra options for specifying stat names, vCPU qom paths, and providers. All these are used by the HMP command "info stats". Because of the development usecases around statistics, a good HMP interface is important. query-stats-schemas returns a list of stats included in each target type, with an option for specifying the provider. The concepts in the schema are based on the KVM binary stats' own introspection data, just translated to QAPI. There are two reasons to have a separate schema that is not tied to the QAPI schema. The first is the contents of the schemas: the new introspection data provides different information than the QAPI data, namely unit of measurement, how the numbers are gathered and change (peak/instant/cumulative/histogram), and histogram bucket sizes. There's really no reason to have this kind of metadata in the QAPI introspection schema (except possibly for the unit of measure, but there's a very weak justification). Another reason is the dynamicity of the schema. The QAPI introspection data is very much static; and while QOM is somewhat more dynamic, generally we consider that to be a bug rather than a feature these days. On the other hand, the statistics that are exposed by QEMU might be passed through from another source, such as KVM, and the disadvantages of manually updating the QAPI schema for outweight the benefits from vetting the statistics and filtering out anything that seems "too unstable". Running old QEMU with new kernel is a supported usecase; if old QEMU cannot expose statistics from a new kernel, or if a kernel developer needs to change QEMU before gathering new info from the new kernel, then that is a poor user interface. The framework provides a method to register callbacks for these QMP commands. Most of the work in fact is done by the callbacks, and a large majority of this patch is new QAPI structs and commands. Examples (with KVM stats): - Query all VM stats: { "execute": "query-stats", "arguments" : { "target": "vm" } } { "return": [ { "provider": "kvm", "stats": [ { "name": "max_mmu_page_hash_collisions", "value": 0 }, { "name": "max_mmu_rmap_size", "value": 0 }, { "name": "nx_lpage_splits", "value": 148 }, ... ] }, { "provider": "xyz", "stats": [ ... ] } ] } - Query all vCPU stats: { "execute": "query-stats", "arguments" : { "target": "vcpu" } } { "return": [ { "provider": "kvm", "qom_path": "/machine/unattached/device[0]" "stats": [ { "name": "guest_mode", "value": 0 }, { "name": "directed_yield_successful", "value": 0 }, { "name": "directed_yield_attempted", "value": 106 }, ... ] }, { "provider": "kvm", "qom_path": "/machine/unattached/device[1]" "stats": [ { "name": "guest_mode", "value": 0 }, { "name": "directed_yield_successful", "value": 0 }, { "name": "directed_yield_attempted", "value": 106 }, ... ] }, ] } - Retrieve the schemas: { "execute": "query-stats-schemas" } { "return": [ { "provider": "kvm", "target": "vcpu", "stats": [ { "name": "guest_mode", "unit": "none", "base": 10, "exponent": 0, "type": "instant" }, { "name": "directed_yield_successful", "unit": "none", "base": 10, "exponent": 0, "type": "cumulative" }, ... ] }, { "provider": "kvm", "target": "vm", "stats": [ { "name": "max_mmu_page_hash_collisions", "unit": "none", "base": 10, "exponent": 0, "type": "peak" }, ... ] }, { "provider": "xyz", "target": "vm", "stats": [ ... ] } ] } Signed-off-by: Mark Kanda <mark.kanda@oracle.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2022-02-15 16:04:31 +01:00
# Since: 7.1
##
{ 'enum': 'StatsProvider',
'data': [ 'kvm', 'cryptodev' ] }
qmp: Support for querying stats Gathering statistics is important for development, for monitoring and for performance measurement. There are tools such as kvm_stat that do this and they rely on the _user_ knowing the interesting data points rather than the tool (which can treat them as opaque). The commands introduced in this commit introduce QMP support for querying stats; the goal is to take the capabilities of these tools and making them available throughout the whole virtualization stack, so that one can observe, monitor and measure virtual machines without having shell access + root on the host that runs them. query-stats returns a list of all stats per target type (only VM and vCPU to start); future commits add extra options for specifying stat names, vCPU qom paths, and providers. All these are used by the HMP command "info stats". Because of the development usecases around statistics, a good HMP interface is important. query-stats-schemas returns a list of stats included in each target type, with an option for specifying the provider. The concepts in the schema are based on the KVM binary stats' own introspection data, just translated to QAPI. There are two reasons to have a separate schema that is not tied to the QAPI schema. The first is the contents of the schemas: the new introspection data provides different information than the QAPI data, namely unit of measurement, how the numbers are gathered and change (peak/instant/cumulative/histogram), and histogram bucket sizes. There's really no reason to have this kind of metadata in the QAPI introspection schema (except possibly for the unit of measure, but there's a very weak justification). Another reason is the dynamicity of the schema. The QAPI introspection data is very much static; and while QOM is somewhat more dynamic, generally we consider that to be a bug rather than a feature these days. On the other hand, the statistics that are exposed by QEMU might be passed through from another source, such as KVM, and the disadvantages of manually updating the QAPI schema for outweight the benefits from vetting the statistics and filtering out anything that seems "too unstable". Running old QEMU with new kernel is a supported usecase; if old QEMU cannot expose statistics from a new kernel, or if a kernel developer needs to change QEMU before gathering new info from the new kernel, then that is a poor user interface. The framework provides a method to register callbacks for these QMP commands. Most of the work in fact is done by the callbacks, and a large majority of this patch is new QAPI structs and commands. Examples (with KVM stats): - Query all VM stats: { "execute": "query-stats", "arguments" : { "target": "vm" } } { "return": [ { "provider": "kvm", "stats": [ { "name": "max_mmu_page_hash_collisions", "value": 0 }, { "name": "max_mmu_rmap_size", "value": 0 }, { "name": "nx_lpage_splits", "value": 148 }, ... ] }, { "provider": "xyz", "stats": [ ... ] } ] } - Query all vCPU stats: { "execute": "query-stats", "arguments" : { "target": "vcpu" } } { "return": [ { "provider": "kvm", "qom_path": "/machine/unattached/device[0]" "stats": [ { "name": "guest_mode", "value": 0 }, { "name": "directed_yield_successful", "value": 0 }, { "name": "directed_yield_attempted", "value": 106 }, ... ] }, { "provider": "kvm", "qom_path": "/machine/unattached/device[1]" "stats": [ { "name": "guest_mode", "value": 0 }, { "name": "directed_yield_successful", "value": 0 }, { "name": "directed_yield_attempted", "value": 106 }, ... ] }, ] } - Retrieve the schemas: { "execute": "query-stats-schemas" } { "return": [ { "provider": "kvm", "target": "vcpu", "stats": [ { "name": "guest_mode", "unit": "none", "base": 10, "exponent": 0, "type": "instant" }, { "name": "directed_yield_successful", "unit": "none", "base": 10, "exponent": 0, "type": "cumulative" }, ... ] }, { "provider": "kvm", "target": "vm", "stats": [ { "name": "max_mmu_page_hash_collisions", "unit": "none", "base": 10, "exponent": 0, "type": "peak" }, ... ] }, { "provider": "xyz", "target": "vm", "stats": [ ... ] } ] } Signed-off-by: Mark Kanda <mark.kanda@oracle.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2022-02-15 16:04:31 +01:00
##
# @StatsTarget:
#
# The kinds of objects on which one can request statistics.
#
# @vm: statistics that apply to the entire virtual machine or the
# entire QEMU process.
qmp: Support for querying stats Gathering statistics is important for development, for monitoring and for performance measurement. There are tools such as kvm_stat that do this and they rely on the _user_ knowing the interesting data points rather than the tool (which can treat them as opaque). The commands introduced in this commit introduce QMP support for querying stats; the goal is to take the capabilities of these tools and making them available throughout the whole virtualization stack, so that one can observe, monitor and measure virtual machines without having shell access + root on the host that runs them. query-stats returns a list of all stats per target type (only VM and vCPU to start); future commits add extra options for specifying stat names, vCPU qom paths, and providers. All these are used by the HMP command "info stats". Because of the development usecases around statistics, a good HMP interface is important. query-stats-schemas returns a list of stats included in each target type, with an option for specifying the provider. The concepts in the schema are based on the KVM binary stats' own introspection data, just translated to QAPI. There are two reasons to have a separate schema that is not tied to the QAPI schema. The first is the contents of the schemas: the new introspection data provides different information than the QAPI data, namely unit of measurement, how the numbers are gathered and change (peak/instant/cumulative/histogram), and histogram bucket sizes. There's really no reason to have this kind of metadata in the QAPI introspection schema (except possibly for the unit of measure, but there's a very weak justification). Another reason is the dynamicity of the schema. The QAPI introspection data is very much static; and while QOM is somewhat more dynamic, generally we consider that to be a bug rather than a feature these days. On the other hand, the statistics that are exposed by QEMU might be passed through from another source, such as KVM, and the disadvantages of manually updating the QAPI schema for outweight the benefits from vetting the statistics and filtering out anything that seems "too unstable". Running old QEMU with new kernel is a supported usecase; if old QEMU cannot expose statistics from a new kernel, or if a kernel developer needs to change QEMU before gathering new info from the new kernel, then that is a poor user interface. The framework provides a method to register callbacks for these QMP commands. Most of the work in fact is done by the callbacks, and a large majority of this patch is new QAPI structs and commands. Examples (with KVM stats): - Query all VM stats: { "execute": "query-stats", "arguments" : { "target": "vm" } } { "return": [ { "provider": "kvm", "stats": [ { "name": "max_mmu_page_hash_collisions", "value": 0 }, { "name": "max_mmu_rmap_size", "value": 0 }, { "name": "nx_lpage_splits", "value": 148 }, ... ] }, { "provider": "xyz", "stats": [ ... ] } ] } - Query all vCPU stats: { "execute": "query-stats", "arguments" : { "target": "vcpu" } } { "return": [ { "provider": "kvm", "qom_path": "/machine/unattached/device[0]" "stats": [ { "name": "guest_mode", "value": 0 }, { "name": "directed_yield_successful", "value": 0 }, { "name": "directed_yield_attempted", "value": 106 }, ... ] }, { "provider": "kvm", "qom_path": "/machine/unattached/device[1]" "stats": [ { "name": "guest_mode", "value": 0 }, { "name": "directed_yield_successful", "value": 0 }, { "name": "directed_yield_attempted", "value": 106 }, ... ] }, ] } - Retrieve the schemas: { "execute": "query-stats-schemas" } { "return": [ { "provider": "kvm", "target": "vcpu", "stats": [ { "name": "guest_mode", "unit": "none", "base": 10, "exponent": 0, "type": "instant" }, { "name": "directed_yield_successful", "unit": "none", "base": 10, "exponent": 0, "type": "cumulative" }, ... ] }, { "provider": "kvm", "target": "vm", "stats": [ { "name": "max_mmu_page_hash_collisions", "unit": "none", "base": 10, "exponent": 0, "type": "peak" }, ... ] }, { "provider": "xyz", "target": "vm", "stats": [ ... ] } ] } Signed-off-by: Mark Kanda <mark.kanda@oracle.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2022-02-15 16:04:31 +01:00
#
# @vcpu: statistics that apply to a single virtual CPU.
#
# @cryptodev: statistics that apply to a crypto device (since 8.0)
#
qmp: Support for querying stats Gathering statistics is important for development, for monitoring and for performance measurement. There are tools such as kvm_stat that do this and they rely on the _user_ knowing the interesting data points rather than the tool (which can treat them as opaque). The commands introduced in this commit introduce QMP support for querying stats; the goal is to take the capabilities of these tools and making them available throughout the whole virtualization stack, so that one can observe, monitor and measure virtual machines without having shell access + root on the host that runs them. query-stats returns a list of all stats per target type (only VM and vCPU to start); future commits add extra options for specifying stat names, vCPU qom paths, and providers. All these are used by the HMP command "info stats". Because of the development usecases around statistics, a good HMP interface is important. query-stats-schemas returns a list of stats included in each target type, with an option for specifying the provider. The concepts in the schema are based on the KVM binary stats' own introspection data, just translated to QAPI. There are two reasons to have a separate schema that is not tied to the QAPI schema. The first is the contents of the schemas: the new introspection data provides different information than the QAPI data, namely unit of measurement, how the numbers are gathered and change (peak/instant/cumulative/histogram), and histogram bucket sizes. There's really no reason to have this kind of metadata in the QAPI introspection schema (except possibly for the unit of measure, but there's a very weak justification). Another reason is the dynamicity of the schema. The QAPI introspection data is very much static; and while QOM is somewhat more dynamic, generally we consider that to be a bug rather than a feature these days. On the other hand, the statistics that are exposed by QEMU might be passed through from another source, such as KVM, and the disadvantages of manually updating the QAPI schema for outweight the benefits from vetting the statistics and filtering out anything that seems "too unstable". Running old QEMU with new kernel is a supported usecase; if old QEMU cannot expose statistics from a new kernel, or if a kernel developer needs to change QEMU before gathering new info from the new kernel, then that is a poor user interface. The framework provides a method to register callbacks for these QMP commands. Most of the work in fact is done by the callbacks, and a large majority of this patch is new QAPI structs and commands. Examples (with KVM stats): - Query all VM stats: { "execute": "query-stats", "arguments" : { "target": "vm" } } { "return": [ { "provider": "kvm", "stats": [ { "name": "max_mmu_page_hash_collisions", "value": 0 }, { "name": "max_mmu_rmap_size", "value": 0 }, { "name": "nx_lpage_splits", "value": 148 }, ... ] }, { "provider": "xyz", "stats": [ ... ] } ] } - Query all vCPU stats: { "execute": "query-stats", "arguments" : { "target": "vcpu" } } { "return": [ { "provider": "kvm", "qom_path": "/machine/unattached/device[0]" "stats": [ { "name": "guest_mode", "value": 0 }, { "name": "directed_yield_successful", "value": 0 }, { "name": "directed_yield_attempted", "value": 106 }, ... ] }, { "provider": "kvm", "qom_path": "/machine/unattached/device[1]" "stats": [ { "name": "guest_mode", "value": 0 }, { "name": "directed_yield_successful", "value": 0 }, { "name": "directed_yield_attempted", "value": 106 }, ... ] }, ] } - Retrieve the schemas: { "execute": "query-stats-schemas" } { "return": [ { "provider": "kvm", "target": "vcpu", "stats": [ { "name": "guest_mode", "unit": "none", "base": 10, "exponent": 0, "type": "instant" }, { "name": "directed_yield_successful", "unit": "none", "base": 10, "exponent": 0, "type": "cumulative" }, ... ] }, { "provider": "kvm", "target": "vm", "stats": [ { "name": "max_mmu_page_hash_collisions", "unit": "none", "base": 10, "exponent": 0, "type": "peak" }, ... ] }, { "provider": "xyz", "target": "vm", "stats": [ ... ] } ] } Signed-off-by: Mark Kanda <mark.kanda@oracle.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2022-02-15 16:04:31 +01:00
# Since: 7.1
##
{ 'enum': 'StatsTarget',
'data': [ 'vm', 'vcpu', 'cryptodev' ] }
qmp: Support for querying stats Gathering statistics is important for development, for monitoring and for performance measurement. There are tools such as kvm_stat that do this and they rely on the _user_ knowing the interesting data points rather than the tool (which can treat them as opaque). The commands introduced in this commit introduce QMP support for querying stats; the goal is to take the capabilities of these tools and making them available throughout the whole virtualization stack, so that one can observe, monitor and measure virtual machines without having shell access + root on the host that runs them. query-stats returns a list of all stats per target type (only VM and vCPU to start); future commits add extra options for specifying stat names, vCPU qom paths, and providers. All these are used by the HMP command "info stats". Because of the development usecases around statistics, a good HMP interface is important. query-stats-schemas returns a list of stats included in each target type, with an option for specifying the provider. The concepts in the schema are based on the KVM binary stats' own introspection data, just translated to QAPI. There are two reasons to have a separate schema that is not tied to the QAPI schema. The first is the contents of the schemas: the new introspection data provides different information than the QAPI data, namely unit of measurement, how the numbers are gathered and change (peak/instant/cumulative/histogram), and histogram bucket sizes. There's really no reason to have this kind of metadata in the QAPI introspection schema (except possibly for the unit of measure, but there's a very weak justification). Another reason is the dynamicity of the schema. The QAPI introspection data is very much static; and while QOM is somewhat more dynamic, generally we consider that to be a bug rather than a feature these days. On the other hand, the statistics that are exposed by QEMU might be passed through from another source, such as KVM, and the disadvantages of manually updating the QAPI schema for outweight the benefits from vetting the statistics and filtering out anything that seems "too unstable". Running old QEMU with new kernel is a supported usecase; if old QEMU cannot expose statistics from a new kernel, or if a kernel developer needs to change QEMU before gathering new info from the new kernel, then that is a poor user interface. The framework provides a method to register callbacks for these QMP commands. Most of the work in fact is done by the callbacks, and a large majority of this patch is new QAPI structs and commands. Examples (with KVM stats): - Query all VM stats: { "execute": "query-stats", "arguments" : { "target": "vm" } } { "return": [ { "provider": "kvm", "stats": [ { "name": "max_mmu_page_hash_collisions", "value": 0 }, { "name": "max_mmu_rmap_size", "value": 0 }, { "name": "nx_lpage_splits", "value": 148 }, ... ] }, { "provider": "xyz", "stats": [ ... ] } ] } - Query all vCPU stats: { "execute": "query-stats", "arguments" : { "target": "vcpu" } } { "return": [ { "provider": "kvm", "qom_path": "/machine/unattached/device[0]" "stats": [ { "name": "guest_mode", "value": 0 }, { "name": "directed_yield_successful", "value": 0 }, { "name": "directed_yield_attempted", "value": 106 }, ... ] }, { "provider": "kvm", "qom_path": "/machine/unattached/device[1]" "stats": [ { "name": "guest_mode", "value": 0 }, { "name": "directed_yield_successful", "value": 0 }, { "name": "directed_yield_attempted", "value": 106 }, ... ] }, ] } - Retrieve the schemas: { "execute": "query-stats-schemas" } { "return": [ { "provider": "kvm", "target": "vcpu", "stats": [ { "name": "guest_mode", "unit": "none", "base": 10, "exponent": 0, "type": "instant" }, { "name": "directed_yield_successful", "unit": "none", "base": 10, "exponent": 0, "type": "cumulative" }, ... ] }, { "provider": "kvm", "target": "vm", "stats": [ { "name": "max_mmu_page_hash_collisions", "unit": "none", "base": 10, "exponent": 0, "type": "peak" }, ... ] }, { "provider": "xyz", "target": "vm", "stats": [ ... ] } ] } Signed-off-by: Mark Kanda <mark.kanda@oracle.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2022-02-15 16:04:31 +01:00
##
# @StatsRequest:
#
# Indicates a set of statistics that should be returned by
# query-stats.
#
# @provider: provider for which to return statistics.
#
# @names: statistics to be returned (all if omitted).
#
# Since: 7.1
##
{ 'struct': 'StatsRequest',
'data': { 'provider': 'StatsProvider',
'*names': [ 'str' ] } }
##
# @StatsVCPUFilter:
#
# @vcpus: list of QOM paths for the desired vCPU objects.
#
# Since: 7.1
##
{ 'struct': 'StatsVCPUFilter',
'data': { '*vcpus': [ 'str' ] } }
qmp: Support for querying stats Gathering statistics is important for development, for monitoring and for performance measurement. There are tools such as kvm_stat that do this and they rely on the _user_ knowing the interesting data points rather than the tool (which can treat them as opaque). The commands introduced in this commit introduce QMP support for querying stats; the goal is to take the capabilities of these tools and making them available throughout the whole virtualization stack, so that one can observe, monitor and measure virtual machines without having shell access + root on the host that runs them. query-stats returns a list of all stats per target type (only VM and vCPU to start); future commits add extra options for specifying stat names, vCPU qom paths, and providers. All these are used by the HMP command "info stats". Because of the development usecases around statistics, a good HMP interface is important. query-stats-schemas returns a list of stats included in each target type, with an option for specifying the provider. The concepts in the schema are based on the KVM binary stats' own introspection data, just translated to QAPI. There are two reasons to have a separate schema that is not tied to the QAPI schema. The first is the contents of the schemas: the new introspection data provides different information than the QAPI data, namely unit of measurement, how the numbers are gathered and change (peak/instant/cumulative/histogram), and histogram bucket sizes. There's really no reason to have this kind of metadata in the QAPI introspection schema (except possibly for the unit of measure, but there's a very weak justification). Another reason is the dynamicity of the schema. The QAPI introspection data is very much static; and while QOM is somewhat more dynamic, generally we consider that to be a bug rather than a feature these days. On the other hand, the statistics that are exposed by QEMU might be passed through from another source, such as KVM, and the disadvantages of manually updating the QAPI schema for outweight the benefits from vetting the statistics and filtering out anything that seems "too unstable". Running old QEMU with new kernel is a supported usecase; if old QEMU cannot expose statistics from a new kernel, or if a kernel developer needs to change QEMU before gathering new info from the new kernel, then that is a poor user interface. The framework provides a method to register callbacks for these QMP commands. Most of the work in fact is done by the callbacks, and a large majority of this patch is new QAPI structs and commands. Examples (with KVM stats): - Query all VM stats: { "execute": "query-stats", "arguments" : { "target": "vm" } } { "return": [ { "provider": "kvm", "stats": [ { "name": "max_mmu_page_hash_collisions", "value": 0 }, { "name": "max_mmu_rmap_size", "value": 0 }, { "name": "nx_lpage_splits", "value": 148 }, ... ] }, { "provider": "xyz", "stats": [ ... ] } ] } - Query all vCPU stats: { "execute": "query-stats", "arguments" : { "target": "vcpu" } } { "return": [ { "provider": "kvm", "qom_path": "/machine/unattached/device[0]" "stats": [ { "name": "guest_mode", "value": 0 }, { "name": "directed_yield_successful", "value": 0 }, { "name": "directed_yield_attempted", "value": 106 }, ... ] }, { "provider": "kvm", "qom_path": "/machine/unattached/device[1]" "stats": [ { "name": "guest_mode", "value": 0 }, { "name": "directed_yield_successful", "value": 0 }, { "name": "directed_yield_attempted", "value": 106 }, ... ] }, ] } - Retrieve the schemas: { "execute": "query-stats-schemas" } { "return": [ { "provider": "kvm", "target": "vcpu", "stats": [ { "name": "guest_mode", "unit": "none", "base": 10, "exponent": 0, "type": "instant" }, { "name": "directed_yield_successful", "unit": "none", "base": 10, "exponent": 0, "type": "cumulative" }, ... ] }, { "provider": "kvm", "target": "vm", "stats": [ { "name": "max_mmu_page_hash_collisions", "unit": "none", "base": 10, "exponent": 0, "type": "peak" }, ... ] }, { "provider": "xyz", "target": "vm", "stats": [ ... ] } ] } Signed-off-by: Mark Kanda <mark.kanda@oracle.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2022-02-15 16:04:31 +01:00
##
# @StatsFilter:
#
# The arguments to the query-stats command; specifies a target for
# which to request statistics and optionally the required subset of
# information for that target:
#
# - which vCPUs to request statistics for
# - which providers to request statistics from
# - which named values to return within each provider
qmp: Support for querying stats Gathering statistics is important for development, for monitoring and for performance measurement. There are tools such as kvm_stat that do this and they rely on the _user_ knowing the interesting data points rather than the tool (which can treat them as opaque). The commands introduced in this commit introduce QMP support for querying stats; the goal is to take the capabilities of these tools and making them available throughout the whole virtualization stack, so that one can observe, monitor and measure virtual machines without having shell access + root on the host that runs them. query-stats returns a list of all stats per target type (only VM and vCPU to start); future commits add extra options for specifying stat names, vCPU qom paths, and providers. All these are used by the HMP command "info stats". Because of the development usecases around statistics, a good HMP interface is important. query-stats-schemas returns a list of stats included in each target type, with an option for specifying the provider. The concepts in the schema are based on the KVM binary stats' own introspection data, just translated to QAPI. There are two reasons to have a separate schema that is not tied to the QAPI schema. The first is the contents of the schemas: the new introspection data provides different information than the QAPI data, namely unit of measurement, how the numbers are gathered and change (peak/instant/cumulative/histogram), and histogram bucket sizes. There's really no reason to have this kind of metadata in the QAPI introspection schema (except possibly for the unit of measure, but there's a very weak justification). Another reason is the dynamicity of the schema. The QAPI introspection data is very much static; and while QOM is somewhat more dynamic, generally we consider that to be a bug rather than a feature these days. On the other hand, the statistics that are exposed by QEMU might be passed through from another source, such as KVM, and the disadvantages of manually updating the QAPI schema for outweight the benefits from vetting the statistics and filtering out anything that seems "too unstable". Running old QEMU with new kernel is a supported usecase; if old QEMU cannot expose statistics from a new kernel, or if a kernel developer needs to change QEMU before gathering new info from the new kernel, then that is a poor user interface. The framework provides a method to register callbacks for these QMP commands. Most of the work in fact is done by the callbacks, and a large majority of this patch is new QAPI structs and commands. Examples (with KVM stats): - Query all VM stats: { "execute": "query-stats", "arguments" : { "target": "vm" } } { "return": [ { "provider": "kvm", "stats": [ { "name": "max_mmu_page_hash_collisions", "value": 0 }, { "name": "max_mmu_rmap_size", "value": 0 }, { "name": "nx_lpage_splits", "value": 148 }, ... ] }, { "provider": "xyz", "stats": [ ... ] } ] } - Query all vCPU stats: { "execute": "query-stats", "arguments" : { "target": "vcpu" } } { "return": [ { "provider": "kvm", "qom_path": "/machine/unattached/device[0]" "stats": [ { "name": "guest_mode", "value": 0 }, { "name": "directed_yield_successful", "value": 0 }, { "name": "directed_yield_attempted", "value": 106 }, ... ] }, { "provider": "kvm", "qom_path": "/machine/unattached/device[1]" "stats": [ { "name": "guest_mode", "value": 0 }, { "name": "directed_yield_successful", "value": 0 }, { "name": "directed_yield_attempted", "value": 106 }, ... ] }, ] } - Retrieve the schemas: { "execute": "query-stats-schemas" } { "return": [ { "provider": "kvm", "target": "vcpu", "stats": [ { "name": "guest_mode", "unit": "none", "base": 10, "exponent": 0, "type": "instant" }, { "name": "directed_yield_successful", "unit": "none", "base": 10, "exponent": 0, "type": "cumulative" }, ... ] }, { "provider": "kvm", "target": "vm", "stats": [ { "name": "max_mmu_page_hash_collisions", "unit": "none", "base": 10, "exponent": 0, "type": "peak" }, ... ] }, { "provider": "xyz", "target": "vm", "stats": [ ... ] } ] } Signed-off-by: Mark Kanda <mark.kanda@oracle.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2022-02-15 16:04:31 +01:00
#
# Since: 7.1
##
{ 'union': 'StatsFilter',
'base': {
'target': 'StatsTarget',
'*providers': [ 'StatsRequest' ] },
'discriminator': 'target',
'data': { 'vcpu': 'StatsVCPUFilter' } }
qmp: Support for querying stats Gathering statistics is important for development, for monitoring and for performance measurement. There are tools such as kvm_stat that do this and they rely on the _user_ knowing the interesting data points rather than the tool (which can treat them as opaque). The commands introduced in this commit introduce QMP support for querying stats; the goal is to take the capabilities of these tools and making them available throughout the whole virtualization stack, so that one can observe, monitor and measure virtual machines without having shell access + root on the host that runs them. query-stats returns a list of all stats per target type (only VM and vCPU to start); future commits add extra options for specifying stat names, vCPU qom paths, and providers. All these are used by the HMP command "info stats". Because of the development usecases around statistics, a good HMP interface is important. query-stats-schemas returns a list of stats included in each target type, with an option for specifying the provider. The concepts in the schema are based on the KVM binary stats' own introspection data, just translated to QAPI. There are two reasons to have a separate schema that is not tied to the QAPI schema. The first is the contents of the schemas: the new introspection data provides different information than the QAPI data, namely unit of measurement, how the numbers are gathered and change (peak/instant/cumulative/histogram), and histogram bucket sizes. There's really no reason to have this kind of metadata in the QAPI introspection schema (except possibly for the unit of measure, but there's a very weak justification). Another reason is the dynamicity of the schema. The QAPI introspection data is very much static; and while QOM is somewhat more dynamic, generally we consider that to be a bug rather than a feature these days. On the other hand, the statistics that are exposed by QEMU might be passed through from another source, such as KVM, and the disadvantages of manually updating the QAPI schema for outweight the benefits from vetting the statistics and filtering out anything that seems "too unstable". Running old QEMU with new kernel is a supported usecase; if old QEMU cannot expose statistics from a new kernel, or if a kernel developer needs to change QEMU before gathering new info from the new kernel, then that is a poor user interface. The framework provides a method to register callbacks for these QMP commands. Most of the work in fact is done by the callbacks, and a large majority of this patch is new QAPI structs and commands. Examples (with KVM stats): - Query all VM stats: { "execute": "query-stats", "arguments" : { "target": "vm" } } { "return": [ { "provider": "kvm", "stats": [ { "name": "max_mmu_page_hash_collisions", "value": 0 }, { "name": "max_mmu_rmap_size", "value": 0 }, { "name": "nx_lpage_splits", "value": 148 }, ... ] }, { "provider": "xyz", "stats": [ ... ] } ] } - Query all vCPU stats: { "execute": "query-stats", "arguments" : { "target": "vcpu" } } { "return": [ { "provider": "kvm", "qom_path": "/machine/unattached/device[0]" "stats": [ { "name": "guest_mode", "value": 0 }, { "name": "directed_yield_successful", "value": 0 }, { "name": "directed_yield_attempted", "value": 106 }, ... ] }, { "provider": "kvm", "qom_path": "/machine/unattached/device[1]" "stats": [ { "name": "guest_mode", "value": 0 }, { "name": "directed_yield_successful", "value": 0 }, { "name": "directed_yield_attempted", "value": 106 }, ... ] }, ] } - Retrieve the schemas: { "execute": "query-stats-schemas" } { "return": [ { "provider": "kvm", "target": "vcpu", "stats": [ { "name": "guest_mode", "unit": "none", "base": 10, "exponent": 0, "type": "instant" }, { "name": "directed_yield_successful", "unit": "none", "base": 10, "exponent": 0, "type": "cumulative" }, ... ] }, { "provider": "kvm", "target": "vm", "stats": [ { "name": "max_mmu_page_hash_collisions", "unit": "none", "base": 10, "exponent": 0, "type": "peak" }, ... ] }, { "provider": "xyz", "target": "vm", "stats": [ ... ] } ] } Signed-off-by: Mark Kanda <mark.kanda@oracle.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2022-02-15 16:04:31 +01:00
##
# @StatsValue:
#
# @scalar: single unsigned 64-bit integers.
#
qmp: Support for querying stats Gathering statistics is important for development, for monitoring and for performance measurement. There are tools such as kvm_stat that do this and they rely on the _user_ knowing the interesting data points rather than the tool (which can treat them as opaque). The commands introduced in this commit introduce QMP support for querying stats; the goal is to take the capabilities of these tools and making them available throughout the whole virtualization stack, so that one can observe, monitor and measure virtual machines without having shell access + root on the host that runs them. query-stats returns a list of all stats per target type (only VM and vCPU to start); future commits add extra options for specifying stat names, vCPU qom paths, and providers. All these are used by the HMP command "info stats". Because of the development usecases around statistics, a good HMP interface is important. query-stats-schemas returns a list of stats included in each target type, with an option for specifying the provider. The concepts in the schema are based on the KVM binary stats' own introspection data, just translated to QAPI. There are two reasons to have a separate schema that is not tied to the QAPI schema. The first is the contents of the schemas: the new introspection data provides different information than the QAPI data, namely unit of measurement, how the numbers are gathered and change (peak/instant/cumulative/histogram), and histogram bucket sizes. There's really no reason to have this kind of metadata in the QAPI introspection schema (except possibly for the unit of measure, but there's a very weak justification). Another reason is the dynamicity of the schema. The QAPI introspection data is very much static; and while QOM is somewhat more dynamic, generally we consider that to be a bug rather than a feature these days. On the other hand, the statistics that are exposed by QEMU might be passed through from another source, such as KVM, and the disadvantages of manually updating the QAPI schema for outweight the benefits from vetting the statistics and filtering out anything that seems "too unstable". Running old QEMU with new kernel is a supported usecase; if old QEMU cannot expose statistics from a new kernel, or if a kernel developer needs to change QEMU before gathering new info from the new kernel, then that is a poor user interface. The framework provides a method to register callbacks for these QMP commands. Most of the work in fact is done by the callbacks, and a large majority of this patch is new QAPI structs and commands. Examples (with KVM stats): - Query all VM stats: { "execute": "query-stats", "arguments" : { "target": "vm" } } { "return": [ { "provider": "kvm", "stats": [ { "name": "max_mmu_page_hash_collisions", "value": 0 }, { "name": "max_mmu_rmap_size", "value": 0 }, { "name": "nx_lpage_splits", "value": 148 }, ... ] }, { "provider": "xyz", "stats": [ ... ] } ] } - Query all vCPU stats: { "execute": "query-stats", "arguments" : { "target": "vcpu" } } { "return": [ { "provider": "kvm", "qom_path": "/machine/unattached/device[0]" "stats": [ { "name": "guest_mode", "value": 0 }, { "name": "directed_yield_successful", "value": 0 }, { "name": "directed_yield_attempted", "value": 106 }, ... ] }, { "provider": "kvm", "qom_path": "/machine/unattached/device[1]" "stats": [ { "name": "guest_mode", "value": 0 }, { "name": "directed_yield_successful", "value": 0 }, { "name": "directed_yield_attempted", "value": 106 }, ... ] }, ] } - Retrieve the schemas: { "execute": "query-stats-schemas" } { "return": [ { "provider": "kvm", "target": "vcpu", "stats": [ { "name": "guest_mode", "unit": "none", "base": 10, "exponent": 0, "type": "instant" }, { "name": "directed_yield_successful", "unit": "none", "base": 10, "exponent": 0, "type": "cumulative" }, ... ] }, { "provider": "kvm", "target": "vm", "stats": [ { "name": "max_mmu_page_hash_collisions", "unit": "none", "base": 10, "exponent": 0, "type": "peak" }, ... ] }, { "provider": "xyz", "target": "vm", "stats": [ ... ] } ] } Signed-off-by: Mark Kanda <mark.kanda@oracle.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2022-02-15 16:04:31 +01:00
# @list: list of unsigned 64-bit integers (used for histograms).
#
# Since: 7.1
##
{ 'alternate': 'StatsValue',
'data': { 'scalar': 'uint64',
'boolean': 'bool',
qmp: Support for querying stats Gathering statistics is important for development, for monitoring and for performance measurement. There are tools such as kvm_stat that do this and they rely on the _user_ knowing the interesting data points rather than the tool (which can treat them as opaque). The commands introduced in this commit introduce QMP support for querying stats; the goal is to take the capabilities of these tools and making them available throughout the whole virtualization stack, so that one can observe, monitor and measure virtual machines without having shell access + root on the host that runs them. query-stats returns a list of all stats per target type (only VM and vCPU to start); future commits add extra options for specifying stat names, vCPU qom paths, and providers. All these are used by the HMP command "info stats". Because of the development usecases around statistics, a good HMP interface is important. query-stats-schemas returns a list of stats included in each target type, with an option for specifying the provider. The concepts in the schema are based on the KVM binary stats' own introspection data, just translated to QAPI. There are two reasons to have a separate schema that is not tied to the QAPI schema. The first is the contents of the schemas: the new introspection data provides different information than the QAPI data, namely unit of measurement, how the numbers are gathered and change (peak/instant/cumulative/histogram), and histogram bucket sizes. There's really no reason to have this kind of metadata in the QAPI introspection schema (except possibly for the unit of measure, but there's a very weak justification). Another reason is the dynamicity of the schema. The QAPI introspection data is very much static; and while QOM is somewhat more dynamic, generally we consider that to be a bug rather than a feature these days. On the other hand, the statistics that are exposed by QEMU might be passed through from another source, such as KVM, and the disadvantages of manually updating the QAPI schema for outweight the benefits from vetting the statistics and filtering out anything that seems "too unstable". Running old QEMU with new kernel is a supported usecase; if old QEMU cannot expose statistics from a new kernel, or if a kernel developer needs to change QEMU before gathering new info from the new kernel, then that is a poor user interface. The framework provides a method to register callbacks for these QMP commands. Most of the work in fact is done by the callbacks, and a large majority of this patch is new QAPI structs and commands. Examples (with KVM stats): - Query all VM stats: { "execute": "query-stats", "arguments" : { "target": "vm" } } { "return": [ { "provider": "kvm", "stats": [ { "name": "max_mmu_page_hash_collisions", "value": 0 }, { "name": "max_mmu_rmap_size", "value": 0 }, { "name": "nx_lpage_splits", "value": 148 }, ... ] }, { "provider": "xyz", "stats": [ ... ] } ] } - Query all vCPU stats: { "execute": "query-stats", "arguments" : { "target": "vcpu" } } { "return": [ { "provider": "kvm", "qom_path": "/machine/unattached/device[0]" "stats": [ { "name": "guest_mode", "value": 0 }, { "name": "directed_yield_successful", "value": 0 }, { "name": "directed_yield_attempted", "value": 106 }, ... ] }, { "provider": "kvm", "qom_path": "/machine/unattached/device[1]" "stats": [ { "name": "guest_mode", "value": 0 }, { "name": "directed_yield_successful", "value": 0 }, { "name": "directed_yield_attempted", "value": 106 }, ... ] }, ] } - Retrieve the schemas: { "execute": "query-stats-schemas" } { "return": [ { "provider": "kvm", "target": "vcpu", "stats": [ { "name": "guest_mode", "unit": "none", "base": 10, "exponent": 0, "type": "instant" }, { "name": "directed_yield_successful", "unit": "none", "base": 10, "exponent": 0, "type": "cumulative" }, ... ] }, { "provider": "kvm", "target": "vm", "stats": [ { "name": "max_mmu_page_hash_collisions", "unit": "none", "base": 10, "exponent": 0, "type": "peak" }, ... ] }, { "provider": "xyz", "target": "vm", "stats": [ ... ] } ] } Signed-off-by: Mark Kanda <mark.kanda@oracle.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2022-02-15 16:04:31 +01:00
'list': [ 'uint64' ] } }
##
# @Stats:
#
# @name: name of stat.
#
qmp: Support for querying stats Gathering statistics is important for development, for monitoring and for performance measurement. There are tools such as kvm_stat that do this and they rely on the _user_ knowing the interesting data points rather than the tool (which can treat them as opaque). The commands introduced in this commit introduce QMP support for querying stats; the goal is to take the capabilities of these tools and making them available throughout the whole virtualization stack, so that one can observe, monitor and measure virtual machines without having shell access + root on the host that runs them. query-stats returns a list of all stats per target type (only VM and vCPU to start); future commits add extra options for specifying stat names, vCPU qom paths, and providers. All these are used by the HMP command "info stats". Because of the development usecases around statistics, a good HMP interface is important. query-stats-schemas returns a list of stats included in each target type, with an option for specifying the provider. The concepts in the schema are based on the KVM binary stats' own introspection data, just translated to QAPI. There are two reasons to have a separate schema that is not tied to the QAPI schema. The first is the contents of the schemas: the new introspection data provides different information than the QAPI data, namely unit of measurement, how the numbers are gathered and change (peak/instant/cumulative/histogram), and histogram bucket sizes. There's really no reason to have this kind of metadata in the QAPI introspection schema (except possibly for the unit of measure, but there's a very weak justification). Another reason is the dynamicity of the schema. The QAPI introspection data is very much static; and while QOM is somewhat more dynamic, generally we consider that to be a bug rather than a feature these days. On the other hand, the statistics that are exposed by QEMU might be passed through from another source, such as KVM, and the disadvantages of manually updating the QAPI schema for outweight the benefits from vetting the statistics and filtering out anything that seems "too unstable". Running old QEMU with new kernel is a supported usecase; if old QEMU cannot expose statistics from a new kernel, or if a kernel developer needs to change QEMU before gathering new info from the new kernel, then that is a poor user interface. The framework provides a method to register callbacks for these QMP commands. Most of the work in fact is done by the callbacks, and a large majority of this patch is new QAPI structs and commands. Examples (with KVM stats): - Query all VM stats: { "execute": "query-stats", "arguments" : { "target": "vm" } } { "return": [ { "provider": "kvm", "stats": [ { "name": "max_mmu_page_hash_collisions", "value": 0 }, { "name": "max_mmu_rmap_size", "value": 0 }, { "name": "nx_lpage_splits", "value": 148 }, ... ] }, { "provider": "xyz", "stats": [ ... ] } ] } - Query all vCPU stats: { "execute": "query-stats", "arguments" : { "target": "vcpu" } } { "return": [ { "provider": "kvm", "qom_path": "/machine/unattached/device[0]" "stats": [ { "name": "guest_mode", "value": 0 }, { "name": "directed_yield_successful", "value": 0 }, { "name": "directed_yield_attempted", "value": 106 }, ... ] }, { "provider": "kvm", "qom_path": "/machine/unattached/device[1]" "stats": [ { "name": "guest_mode", "value": 0 }, { "name": "directed_yield_successful", "value": 0 }, { "name": "directed_yield_attempted", "value": 106 }, ... ] }, ] } - Retrieve the schemas: { "execute": "query-stats-schemas" } { "return": [ { "provider": "kvm", "target": "vcpu", "stats": [ { "name": "guest_mode", "unit": "none", "base": 10, "exponent": 0, "type": "instant" }, { "name": "directed_yield_successful", "unit": "none", "base": 10, "exponent": 0, "type": "cumulative" }, ... ] }, { "provider": "kvm", "target": "vm", "stats": [ { "name": "max_mmu_page_hash_collisions", "unit": "none", "base": 10, "exponent": 0, "type": "peak" }, ... ] }, { "provider": "xyz", "target": "vm", "stats": [ ... ] } ] } Signed-off-by: Mark Kanda <mark.kanda@oracle.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2022-02-15 16:04:31 +01:00
# @value: stat value.
#
# Since: 7.1
##
{ 'struct': 'Stats',
'data': { 'name': 'str',
'value' : 'StatsValue' } }
##
# @StatsResult:
#
# @provider: provider for this set of statistics.
#
# @qom-path: Path to the object for which the statistics are returned,
# if the object is exposed in the QOM tree
qmp: Support for querying stats Gathering statistics is important for development, for monitoring and for performance measurement. There are tools such as kvm_stat that do this and they rely on the _user_ knowing the interesting data points rather than the tool (which can treat them as opaque). The commands introduced in this commit introduce QMP support for querying stats; the goal is to take the capabilities of these tools and making them available throughout the whole virtualization stack, so that one can observe, monitor and measure virtual machines without having shell access + root on the host that runs them. query-stats returns a list of all stats per target type (only VM and vCPU to start); future commits add extra options for specifying stat names, vCPU qom paths, and providers. All these are used by the HMP command "info stats". Because of the development usecases around statistics, a good HMP interface is important. query-stats-schemas returns a list of stats included in each target type, with an option for specifying the provider. The concepts in the schema are based on the KVM binary stats' own introspection data, just translated to QAPI. There are two reasons to have a separate schema that is not tied to the QAPI schema. The first is the contents of the schemas: the new introspection data provides different information than the QAPI data, namely unit of measurement, how the numbers are gathered and change (peak/instant/cumulative/histogram), and histogram bucket sizes. There's really no reason to have this kind of metadata in the QAPI introspection schema (except possibly for the unit of measure, but there's a very weak justification). Another reason is the dynamicity of the schema. The QAPI introspection data is very much static; and while QOM is somewhat more dynamic, generally we consider that to be a bug rather than a feature these days. On the other hand, the statistics that are exposed by QEMU might be passed through from another source, such as KVM, and the disadvantages of manually updating the QAPI schema for outweight the benefits from vetting the statistics and filtering out anything that seems "too unstable". Running old QEMU with new kernel is a supported usecase; if old QEMU cannot expose statistics from a new kernel, or if a kernel developer needs to change QEMU before gathering new info from the new kernel, then that is a poor user interface. The framework provides a method to register callbacks for these QMP commands. Most of the work in fact is done by the callbacks, and a large majority of this patch is new QAPI structs and commands. Examples (with KVM stats): - Query all VM stats: { "execute": "query-stats", "arguments" : { "target": "vm" } } { "return": [ { "provider": "kvm", "stats": [ { "name": "max_mmu_page_hash_collisions", "value": 0 }, { "name": "max_mmu_rmap_size", "value": 0 }, { "name": "nx_lpage_splits", "value": 148 }, ... ] }, { "provider": "xyz", "stats": [ ... ] } ] } - Query all vCPU stats: { "execute": "query-stats", "arguments" : { "target": "vcpu" } } { "return": [ { "provider": "kvm", "qom_path": "/machine/unattached/device[0]" "stats": [ { "name": "guest_mode", "value": 0 }, { "name": "directed_yield_successful", "value": 0 }, { "name": "directed_yield_attempted", "value": 106 }, ... ] }, { "provider": "kvm", "qom_path": "/machine/unattached/device[1]" "stats": [ { "name": "guest_mode", "value": 0 }, { "name": "directed_yield_successful", "value": 0 }, { "name": "directed_yield_attempted", "value": 106 }, ... ] }, ] } - Retrieve the schemas: { "execute": "query-stats-schemas" } { "return": [ { "provider": "kvm", "target": "vcpu", "stats": [ { "name": "guest_mode", "unit": "none", "base": 10, "exponent": 0, "type": "instant" }, { "name": "directed_yield_successful", "unit": "none", "base": 10, "exponent": 0, "type": "cumulative" }, ... ] }, { "provider": "kvm", "target": "vm", "stats": [ { "name": "max_mmu_page_hash_collisions", "unit": "none", "base": 10, "exponent": 0, "type": "peak" }, ... ] }, { "provider": "xyz", "target": "vm", "stats": [ ... ] } ] } Signed-off-by: Mark Kanda <mark.kanda@oracle.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2022-02-15 16:04:31 +01:00
#
# @stats: list of statistics.
#
# Since: 7.1
##
{ 'struct': 'StatsResult',
'data': { 'provider': 'StatsProvider',
'*qom-path': 'str',
'stats': [ 'Stats' ] } }
##
# @query-stats:
#
# Return runtime-collected statistics for objects such as the VM or
# its vCPUs.
qmp: Support for querying stats Gathering statistics is important for development, for monitoring and for performance measurement. There are tools such as kvm_stat that do this and they rely on the _user_ knowing the interesting data points rather than the tool (which can treat them as opaque). The commands introduced in this commit introduce QMP support for querying stats; the goal is to take the capabilities of these tools and making them available throughout the whole virtualization stack, so that one can observe, monitor and measure virtual machines without having shell access + root on the host that runs them. query-stats returns a list of all stats per target type (only VM and vCPU to start); future commits add extra options for specifying stat names, vCPU qom paths, and providers. All these are used by the HMP command "info stats". Because of the development usecases around statistics, a good HMP interface is important. query-stats-schemas returns a list of stats included in each target type, with an option for specifying the provider. The concepts in the schema are based on the KVM binary stats' own introspection data, just translated to QAPI. There are two reasons to have a separate schema that is not tied to the QAPI schema. The first is the contents of the schemas: the new introspection data provides different information than the QAPI data, namely unit of measurement, how the numbers are gathered and change (peak/instant/cumulative/histogram), and histogram bucket sizes. There's really no reason to have this kind of metadata in the QAPI introspection schema (except possibly for the unit of measure, but there's a very weak justification). Another reason is the dynamicity of the schema. The QAPI introspection data is very much static; and while QOM is somewhat more dynamic, generally we consider that to be a bug rather than a feature these days. On the other hand, the statistics that are exposed by QEMU might be passed through from another source, such as KVM, and the disadvantages of manually updating the QAPI schema for outweight the benefits from vetting the statistics and filtering out anything that seems "too unstable". Running old QEMU with new kernel is a supported usecase; if old QEMU cannot expose statistics from a new kernel, or if a kernel developer needs to change QEMU before gathering new info from the new kernel, then that is a poor user interface. The framework provides a method to register callbacks for these QMP commands. Most of the work in fact is done by the callbacks, and a large majority of this patch is new QAPI structs and commands. Examples (with KVM stats): - Query all VM stats: { "execute": "query-stats", "arguments" : { "target": "vm" } } { "return": [ { "provider": "kvm", "stats": [ { "name": "max_mmu_page_hash_collisions", "value": 0 }, { "name": "max_mmu_rmap_size", "value": 0 }, { "name": "nx_lpage_splits", "value": 148 }, ... ] }, { "provider": "xyz", "stats": [ ... ] } ] } - Query all vCPU stats: { "execute": "query-stats", "arguments" : { "target": "vcpu" } } { "return": [ { "provider": "kvm", "qom_path": "/machine/unattached/device[0]" "stats": [ { "name": "guest_mode", "value": 0 }, { "name": "directed_yield_successful", "value": 0 }, { "name": "directed_yield_attempted", "value": 106 }, ... ] }, { "provider": "kvm", "qom_path": "/machine/unattached/device[1]" "stats": [ { "name": "guest_mode", "value": 0 }, { "name": "directed_yield_successful", "value": 0 }, { "name": "directed_yield_attempted", "value": 106 }, ... ] }, ] } - Retrieve the schemas: { "execute": "query-stats-schemas" } { "return": [ { "provider": "kvm", "target": "vcpu", "stats": [ { "name": "guest_mode", "unit": "none", "base": 10, "exponent": 0, "type": "instant" }, { "name": "directed_yield_successful", "unit": "none", "base": 10, "exponent": 0, "type": "cumulative" }, ... ] }, { "provider": "kvm", "target": "vm", "stats": [ { "name": "max_mmu_page_hash_collisions", "unit": "none", "base": 10, "exponent": 0, "type": "peak" }, ... ] }, { "provider": "xyz", "target": "vm", "stats": [ ... ] } ] } Signed-off-by: Mark Kanda <mark.kanda@oracle.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2022-02-15 16:04:31 +01:00
#
# The arguments are a StatsFilter and specify the provider and objects
# to return statistics about.
#
# Returns: a list of StatsResult, one for each provider and object
# (e.g., for each vCPU).
qmp: Support for querying stats Gathering statistics is important for development, for monitoring and for performance measurement. There are tools such as kvm_stat that do this and they rely on the _user_ knowing the interesting data points rather than the tool (which can treat them as opaque). The commands introduced in this commit introduce QMP support for querying stats; the goal is to take the capabilities of these tools and making them available throughout the whole virtualization stack, so that one can observe, monitor and measure virtual machines without having shell access + root on the host that runs them. query-stats returns a list of all stats per target type (only VM and vCPU to start); future commits add extra options for specifying stat names, vCPU qom paths, and providers. All these are used by the HMP command "info stats". Because of the development usecases around statistics, a good HMP interface is important. query-stats-schemas returns a list of stats included in each target type, with an option for specifying the provider. The concepts in the schema are based on the KVM binary stats' own introspection data, just translated to QAPI. There are two reasons to have a separate schema that is not tied to the QAPI schema. The first is the contents of the schemas: the new introspection data provides different information than the QAPI data, namely unit of measurement, how the numbers are gathered and change (peak/instant/cumulative/histogram), and histogram bucket sizes. There's really no reason to have this kind of metadata in the QAPI introspection schema (except possibly for the unit of measure, but there's a very weak justification). Another reason is the dynamicity of the schema. The QAPI introspection data is very much static; and while QOM is somewhat more dynamic, generally we consider that to be a bug rather than a feature these days. On the other hand, the statistics that are exposed by QEMU might be passed through from another source, such as KVM, and the disadvantages of manually updating the QAPI schema for outweight the benefits from vetting the statistics and filtering out anything that seems "too unstable". Running old QEMU with new kernel is a supported usecase; if old QEMU cannot expose statistics from a new kernel, or if a kernel developer needs to change QEMU before gathering new info from the new kernel, then that is a poor user interface. The framework provides a method to register callbacks for these QMP commands. Most of the work in fact is done by the callbacks, and a large majority of this patch is new QAPI structs and commands. Examples (with KVM stats): - Query all VM stats: { "execute": "query-stats", "arguments" : { "target": "vm" } } { "return": [ { "provider": "kvm", "stats": [ { "name": "max_mmu_page_hash_collisions", "value": 0 }, { "name": "max_mmu_rmap_size", "value": 0 }, { "name": "nx_lpage_splits", "value": 148 }, ... ] }, { "provider": "xyz", "stats": [ ... ] } ] } - Query all vCPU stats: { "execute": "query-stats", "arguments" : { "target": "vcpu" } } { "return": [ { "provider": "kvm", "qom_path": "/machine/unattached/device[0]" "stats": [ { "name": "guest_mode", "value": 0 }, { "name": "directed_yield_successful", "value": 0 }, { "name": "directed_yield_attempted", "value": 106 }, ... ] }, { "provider": "kvm", "qom_path": "/machine/unattached/device[1]" "stats": [ { "name": "guest_mode", "value": 0 }, { "name": "directed_yield_successful", "value": 0 }, { "name": "directed_yield_attempted", "value": 106 }, ... ] }, ] } - Retrieve the schemas: { "execute": "query-stats-schemas" } { "return": [ { "provider": "kvm", "target": "vcpu", "stats": [ { "name": "guest_mode", "unit": "none", "base": 10, "exponent": 0, "type": "instant" }, { "name": "directed_yield_successful", "unit": "none", "base": 10, "exponent": 0, "type": "cumulative" }, ... ] }, { "provider": "kvm", "target": "vm", "stats": [ { "name": "max_mmu_page_hash_collisions", "unit": "none", "base": 10, "exponent": 0, "type": "peak" }, ... ] }, { "provider": "xyz", "target": "vm", "stats": [ ... ] } ] } Signed-off-by: Mark Kanda <mark.kanda@oracle.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2022-02-15 16:04:31 +01:00
#
# Since: 7.1
##
{ 'command': 'query-stats',
'data': 'StatsFilter',
'boxed': true,
'returns': [ 'StatsResult' ] }
##
# @StatsSchemaValue:
#
# Schema for a single statistic.
#
# @name: name of the statistic; each element of the schema is uniquely
# identified by a target, a provider (both available in
# @StatsSchema) and the name.
qmp: Support for querying stats Gathering statistics is important for development, for monitoring and for performance measurement. There are tools such as kvm_stat that do this and they rely on the _user_ knowing the interesting data points rather than the tool (which can treat them as opaque). The commands introduced in this commit introduce QMP support for querying stats; the goal is to take the capabilities of these tools and making them available throughout the whole virtualization stack, so that one can observe, monitor and measure virtual machines without having shell access + root on the host that runs them. query-stats returns a list of all stats per target type (only VM and vCPU to start); future commits add extra options for specifying stat names, vCPU qom paths, and providers. All these are used by the HMP command "info stats". Because of the development usecases around statistics, a good HMP interface is important. query-stats-schemas returns a list of stats included in each target type, with an option for specifying the provider. The concepts in the schema are based on the KVM binary stats' own introspection data, just translated to QAPI. There are two reasons to have a separate schema that is not tied to the QAPI schema. The first is the contents of the schemas: the new introspection data provides different information than the QAPI data, namely unit of measurement, how the numbers are gathered and change (peak/instant/cumulative/histogram), and histogram bucket sizes. There's really no reason to have this kind of metadata in the QAPI introspection schema (except possibly for the unit of measure, but there's a very weak justification). Another reason is the dynamicity of the schema. The QAPI introspection data is very much static; and while QOM is somewhat more dynamic, generally we consider that to be a bug rather than a feature these days. On the other hand, the statistics that are exposed by QEMU might be passed through from another source, such as KVM, and the disadvantages of manually updating the QAPI schema for outweight the benefits from vetting the statistics and filtering out anything that seems "too unstable". Running old QEMU with new kernel is a supported usecase; if old QEMU cannot expose statistics from a new kernel, or if a kernel developer needs to change QEMU before gathering new info from the new kernel, then that is a poor user interface. The framework provides a method to register callbacks for these QMP commands. Most of the work in fact is done by the callbacks, and a large majority of this patch is new QAPI structs and commands. Examples (with KVM stats): - Query all VM stats: { "execute": "query-stats", "arguments" : { "target": "vm" } } { "return": [ { "provider": "kvm", "stats": [ { "name": "max_mmu_page_hash_collisions", "value": 0 }, { "name": "max_mmu_rmap_size", "value": 0 }, { "name": "nx_lpage_splits", "value": 148 }, ... ] }, { "provider": "xyz", "stats": [ ... ] } ] } - Query all vCPU stats: { "execute": "query-stats", "arguments" : { "target": "vcpu" } } { "return": [ { "provider": "kvm", "qom_path": "/machine/unattached/device[0]" "stats": [ { "name": "guest_mode", "value": 0 }, { "name": "directed_yield_successful", "value": 0 }, { "name": "directed_yield_attempted", "value": 106 }, ... ] }, { "provider": "kvm", "qom_path": "/machine/unattached/device[1]" "stats": [ { "name": "guest_mode", "value": 0 }, { "name": "directed_yield_successful", "value": 0 }, { "name": "directed_yield_attempted", "value": 106 }, ... ] }, ] } - Retrieve the schemas: { "execute": "query-stats-schemas" } { "return": [ { "provider": "kvm", "target": "vcpu", "stats": [ { "name": "guest_mode", "unit": "none", "base": 10, "exponent": 0, "type": "instant" }, { "name": "directed_yield_successful", "unit": "none", "base": 10, "exponent": 0, "type": "cumulative" }, ... ] }, { "provider": "kvm", "target": "vm", "stats": [ { "name": "max_mmu_page_hash_collisions", "unit": "none", "base": 10, "exponent": 0, "type": "peak" }, ... ] }, { "provider": "xyz", "target": "vm", "stats": [ ... ] } ] } Signed-off-by: Mark Kanda <mark.kanda@oracle.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2022-02-15 16:04:31 +01:00
#
# @type: kind of statistic.
#
# @unit: basic unit of measure for the statistic; if missing, the
# statistic is a simple number or counter.
qmp: Support for querying stats Gathering statistics is important for development, for monitoring and for performance measurement. There are tools such as kvm_stat that do this and they rely on the _user_ knowing the interesting data points rather than the tool (which can treat them as opaque). The commands introduced in this commit introduce QMP support for querying stats; the goal is to take the capabilities of these tools and making them available throughout the whole virtualization stack, so that one can observe, monitor and measure virtual machines without having shell access + root on the host that runs them. query-stats returns a list of all stats per target type (only VM and vCPU to start); future commits add extra options for specifying stat names, vCPU qom paths, and providers. All these are used by the HMP command "info stats". Because of the development usecases around statistics, a good HMP interface is important. query-stats-schemas returns a list of stats included in each target type, with an option for specifying the provider. The concepts in the schema are based on the KVM binary stats' own introspection data, just translated to QAPI. There are two reasons to have a separate schema that is not tied to the QAPI schema. The first is the contents of the schemas: the new introspection data provides different information than the QAPI data, namely unit of measurement, how the numbers are gathered and change (peak/instant/cumulative/histogram), and histogram bucket sizes. There's really no reason to have this kind of metadata in the QAPI introspection schema (except possibly for the unit of measure, but there's a very weak justification). Another reason is the dynamicity of the schema. The QAPI introspection data is very much static; and while QOM is somewhat more dynamic, generally we consider that to be a bug rather than a feature these days. On the other hand, the statistics that are exposed by QEMU might be passed through from another source, such as KVM, and the disadvantages of manually updating the QAPI schema for outweight the benefits from vetting the statistics and filtering out anything that seems "too unstable". Running old QEMU with new kernel is a supported usecase; if old QEMU cannot expose statistics from a new kernel, or if a kernel developer needs to change QEMU before gathering new info from the new kernel, then that is a poor user interface. The framework provides a method to register callbacks for these QMP commands. Most of the work in fact is done by the callbacks, and a large majority of this patch is new QAPI structs and commands. Examples (with KVM stats): - Query all VM stats: { "execute": "query-stats", "arguments" : { "target": "vm" } } { "return": [ { "provider": "kvm", "stats": [ { "name": "max_mmu_page_hash_collisions", "value": 0 }, { "name": "max_mmu_rmap_size", "value": 0 }, { "name": "nx_lpage_splits", "value": 148 }, ... ] }, { "provider": "xyz", "stats": [ ... ] } ] } - Query all vCPU stats: { "execute": "query-stats", "arguments" : { "target": "vcpu" } } { "return": [ { "provider": "kvm", "qom_path": "/machine/unattached/device[0]" "stats": [ { "name": "guest_mode", "value": 0 }, { "name": "directed_yield_successful", "value": 0 }, { "name": "directed_yield_attempted", "value": 106 }, ... ] }, { "provider": "kvm", "qom_path": "/machine/unattached/device[1]" "stats": [ { "name": "guest_mode", "value": 0 }, { "name": "directed_yield_successful", "value": 0 }, { "name": "directed_yield_attempted", "value": 106 }, ... ] }, ] } - Retrieve the schemas: { "execute": "query-stats-schemas" } { "return": [ { "provider": "kvm", "target": "vcpu", "stats": [ { "name": "guest_mode", "unit": "none", "base": 10, "exponent": 0, "type": "instant" }, { "name": "directed_yield_successful", "unit": "none", "base": 10, "exponent": 0, "type": "cumulative" }, ... ] }, { "provider": "kvm", "target": "vm", "stats": [ { "name": "max_mmu_page_hash_collisions", "unit": "none", "base": 10, "exponent": 0, "type": "peak" }, ... ] }, { "provider": "xyz", "target": "vm", "stats": [ ... ] } ] } Signed-off-by: Mark Kanda <mark.kanda@oracle.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2022-02-15 16:04:31 +01:00
#
# @base: base for the multiple of @unit in which the statistic is
# measured. Only present if @exponent is non-zero; @base and
# @exponent together form a SI prefix (e.g., _nano-_ for
# ``base=10`` and ``exponent=-9``) or IEC binary prefix (e.g.
# _kibi-_ for ``base=2`` and ``exponent=10``)
qmp: Support for querying stats Gathering statistics is important for development, for monitoring and for performance measurement. There are tools such as kvm_stat that do this and they rely on the _user_ knowing the interesting data points rather than the tool (which can treat them as opaque). The commands introduced in this commit introduce QMP support for querying stats; the goal is to take the capabilities of these tools and making them available throughout the whole virtualization stack, so that one can observe, monitor and measure virtual machines without having shell access + root on the host that runs them. query-stats returns a list of all stats per target type (only VM and vCPU to start); future commits add extra options for specifying stat names, vCPU qom paths, and providers. All these are used by the HMP command "info stats". Because of the development usecases around statistics, a good HMP interface is important. query-stats-schemas returns a list of stats included in each target type, with an option for specifying the provider. The concepts in the schema are based on the KVM binary stats' own introspection data, just translated to QAPI. There are two reasons to have a separate schema that is not tied to the QAPI schema. The first is the contents of the schemas: the new introspection data provides different information than the QAPI data, namely unit of measurement, how the numbers are gathered and change (peak/instant/cumulative/histogram), and histogram bucket sizes. There's really no reason to have this kind of metadata in the QAPI introspection schema (except possibly for the unit of measure, but there's a very weak justification). Another reason is the dynamicity of the schema. The QAPI introspection data is very much static; and while QOM is somewhat more dynamic, generally we consider that to be a bug rather than a feature these days. On the other hand, the statistics that are exposed by QEMU might be passed through from another source, such as KVM, and the disadvantages of manually updating the QAPI schema for outweight the benefits from vetting the statistics and filtering out anything that seems "too unstable". Running old QEMU with new kernel is a supported usecase; if old QEMU cannot expose statistics from a new kernel, or if a kernel developer needs to change QEMU before gathering new info from the new kernel, then that is a poor user interface. The framework provides a method to register callbacks for these QMP commands. Most of the work in fact is done by the callbacks, and a large majority of this patch is new QAPI structs and commands. Examples (with KVM stats): - Query all VM stats: { "execute": "query-stats", "arguments" : { "target": "vm" } } { "return": [ { "provider": "kvm", "stats": [ { "name": "max_mmu_page_hash_collisions", "value": 0 }, { "name": "max_mmu_rmap_size", "value": 0 }, { "name": "nx_lpage_splits", "value": 148 }, ... ] }, { "provider": "xyz", "stats": [ ... ] } ] } - Query all vCPU stats: { "execute": "query-stats", "arguments" : { "target": "vcpu" } } { "return": [ { "provider": "kvm", "qom_path": "/machine/unattached/device[0]" "stats": [ { "name": "guest_mode", "value": 0 }, { "name": "directed_yield_successful", "value": 0 }, { "name": "directed_yield_attempted", "value": 106 }, ... ] }, { "provider": "kvm", "qom_path": "/machine/unattached/device[1]" "stats": [ { "name": "guest_mode", "value": 0 }, { "name": "directed_yield_successful", "value": 0 }, { "name": "directed_yield_attempted", "value": 106 }, ... ] }, ] } - Retrieve the schemas: { "execute": "query-stats-schemas" } { "return": [ { "provider": "kvm", "target": "vcpu", "stats": [ { "name": "guest_mode", "unit": "none", "base": 10, "exponent": 0, "type": "instant" }, { "name": "directed_yield_successful", "unit": "none", "base": 10, "exponent": 0, "type": "cumulative" }, ... ] }, { "provider": "kvm", "target": "vm", "stats": [ { "name": "max_mmu_page_hash_collisions", "unit": "none", "base": 10, "exponent": 0, "type": "peak" }, ... ] }, { "provider": "xyz", "target": "vm", "stats": [ ... ] } ] } Signed-off-by: Mark Kanda <mark.kanda@oracle.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2022-02-15 16:04:31 +01:00
#
# @exponent: exponent for the multiple of @unit in which the statistic
# is expressed, or 0 for the basic unit
qmp: Support for querying stats Gathering statistics is important for development, for monitoring and for performance measurement. There are tools such as kvm_stat that do this and they rely on the _user_ knowing the interesting data points rather than the tool (which can treat them as opaque). The commands introduced in this commit introduce QMP support for querying stats; the goal is to take the capabilities of these tools and making them available throughout the whole virtualization stack, so that one can observe, monitor and measure virtual machines without having shell access + root on the host that runs them. query-stats returns a list of all stats per target type (only VM and vCPU to start); future commits add extra options for specifying stat names, vCPU qom paths, and providers. All these are used by the HMP command "info stats". Because of the development usecases around statistics, a good HMP interface is important. query-stats-schemas returns a list of stats included in each target type, with an option for specifying the provider. The concepts in the schema are based on the KVM binary stats' own introspection data, just translated to QAPI. There are two reasons to have a separate schema that is not tied to the QAPI schema. The first is the contents of the schemas: the new introspection data provides different information than the QAPI data, namely unit of measurement, how the numbers are gathered and change (peak/instant/cumulative/histogram), and histogram bucket sizes. There's really no reason to have this kind of metadata in the QAPI introspection schema (except possibly for the unit of measure, but there's a very weak justification). Another reason is the dynamicity of the schema. The QAPI introspection data is very much static; and while QOM is somewhat more dynamic, generally we consider that to be a bug rather than a feature these days. On the other hand, the statistics that are exposed by QEMU might be passed through from another source, such as KVM, and the disadvantages of manually updating the QAPI schema for outweight the benefits from vetting the statistics and filtering out anything that seems "too unstable". Running old QEMU with new kernel is a supported usecase; if old QEMU cannot expose statistics from a new kernel, or if a kernel developer needs to change QEMU before gathering new info from the new kernel, then that is a poor user interface. The framework provides a method to register callbacks for these QMP commands. Most of the work in fact is done by the callbacks, and a large majority of this patch is new QAPI structs and commands. Examples (with KVM stats): - Query all VM stats: { "execute": "query-stats", "arguments" : { "target": "vm" } } { "return": [ { "provider": "kvm", "stats": [ { "name": "max_mmu_page_hash_collisions", "value": 0 }, { "name": "max_mmu_rmap_size", "value": 0 }, { "name": "nx_lpage_splits", "value": 148 }, ... ] }, { "provider": "xyz", "stats": [ ... ] } ] } - Query all vCPU stats: { "execute": "query-stats", "arguments" : { "target": "vcpu" } } { "return": [ { "provider": "kvm", "qom_path": "/machine/unattached/device[0]" "stats": [ { "name": "guest_mode", "value": 0 }, { "name": "directed_yield_successful", "value": 0 }, { "name": "directed_yield_attempted", "value": 106 }, ... ] }, { "provider": "kvm", "qom_path": "/machine/unattached/device[1]" "stats": [ { "name": "guest_mode", "value": 0 }, { "name": "directed_yield_successful", "value": 0 }, { "name": "directed_yield_attempted", "value": 106 }, ... ] }, ] } - Retrieve the schemas: { "execute": "query-stats-schemas" } { "return": [ { "provider": "kvm", "target": "vcpu", "stats": [ { "name": "guest_mode", "unit": "none", "base": 10, "exponent": 0, "type": "instant" }, { "name": "directed_yield_successful", "unit": "none", "base": 10, "exponent": 0, "type": "cumulative" }, ... ] }, { "provider": "kvm", "target": "vm", "stats": [ { "name": "max_mmu_page_hash_collisions", "unit": "none", "base": 10, "exponent": 0, "type": "peak" }, ... ] }, { "provider": "xyz", "target": "vm", "stats": [ ... ] } ] } Signed-off-by: Mark Kanda <mark.kanda@oracle.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2022-02-15 16:04:31 +01:00
#
# @bucket-size: Present when @type is "linear-histogram", contains the
# width of each bucket of the histogram.
qmp: Support for querying stats Gathering statistics is important for development, for monitoring and for performance measurement. There are tools such as kvm_stat that do this and they rely on the _user_ knowing the interesting data points rather than the tool (which can treat them as opaque). The commands introduced in this commit introduce QMP support for querying stats; the goal is to take the capabilities of these tools and making them available throughout the whole virtualization stack, so that one can observe, monitor and measure virtual machines without having shell access + root on the host that runs them. query-stats returns a list of all stats per target type (only VM and vCPU to start); future commits add extra options for specifying stat names, vCPU qom paths, and providers. All these are used by the HMP command "info stats". Because of the development usecases around statistics, a good HMP interface is important. query-stats-schemas returns a list of stats included in each target type, with an option for specifying the provider. The concepts in the schema are based on the KVM binary stats' own introspection data, just translated to QAPI. There are two reasons to have a separate schema that is not tied to the QAPI schema. The first is the contents of the schemas: the new introspection data provides different information than the QAPI data, namely unit of measurement, how the numbers are gathered and change (peak/instant/cumulative/histogram), and histogram bucket sizes. There's really no reason to have this kind of metadata in the QAPI introspection schema (except possibly for the unit of measure, but there's a very weak justification). Another reason is the dynamicity of the schema. The QAPI introspection data is very much static; and while QOM is somewhat more dynamic, generally we consider that to be a bug rather than a feature these days. On the other hand, the statistics that are exposed by QEMU might be passed through from another source, such as KVM, and the disadvantages of manually updating the QAPI schema for outweight the benefits from vetting the statistics and filtering out anything that seems "too unstable". Running old QEMU with new kernel is a supported usecase; if old QEMU cannot expose statistics from a new kernel, or if a kernel developer needs to change QEMU before gathering new info from the new kernel, then that is a poor user interface. The framework provides a method to register callbacks for these QMP commands. Most of the work in fact is done by the callbacks, and a large majority of this patch is new QAPI structs and commands. Examples (with KVM stats): - Query all VM stats: { "execute": "query-stats", "arguments" : { "target": "vm" } } { "return": [ { "provider": "kvm", "stats": [ { "name": "max_mmu_page_hash_collisions", "value": 0 }, { "name": "max_mmu_rmap_size", "value": 0 }, { "name": "nx_lpage_splits", "value": 148 }, ... ] }, { "provider": "xyz", "stats": [ ... ] } ] } - Query all vCPU stats: { "execute": "query-stats", "arguments" : { "target": "vcpu" } } { "return": [ { "provider": "kvm", "qom_path": "/machine/unattached/device[0]" "stats": [ { "name": "guest_mode", "value": 0 }, { "name": "directed_yield_successful", "value": 0 }, { "name": "directed_yield_attempted", "value": 106 }, ... ] }, { "provider": "kvm", "qom_path": "/machine/unattached/device[1]" "stats": [ { "name": "guest_mode", "value": 0 }, { "name": "directed_yield_successful", "value": 0 }, { "name": "directed_yield_attempted", "value": 106 }, ... ] }, ] } - Retrieve the schemas: { "execute": "query-stats-schemas" } { "return": [ { "provider": "kvm", "target": "vcpu", "stats": [ { "name": "guest_mode", "unit": "none", "base": 10, "exponent": 0, "type": "instant" }, { "name": "directed_yield_successful", "unit": "none", "base": 10, "exponent": 0, "type": "cumulative" }, ... ] }, { "provider": "kvm", "target": "vm", "stats": [ { "name": "max_mmu_page_hash_collisions", "unit": "none", "base": 10, "exponent": 0, "type": "peak" }, ... ] }, { "provider": "xyz", "target": "vm", "stats": [ ... ] } ] } Signed-off-by: Mark Kanda <mark.kanda@oracle.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2022-02-15 16:04:31 +01:00
#
# Since: 7.1
##
{ 'struct': 'StatsSchemaValue',
'data': { 'name': 'str',
'type': 'StatsType',
'*unit': 'StatsUnit',
'*base': 'int8',
'exponent': 'int16',
'*bucket-size': 'uint32' } }
##
# @StatsSchema:
#
# Schema for all available statistics for a provider and target.
#
# @provider: provider for this set of statistics.
#
# @target: the kind of object that can be queried through the
# provider.
qmp: Support for querying stats Gathering statistics is important for development, for monitoring and for performance measurement. There are tools such as kvm_stat that do this and they rely on the _user_ knowing the interesting data points rather than the tool (which can treat them as opaque). The commands introduced in this commit introduce QMP support for querying stats; the goal is to take the capabilities of these tools and making them available throughout the whole virtualization stack, so that one can observe, monitor and measure virtual machines without having shell access + root on the host that runs them. query-stats returns a list of all stats per target type (only VM and vCPU to start); future commits add extra options for specifying stat names, vCPU qom paths, and providers. All these are used by the HMP command "info stats". Because of the development usecases around statistics, a good HMP interface is important. query-stats-schemas returns a list of stats included in each target type, with an option for specifying the provider. The concepts in the schema are based on the KVM binary stats' own introspection data, just translated to QAPI. There are two reasons to have a separate schema that is not tied to the QAPI schema. The first is the contents of the schemas: the new introspection data provides different information than the QAPI data, namely unit of measurement, how the numbers are gathered and change (peak/instant/cumulative/histogram), and histogram bucket sizes. There's really no reason to have this kind of metadata in the QAPI introspection schema (except possibly for the unit of measure, but there's a very weak justification). Another reason is the dynamicity of the schema. The QAPI introspection data is very much static; and while QOM is somewhat more dynamic, generally we consider that to be a bug rather than a feature these days. On the other hand, the statistics that are exposed by QEMU might be passed through from another source, such as KVM, and the disadvantages of manually updating the QAPI schema for outweight the benefits from vetting the statistics and filtering out anything that seems "too unstable". Running old QEMU with new kernel is a supported usecase; if old QEMU cannot expose statistics from a new kernel, or if a kernel developer needs to change QEMU before gathering new info from the new kernel, then that is a poor user interface. The framework provides a method to register callbacks for these QMP commands. Most of the work in fact is done by the callbacks, and a large majority of this patch is new QAPI structs and commands. Examples (with KVM stats): - Query all VM stats: { "execute": "query-stats", "arguments" : { "target": "vm" } } { "return": [ { "provider": "kvm", "stats": [ { "name": "max_mmu_page_hash_collisions", "value": 0 }, { "name": "max_mmu_rmap_size", "value": 0 }, { "name": "nx_lpage_splits", "value": 148 }, ... ] }, { "provider": "xyz", "stats": [ ... ] } ] } - Query all vCPU stats: { "execute": "query-stats", "arguments" : { "target": "vcpu" } } { "return": [ { "provider": "kvm", "qom_path": "/machine/unattached/device[0]" "stats": [ { "name": "guest_mode", "value": 0 }, { "name": "directed_yield_successful", "value": 0 }, { "name": "directed_yield_attempted", "value": 106 }, ... ] }, { "provider": "kvm", "qom_path": "/machine/unattached/device[1]" "stats": [ { "name": "guest_mode", "value": 0 }, { "name": "directed_yield_successful", "value": 0 }, { "name": "directed_yield_attempted", "value": 106 }, ... ] }, ] } - Retrieve the schemas: { "execute": "query-stats-schemas" } { "return": [ { "provider": "kvm", "target": "vcpu", "stats": [ { "name": "guest_mode", "unit": "none", "base": 10, "exponent": 0, "type": "instant" }, { "name": "directed_yield_successful", "unit": "none", "base": 10, "exponent": 0, "type": "cumulative" }, ... ] }, { "provider": "kvm", "target": "vm", "stats": [ { "name": "max_mmu_page_hash_collisions", "unit": "none", "base": 10, "exponent": 0, "type": "peak" }, ... ] }, { "provider": "xyz", "target": "vm", "stats": [ ... ] } ] } Signed-off-by: Mark Kanda <mark.kanda@oracle.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2022-02-15 16:04:31 +01:00
#
# @stats: list of statistics.
#
# Since: 7.1
##
{ 'struct': 'StatsSchema',
'data': { 'provider': 'StatsProvider',
'target': 'StatsTarget',
'stats': [ 'StatsSchemaValue' ] } }
##
# @query-stats-schemas:
#
# Return the schema for all available runtime-collected statistics.
#
# Note: runtime-collected statistics and their names fall outside
# QEMU's usual deprecation policies. QEMU will try to keep the
# set of available data stable, together with their names, but
# will not guarantee stability at all costs; the same is true of
# providers that source statistics externally, e.g. from Linux.
# For example, if the same value is being tracked with different
# names on different architectures or by different providers, one
# of them might be renamed. A statistic might go away if an
# algorithm is changed or some code is removed; changing a default
# might cause previously useful statistics to always report 0.
# Such changes, however, are expected to be rare.
qmp: Support for querying stats Gathering statistics is important for development, for monitoring and for performance measurement. There are tools such as kvm_stat that do this and they rely on the _user_ knowing the interesting data points rather than the tool (which can treat them as opaque). The commands introduced in this commit introduce QMP support for querying stats; the goal is to take the capabilities of these tools and making them available throughout the whole virtualization stack, so that one can observe, monitor and measure virtual machines without having shell access + root on the host that runs them. query-stats returns a list of all stats per target type (only VM and vCPU to start); future commits add extra options for specifying stat names, vCPU qom paths, and providers. All these are used by the HMP command "info stats". Because of the development usecases around statistics, a good HMP interface is important. query-stats-schemas returns a list of stats included in each target type, with an option for specifying the provider. The concepts in the schema are based on the KVM binary stats' own introspection data, just translated to QAPI. There are two reasons to have a separate schema that is not tied to the QAPI schema. The first is the contents of the schemas: the new introspection data provides different information than the QAPI data, namely unit of measurement, how the numbers are gathered and change (peak/instant/cumulative/histogram), and histogram bucket sizes. There's really no reason to have this kind of metadata in the QAPI introspection schema (except possibly for the unit of measure, but there's a very weak justification). Another reason is the dynamicity of the schema. The QAPI introspection data is very much static; and while QOM is somewhat more dynamic, generally we consider that to be a bug rather than a feature these days. On the other hand, the statistics that are exposed by QEMU might be passed through from another source, such as KVM, and the disadvantages of manually updating the QAPI schema for outweight the benefits from vetting the statistics and filtering out anything that seems "too unstable". Running old QEMU with new kernel is a supported usecase; if old QEMU cannot expose statistics from a new kernel, or if a kernel developer needs to change QEMU before gathering new info from the new kernel, then that is a poor user interface. The framework provides a method to register callbacks for these QMP commands. Most of the work in fact is done by the callbacks, and a large majority of this patch is new QAPI structs and commands. Examples (with KVM stats): - Query all VM stats: { "execute": "query-stats", "arguments" : { "target": "vm" } } { "return": [ { "provider": "kvm", "stats": [ { "name": "max_mmu_page_hash_collisions", "value": 0 }, { "name": "max_mmu_rmap_size", "value": 0 }, { "name": "nx_lpage_splits", "value": 148 }, ... ] }, { "provider": "xyz", "stats": [ ... ] } ] } - Query all vCPU stats: { "execute": "query-stats", "arguments" : { "target": "vcpu" } } { "return": [ { "provider": "kvm", "qom_path": "/machine/unattached/device[0]" "stats": [ { "name": "guest_mode", "value": 0 }, { "name": "directed_yield_successful", "value": 0 }, { "name": "directed_yield_attempted", "value": 106 }, ... ] }, { "provider": "kvm", "qom_path": "/machine/unattached/device[1]" "stats": [ { "name": "guest_mode", "value": 0 }, { "name": "directed_yield_successful", "value": 0 }, { "name": "directed_yield_attempted", "value": 106 }, ... ] }, ] } - Retrieve the schemas: { "execute": "query-stats-schemas" } { "return": [ { "provider": "kvm", "target": "vcpu", "stats": [ { "name": "guest_mode", "unit": "none", "base": 10, "exponent": 0, "type": "instant" }, { "name": "directed_yield_successful", "unit": "none", "base": 10, "exponent": 0, "type": "cumulative" }, ... ] }, { "provider": "kvm", "target": "vm", "stats": [ { "name": "max_mmu_page_hash_collisions", "unit": "none", "base": 10, "exponent": 0, "type": "peak" }, ... ] }, { "provider": "xyz", "target": "vm", "stats": [ ... ] } ] } Signed-off-by: Mark Kanda <mark.kanda@oracle.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2022-02-15 16:04:31 +01:00
#
# Since: 7.1
##
{ 'command': 'query-stats-schemas',
'data': { '*provider': 'StatsProvider' },
qmp: Support for querying stats Gathering statistics is important for development, for monitoring and for performance measurement. There are tools such as kvm_stat that do this and they rely on the _user_ knowing the interesting data points rather than the tool (which can treat them as opaque). The commands introduced in this commit introduce QMP support for querying stats; the goal is to take the capabilities of these tools and making them available throughout the whole virtualization stack, so that one can observe, monitor and measure virtual machines without having shell access + root on the host that runs them. query-stats returns a list of all stats per target type (only VM and vCPU to start); future commits add extra options for specifying stat names, vCPU qom paths, and providers. All these are used by the HMP command "info stats". Because of the development usecases around statistics, a good HMP interface is important. query-stats-schemas returns a list of stats included in each target type, with an option for specifying the provider. The concepts in the schema are based on the KVM binary stats' own introspection data, just translated to QAPI. There are two reasons to have a separate schema that is not tied to the QAPI schema. The first is the contents of the schemas: the new introspection data provides different information than the QAPI data, namely unit of measurement, how the numbers are gathered and change (peak/instant/cumulative/histogram), and histogram bucket sizes. There's really no reason to have this kind of metadata in the QAPI introspection schema (except possibly for the unit of measure, but there's a very weak justification). Another reason is the dynamicity of the schema. The QAPI introspection data is very much static; and while QOM is somewhat more dynamic, generally we consider that to be a bug rather than a feature these days. On the other hand, the statistics that are exposed by QEMU might be passed through from another source, such as KVM, and the disadvantages of manually updating the QAPI schema for outweight the benefits from vetting the statistics and filtering out anything that seems "too unstable". Running old QEMU with new kernel is a supported usecase; if old QEMU cannot expose statistics from a new kernel, or if a kernel developer needs to change QEMU before gathering new info from the new kernel, then that is a poor user interface. The framework provides a method to register callbacks for these QMP commands. Most of the work in fact is done by the callbacks, and a large majority of this patch is new QAPI structs and commands. Examples (with KVM stats): - Query all VM stats: { "execute": "query-stats", "arguments" : { "target": "vm" } } { "return": [ { "provider": "kvm", "stats": [ { "name": "max_mmu_page_hash_collisions", "value": 0 }, { "name": "max_mmu_rmap_size", "value": 0 }, { "name": "nx_lpage_splits", "value": 148 }, ... ] }, { "provider": "xyz", "stats": [ ... ] } ] } - Query all vCPU stats: { "execute": "query-stats", "arguments" : { "target": "vcpu" } } { "return": [ { "provider": "kvm", "qom_path": "/machine/unattached/device[0]" "stats": [ { "name": "guest_mode", "value": 0 }, { "name": "directed_yield_successful", "value": 0 }, { "name": "directed_yield_attempted", "value": 106 }, ... ] }, { "provider": "kvm", "qom_path": "/machine/unattached/device[1]" "stats": [ { "name": "guest_mode", "value": 0 }, { "name": "directed_yield_successful", "value": 0 }, { "name": "directed_yield_attempted", "value": 106 }, ... ] }, ] } - Retrieve the schemas: { "execute": "query-stats-schemas" } { "return": [ { "provider": "kvm", "target": "vcpu", "stats": [ { "name": "guest_mode", "unit": "none", "base": 10, "exponent": 0, "type": "instant" }, { "name": "directed_yield_successful", "unit": "none", "base": 10, "exponent": 0, "type": "cumulative" }, ... ] }, { "provider": "kvm", "target": "vm", "stats": [ { "name": "max_mmu_page_hash_collisions", "unit": "none", "base": 10, "exponent": 0, "type": "peak" }, ... ] }, { "provider": "xyz", "target": "vm", "stats": [ ... ] } ] } Signed-off-by: Mark Kanda <mark.kanda@oracle.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2022-02-15 16:04:31 +01:00
'returns': [ 'StatsSchema' ] }