mirror_qemu/qga/qapi-schema.json

1803 lines
45 KiB
JSON
Raw Permalink Normal View History

# *-*- Mode: Python -*-*
# vim: filetype=python
##
# = General note concerning the use of guest agent interfaces
#
# "unsupported" is a higher-level error than the errors that
# individual commands might document. The caller should always be
# prepared to receive QERR_UNSUPPORTED, even if the given command
# doesn't specify it, or doesn't document any failure mode at all.
##
##
# = QEMU guest agent protocol commands and structs
##
{ 'pragma': { 'doc-required': true } }
# Lists with items allowed to permit QAPI rule violations; think twice
# before you add to them!
{ 'pragma': {
# Types whose member names may use '_'
'member-name-exceptions': [
'GuestAgentInfo'
],
# Commands allowed to return a non-dictionary:
'command-returns-exceptions': [
'guest-file-open',
'guest-fsfreeze-freeze',
'guest-fsfreeze-freeze-list',
'guest-fsfreeze-status',
'guest-fsfreeze-thaw',
'guest-get-time',
'guest-set-vcpus',
'guest-sync',
'guest-sync-delimited' ],
# Types and commands with undocumented members:
'documentation-exceptions': [
'GuestNVMeSmart' ] } }
##
# @guest-sync-delimited:
#
# Echo back a unique integer value, and prepend to response a leading
# sentinel byte (0xFF) the client can check scan for.
#
# This is used by clients talking to the guest agent over the wire to
# ensure the stream is in sync and doesn't contain stale data from
# previous client. It must be issued upon initial connection, and
# after any client-side timeouts (including timeouts on receiving a
# response to this command).
#
# After issuing this request, all guest agent responses should be
# ignored until the response containing the unique integer value the
# client passed in is returned. Receival of the 0xFF sentinel byte
# must be handled as an indication that the client's
# lexer/tokenizer/parser state should be flushed/reset in preparation
# for reliably receiving the subsequent response. As an optimization,
# clients may opt to ignore all data until a sentinel value is
# receiving to avoid unnecessary processing of stale data.
#
# Similarly, clients should also precede this *request* with a 0xFF
# byte to make sure the guest agent flushes any partially read JSON
# data from a previous client connection.
#
# @id: randomly generated 64-bit integer
#
# Returns: The unique integer id passed in by the client
#
# Since: 1.1
##
{ 'command': 'guest-sync-delimited',
'data': { 'id': 'int' },
'returns': 'int' }
##
# @guest-sync:
#
# Echo back a unique integer value
#
# This is used by clients talking to the guest agent over the wire to
# ensure the stream is in sync and doesn't contain stale data from
# previous client. All guest agent responses should be ignored until
# the provided unique integer value is returned, and it is up to the
# client to handle stale whole or partially-delivered JSON text in
# such a way that this response can be obtained.
#
# In cases where a partial stale response was previously received by
# the client, this cannot always be done reliably. One particular
# scenario being if qemu-ga responses are fed character-by-character
# into a JSON parser. In these situations, using guest-sync-delimited
# may be optimal.
#
# For clients that fetch responses line by line and convert them to
# JSON objects, guest-sync should be sufficient, but note that in
# cases where the channel is dirty some attempts at parsing the
# response may result in a parser error.
#
# Such clients should also precede this command with a 0xFF byte to
# make sure the guest agent flushes any partially read JSON data from
# a previous session.
#
# @id: randomly generated 64-bit integer
#
# Returns: The unique integer id passed in by the client
#
# Since: 0.15.0
##
{ 'command': 'guest-sync',
'data': { 'id': 'int' },
'returns': 'int' }
##
# @guest-ping:
#
# Ping the guest agent, a non-error return implies success
#
# Since: 0.15.0
##
{ 'command': 'guest-ping' }
##
# @guest-get-time:
#
# Get the information about guest's System Time relative to the Epoch
# of 1970-01-01 in UTC.
#
# Returns: Time in nanoseconds.
#
# Since: 1.5
##
{ 'command': 'guest-get-time',
'returns': 'int' }
##
# @guest-set-time:
#
# Set guest time.
#
# When a guest is paused or migrated to a file then loaded from that
# file, the guest OS has no idea that there was a big gap in the time.
# Depending on how long the gap was, NTP might not be able to
# resynchronize the guest.
#
# This command tries to set guest's System Time to the given value,
# then sets the Hardware Clock (RTC) to the current System Time. This
# will make it easier for a guest to resynchronize without waiting for
# NTP. If no @time is specified, then the time to set is read from
# RTC. However, this may not be supported on all platforms (i.e.
# Windows). If that's the case users are advised to always pass a
# value.
#
# @time: time of nanoseconds, relative to the Epoch of 1970-01-01 in
# UTC.
#
# Since: 1.5
##
{ 'command': 'guest-set-time',
'data': { '*time': 'int' } }
##
# @GuestAgentCommandInfo:
#
# Information about guest agent commands.
#
# @name: name of the command
#
# @enabled: whether command is currently enabled by guest admin
#
# @success-response: whether command returns a response on success
# (since 1.7)
#
# Since: 1.1.0
##
{ 'struct': 'GuestAgentCommandInfo',
'data': { 'name': 'str', 'enabled': 'bool', 'success-response': 'bool' } }
##
# @GuestAgentInfo:
#
# Information about guest agent.
#
# @version: guest agent version
#
# @supported_commands: Information about guest agent commands
#
# Since: 0.15.0
##
{ 'struct': 'GuestAgentInfo',
'data': { 'version': 'str',
'supported_commands': ['GuestAgentCommandInfo'] } }
##
# @guest-info:
#
# Get some information about the guest agent.
#
# Returns: @GuestAgentInfo
#
# Since: 0.15.0
##
{ 'command': 'guest-info',
'returns': 'GuestAgentInfo' }
##
# @guest-shutdown:
#
# Initiate guest-activated shutdown. Note: this is an asynchronous
# shutdown request, with no guarantee of successful shutdown.
#
# @mode: "halt", "powerdown" (default), or "reboot"
#
# This command does NOT return a response on success. Success
# condition is indicated by the VM exiting with a zero exit status or,
# when running with --no-shutdown, by issuing the query-status QMP
# command to confirm the VM status is "shutdown".
#
# Since: 0.15.0
##
{ 'command': 'guest-shutdown', 'data': { '*mode': 'str' },
'success-response': false }
##
# @guest-file-open:
#
# Open a file in the guest and retrieve a file handle for it
#
# @path: Full path to the file in the guest to open.
#
# @mode: open mode, as per fopen(), "r" is the default.
#
# Returns: Guest file handle
#
# Since: 0.15.0
##
{ 'command': 'guest-file-open',
'data': { 'path': 'str', '*mode': 'str' },
'returns': 'int' }
##
# @guest-file-close:
#
# Close an open file in the guest
#
# @handle: filehandle returned by guest-file-open
#
# Since: 0.15.0
##
{ 'command': 'guest-file-close',
'data': { 'handle': 'int' } }
##
# @GuestFileRead:
#
# Result of guest agent file-read operation
#
# @count: number of bytes read (note: count is *before*
# base64-encoding is applied)
#
# @buf-b64: base64-encoded bytes read
#
# @eof: whether EOF was encountered during read operation.
#
# Since: 0.15.0
##
{ 'struct': 'GuestFileRead',
'data': { 'count': 'int', 'buf-b64': 'str', 'eof': 'bool' } }
##
# @guest-file-read:
#
# Read from an open file in the guest. Data will be base64-encoded.
# As this command is just for limited, ad-hoc debugging, such as log
# file access, the number of bytes to read is limited to 48 MB.
#
# @handle: filehandle returned by guest-file-open
#
# @count: maximum number of bytes to read (default is 4KB, maximum is
# 48MB)
#
# Returns: @GuestFileRead
#
# Since: 0.15.0
##
{ 'command': 'guest-file-read',
'data': { 'handle': 'int', '*count': 'int' },
'returns': 'GuestFileRead' }
##
# @GuestFileWrite:
#
# Result of guest agent file-write operation
#
# @count: number of bytes written (note: count is actual bytes
# written, after base64-decoding of provided buffer)
#
# @eof: whether EOF was encountered during write operation.
#
# Since: 0.15.0
##
{ 'struct': 'GuestFileWrite',
'data': { 'count': 'int', 'eof': 'bool' } }
##
# @guest-file-write:
#
# Write to an open file in the guest.
#
# @handle: filehandle returned by guest-file-open
#
# @buf-b64: base64-encoded string representing data to be written
#
# @count: bytes to write (actual bytes, after base64-decode), default
# is all content in buf-b64 buffer after base64 decoding
#
# Returns: @GuestFileWrite
#
# Since: 0.15.0
##
{ 'command': 'guest-file-write',
'data': { 'handle': 'int', 'buf-b64': 'str', '*count': 'int' },
'returns': 'GuestFileWrite' }
##
# @GuestFileSeek:
#
# Result of guest agent file-seek operation
#
# @position: current file position
#
# @eof: whether EOF was encountered during file seek
#
# Since: 0.15.0
##
{ 'struct': 'GuestFileSeek',
'data': { 'position': 'int', 'eof': 'bool' } }
##
# @QGASeek:
#
# Symbolic names for use in @guest-file-seek
#
# @set: Set to the specified offset (same effect as 'whence':0)
#
# @cur: Add offset to the current location (same effect as 'whence':1)
#
# @end: Add offset to the end of the file (same effect as 'whence':2)
#
# Since: 2.6
##
{ 'enum': 'QGASeek', 'data': [ 'set', 'cur', 'end' ] }
##
# @GuestFileWhence:
#
# Controls the meaning of offset to @guest-file-seek.
#
# @value: Integral value (0 for set, 1 for cur, 2 for end), available
# for historical reasons, and might differ from the host's or
# guest's SEEK_* values (since: 0.15)
#
# @name: Symbolic name, and preferred interface
#
# Since: 2.6
##
{ 'alternate': 'GuestFileWhence',
'data': { 'value': 'int', 'name': 'QGASeek' } }
##
# @guest-file-seek:
#
# Seek to a position in the file, as with fseek(), and return the
# current file position afterward. Also encapsulates ftell()'s
# functionality, with offset=0 and whence=1.
#
# @handle: filehandle returned by guest-file-open
#
# @offset: bytes to skip over in the file stream
#
# @whence: Symbolic or numeric code for interpreting offset
#
# Returns: @GuestFileSeek
#
# Since: 0.15.0
##
{ 'command': 'guest-file-seek',
'data': { 'handle': 'int', 'offset': 'int',
'whence': 'GuestFileWhence' },
'returns': 'GuestFileSeek' }
##
# @guest-file-flush:
#
# Write file changes buffered in userspace to disk/kernel buffers
#
# @handle: filehandle returned by guest-file-open
#
# Since: 0.15.0
##
{ 'command': 'guest-file-flush',
'data': { 'handle': 'int' } }
##
# @GuestFsfreezeStatus:
#
# An enumeration of filesystem freeze states
#
# @thawed: filesystems thawed/unfrozen
#
# @frozen: all non-network guest filesystems frozen
#
# Since: 0.15.0
##
{ 'enum': 'GuestFsfreezeStatus',
'data': [ 'thawed', 'frozen' ] }
##
# @guest-fsfreeze-status:
#
# Get guest fsfreeze state.
#
# Returns: GuestFsfreezeStatus ("thawed", "frozen", etc., as defined
# below)
#
# Note: This may fail to properly report the current state as a result
# of some other guest processes having issued an fs freeze/thaw.
#
# Since: 0.15.0
##
{ 'command': 'guest-fsfreeze-status',
'returns': 'GuestFsfreezeStatus' }
##
# @guest-fsfreeze-freeze:
#
# Sync and freeze all freezable, local guest filesystems. If this
# command succeeded, you may call @guest-fsfreeze-thaw later to
# unfreeze.
#
# On error, all filesystems will be thawed. If no filesystems are
# frozen as a result of this call, then @guest-fsfreeze-status will
# remain "thawed" and calling @guest-fsfreeze-thaw is not necessary.
#
# Returns: Number of file systems currently frozen.
#
# Note: On Windows, the command is implemented with the help of a
# Volume Shadow-copy Service DLL helper. The frozen state is
# limited for up to 10 seconds by VSS.
#
# Since: 0.15.0
##
{ 'command': 'guest-fsfreeze-freeze',
'returns': 'int' }
##
# @guest-fsfreeze-freeze-list:
#
# Sync and freeze specified guest filesystems. See also
# @guest-fsfreeze-freeze.
#
# On error, all filesystems will be thawed.
#
# @mountpoints: an array of mountpoints of filesystems to be frozen.
# If omitted, every mounted filesystem is frozen. Invalid mount
# points are ignored.
#
# Returns: Number of file systems currently frozen.
#
# Since: 2.2
##
{ 'command': 'guest-fsfreeze-freeze-list',
'data': { '*mountpoints': ['str'] },
'returns': 'int' }
##
# @guest-fsfreeze-thaw:
#
# Unfreeze all frozen guest filesystems
#
# Returns: Number of file systems thawed by this call
#
# Note: if return value does not match the previous call to
# guest-fsfreeze-freeze, this likely means some freezable
# filesystems were unfrozen before this call, and that the
# filesystem state may have changed before issuing this command.
#
# Since: 0.15.0
##
{ 'command': 'guest-fsfreeze-thaw',
'returns': 'int' }
qemu-ga: add guest-suspend-disk As the command name implies, this command suspends the guest to disk. The suspend operation is implemented by two functions: bios_supports_mode() and guest_suspend(). Both functions are generic enough to be used by other suspend modes (introduced by next commits). Both functions will try to use the scripts provided by the pm-utils package if it's available. If it's not available, a manual method, which consists of directly writing to '/sys/power/state', will be used. To reap terminated children, a new signal handler is installed in the parent to catch SIGCHLD signals and a non-blocking call to waitpid() is done to collect their exit statuses. The statuses, however, are discarded. The approach used to query the guest for suspend support deserves some explanation. It's implemented by bios_supports_mode() and shown below: qemu-ga | create pipe | fork() ----------------- | | | | | fork() | -------------------------- | | | | | | | | exec('pm-is-supported') | | | wait() | write exit status to pipe | exit | read pipe This might look complex, but the resulting code is quite simple. The purpose of that approach is to allow qemu-ga to reap its children (semi-)automatically from its SIGCHLD handler. Implementing this the obvious way, that's, doing the exec() call from the first child process, would force us to introduce a more complex way to reap qemu-ga's children. Like registering PIDs to be reaped and having a way to wait for them when returning their exit status to qemu-ga is necessary. The approach explained above avoids that complexity. Signed-off-by: Luiz Capitulino <lcapitulino@redhat.com>
2012-02-28 18:03:03 +04:00
##
# @GuestFilesystemTrimResult:
#
# @path: path that was trimmed
#
# @error: an error message when trim failed
#
# @trimmed: bytes trimmed for this path
#
# @minimum: reported effective minimum for this path
#
# Since: 2.4
##
{ 'struct': 'GuestFilesystemTrimResult',
'data': {'path': 'str',
'*trimmed': 'int', '*minimum': 'int', '*error': 'str'} }
##
# @GuestFilesystemTrimResponse:
#
# @paths: list of @GuestFilesystemTrimResult per path that was trimmed
#
# Since: 2.4
##
{ 'struct': 'GuestFilesystemTrimResponse',
'data': {'paths': ['GuestFilesystemTrimResult']} }
##
# @guest-fstrim:
#
# Discard (or "trim") blocks which are not in use by the filesystem.
#
# @minimum: Minimum contiguous free range to discard, in bytes. Free
# ranges smaller than this may be ignored (this is a hint and the
# guest may not respect it). By increasing this value, the fstrim
# operation will complete more quickly for filesystems with badly
# fragmented free space, although not all blocks will be
# discarded. The default value is zero, meaning "discard every
# free block".
#
# Returns: A @GuestFilesystemTrimResponse which contains the status of
# all trimmed paths. (since 2.4)
#
# Since: 1.2
##
{ 'command': 'guest-fstrim',
'data': { '*minimum': 'int' },
'returns': 'GuestFilesystemTrimResponse' }
qemu-ga: add guest-suspend-disk As the command name implies, this command suspends the guest to disk. The suspend operation is implemented by two functions: bios_supports_mode() and guest_suspend(). Both functions are generic enough to be used by other suspend modes (introduced by next commits). Both functions will try to use the scripts provided by the pm-utils package if it's available. If it's not available, a manual method, which consists of directly writing to '/sys/power/state', will be used. To reap terminated children, a new signal handler is installed in the parent to catch SIGCHLD signals and a non-blocking call to waitpid() is done to collect their exit statuses. The statuses, however, are discarded. The approach used to query the guest for suspend support deserves some explanation. It's implemented by bios_supports_mode() and shown below: qemu-ga | create pipe | fork() ----------------- | | | | | fork() | -------------------------- | | | | | | | | exec('pm-is-supported') | | | wait() | write exit status to pipe | exit | read pipe This might look complex, but the resulting code is quite simple. The purpose of that approach is to allow qemu-ga to reap its children (semi-)automatically from its SIGCHLD handler. Implementing this the obvious way, that's, doing the exec() call from the first child process, would force us to introduce a more complex way to reap qemu-ga's children. Like registering PIDs to be reaped and having a way to wait for them when returning their exit status to qemu-ga is necessary. The approach explained above avoids that complexity. Signed-off-by: Luiz Capitulino <lcapitulino@redhat.com>
2012-02-28 18:03:03 +04:00
##
# @guest-suspend-disk:
qemu-ga: add guest-suspend-disk As the command name implies, this command suspends the guest to disk. The suspend operation is implemented by two functions: bios_supports_mode() and guest_suspend(). Both functions are generic enough to be used by other suspend modes (introduced by next commits). Both functions will try to use the scripts provided by the pm-utils package if it's available. If it's not available, a manual method, which consists of directly writing to '/sys/power/state', will be used. To reap terminated children, a new signal handler is installed in the parent to catch SIGCHLD signals and a non-blocking call to waitpid() is done to collect their exit statuses. The statuses, however, are discarded. The approach used to query the guest for suspend support deserves some explanation. It's implemented by bios_supports_mode() and shown below: qemu-ga | create pipe | fork() ----------------- | | | | | fork() | -------------------------- | | | | | | | | exec('pm-is-supported') | | | wait() | write exit status to pipe | exit | read pipe This might look complex, but the resulting code is quite simple. The purpose of that approach is to allow qemu-ga to reap its children (semi-)automatically from its SIGCHLD handler. Implementing this the obvious way, that's, doing the exec() call from the first child process, would force us to introduce a more complex way to reap qemu-ga's children. Like registering PIDs to be reaped and having a way to wait for them when returning their exit status to qemu-ga is necessary. The approach explained above avoids that complexity. Signed-off-by: Luiz Capitulino <lcapitulino@redhat.com>
2012-02-28 18:03:03 +04:00
#
# Suspend guest to disk.
#
# This command attempts to suspend the guest using three strategies,
# in this order:
qemu-ga: add guest-suspend-disk As the command name implies, this command suspends the guest to disk. The suspend operation is implemented by two functions: bios_supports_mode() and guest_suspend(). Both functions are generic enough to be used by other suspend modes (introduced by next commits). Both functions will try to use the scripts provided by the pm-utils package if it's available. If it's not available, a manual method, which consists of directly writing to '/sys/power/state', will be used. To reap terminated children, a new signal handler is installed in the parent to catch SIGCHLD signals and a non-blocking call to waitpid() is done to collect their exit statuses. The statuses, however, are discarded. The approach used to query the guest for suspend support deserves some explanation. It's implemented by bios_supports_mode() and shown below: qemu-ga | create pipe | fork() ----------------- | | | | | fork() | -------------------------- | | | | | | | | exec('pm-is-supported') | | | wait() | write exit status to pipe | exit | read pipe This might look complex, but the resulting code is quite simple. The purpose of that approach is to allow qemu-ga to reap its children (semi-)automatically from its SIGCHLD handler. Implementing this the obvious way, that's, doing the exec() call from the first child process, would force us to introduce a more complex way to reap qemu-ga's children. Like registering PIDs to be reaped and having a way to wait for them when returning their exit status to qemu-ga is necessary. The approach explained above avoids that complexity. Signed-off-by: Luiz Capitulino <lcapitulino@redhat.com>
2012-02-28 18:03:03 +04:00
#
# - systemd hibernate
# - pm-utils (via pm-hibernate)
# - manual write into sysfs
qemu-ga: add guest-suspend-disk As the command name implies, this command suspends the guest to disk. The suspend operation is implemented by two functions: bios_supports_mode() and guest_suspend(). Both functions are generic enough to be used by other suspend modes (introduced by next commits). Both functions will try to use the scripts provided by the pm-utils package if it's available. If it's not available, a manual method, which consists of directly writing to '/sys/power/state', will be used. To reap terminated children, a new signal handler is installed in the parent to catch SIGCHLD signals and a non-blocking call to waitpid() is done to collect their exit statuses. The statuses, however, are discarded. The approach used to query the guest for suspend support deserves some explanation. It's implemented by bios_supports_mode() and shown below: qemu-ga | create pipe | fork() ----------------- | | | | | fork() | -------------------------- | | | | | | | | exec('pm-is-supported') | | | wait() | write exit status to pipe | exit | read pipe This might look complex, but the resulting code is quite simple. The purpose of that approach is to allow qemu-ga to reap its children (semi-)automatically from its SIGCHLD handler. Implementing this the obvious way, that's, doing the exec() call from the first child process, would force us to introduce a more complex way to reap qemu-ga's children. Like registering PIDs to be reaped and having a way to wait for them when returning their exit status to qemu-ga is necessary. The approach explained above avoids that complexity. Signed-off-by: Luiz Capitulino <lcapitulino@redhat.com>
2012-02-28 18:03:03 +04:00
#
# This command does NOT return a response on success. There is a high
# chance the command succeeded if the VM exits with a zero exit status
# or, when running with --no-shutdown, by issuing the query-status QMP
# command to to confirm the VM status is "shutdown". However, the VM
# could also exit (or set its status to "shutdown") due to other
# reasons.
#
# Errors:
# - If suspend to disk is not supported, Unsupported
qemu-ga: add guest-suspend-disk As the command name implies, this command suspends the guest to disk. The suspend operation is implemented by two functions: bios_supports_mode() and guest_suspend(). Both functions are generic enough to be used by other suspend modes (introduced by next commits). Both functions will try to use the scripts provided by the pm-utils package if it's available. If it's not available, a manual method, which consists of directly writing to '/sys/power/state', will be used. To reap terminated children, a new signal handler is installed in the parent to catch SIGCHLD signals and a non-blocking call to waitpid() is done to collect their exit statuses. The statuses, however, are discarded. The approach used to query the guest for suspend support deserves some explanation. It's implemented by bios_supports_mode() and shown below: qemu-ga | create pipe | fork() ----------------- | | | | | fork() | -------------------------- | | | | | | | | exec('pm-is-supported') | | | wait() | write exit status to pipe | exit | read pipe This might look complex, but the resulting code is quite simple. The purpose of that approach is to allow qemu-ga to reap its children (semi-)automatically from its SIGCHLD handler. Implementing this the obvious way, that's, doing the exec() call from the first child process, would force us to introduce a more complex way to reap qemu-ga's children. Like registering PIDs to be reaped and having a way to wait for them when returning their exit status to qemu-ga is necessary. The approach explained above avoids that complexity. Signed-off-by: Luiz Capitulino <lcapitulino@redhat.com>
2012-02-28 18:03:03 +04:00
#
# Notes: It's strongly recommended to issue the guest-sync command
# before sending commands when the guest resumes
qemu-ga: add guest-suspend-disk As the command name implies, this command suspends the guest to disk. The suspend operation is implemented by two functions: bios_supports_mode() and guest_suspend(). Both functions are generic enough to be used by other suspend modes (introduced by next commits). Both functions will try to use the scripts provided by the pm-utils package if it's available. If it's not available, a manual method, which consists of directly writing to '/sys/power/state', will be used. To reap terminated children, a new signal handler is installed in the parent to catch SIGCHLD signals and a non-blocking call to waitpid() is done to collect their exit statuses. The statuses, however, are discarded. The approach used to query the guest for suspend support deserves some explanation. It's implemented by bios_supports_mode() and shown below: qemu-ga | create pipe | fork() ----------------- | | | | | fork() | -------------------------- | | | | | | | | exec('pm-is-supported') | | | wait() | write exit status to pipe | exit | read pipe This might look complex, but the resulting code is quite simple. The purpose of that approach is to allow qemu-ga to reap its children (semi-)automatically from its SIGCHLD handler. Implementing this the obvious way, that's, doing the exec() call from the first child process, would force us to introduce a more complex way to reap qemu-ga's children. Like registering PIDs to be reaped and having a way to wait for them when returning their exit status to qemu-ga is necessary. The approach explained above avoids that complexity. Signed-off-by: Luiz Capitulino <lcapitulino@redhat.com>
2012-02-28 18:03:03 +04:00
#
# Since: 1.1
##
{ 'command': 'guest-suspend-disk', 'success-response': false }
##
# @guest-suspend-ram:
#
# Suspend guest to ram.
#
# This command attempts to suspend the guest using three strategies,
# in this order:
#
# - systemd hibernate
# - pm-utils (via pm-hibernate)
# - manual write into sysfs
#
# IMPORTANT: guest-suspend-ram requires working wakeup support in
# QEMU. You should check QMP command query-current-machine returns
# wakeup-suspend-support: true before issuing this command. Failure
# in doing so can result in a suspended guest that QEMU will not be
# able to awaken, forcing the user to power cycle the guest to bring
# it back.
#
# This command does NOT return a response on success. There are two
# options to check for success:
#
# 1. Wait for the SUSPEND QMP event from QEMU
# 2. Issue the query-status QMP command to confirm the VM status is
# "suspended"
#
# Errors:
# - If suspend to ram is not supported, Unsupported
#
# Notes: It's strongly recommended to issue the guest-sync command
# before sending commands when the guest resumes
#
# Since: 1.1
##
{ 'command': 'guest-suspend-ram', 'success-response': false }
##
# @guest-suspend-hybrid:
#
# Save guest state to disk and suspend to ram.
#
# This command attempts to suspend the guest by executing, in this
# order:
#
# - systemd hybrid-sleep
# - pm-utils (via pm-suspend-hybrid)
#
# IMPORTANT: guest-suspend-hybrid requires working wakeup support in
# QEMU. You should check QMP command query-current-machine returns
# wakeup-suspend-support: true before issuing this command. Failure
# in doing so can result in a suspended guest that QEMU will not be
# able to awaken, forcing the user to power cycle the guest to bring
# it back.
#
# This command does NOT return a response on success. There are two
# options to check for success:
#
# 1. Wait for the SUSPEND QMP event from QEMU
# 2. Issue the query-status QMP command to confirm the VM status is
# "suspended"
#
# Errors:
# - If hybrid suspend is not supported, Unsupported
#
# Notes: It's strongly recommended to issue the guest-sync command
# before sending commands when the guest resumes
#
# Since: 1.1
##
{ 'command': 'guest-suspend-hybrid', 'success-response': false }
##
# @GuestIpAddressType:
#
# An enumeration of supported IP address types
#
# @ipv4: IP version 4
#
# @ipv6: IP version 6
#
# Since: 1.1
##
{ 'enum': 'GuestIpAddressType',
'data': [ 'ipv4', 'ipv6' ] }
##
# @GuestIpAddress:
#
# @ip-address: IP address
#
# @ip-address-type: Type of @ip-address (e.g. ipv4, ipv6)
#
# @prefix: Network prefix length of @ip-address
#
# Since: 1.1
##
{ 'struct': 'GuestIpAddress',
'data': {'ip-address': 'str',
'ip-address-type': 'GuestIpAddressType',
'prefix': 'int'} }
##
# @GuestNetworkInterfaceStat:
#
# @rx-bytes: total bytes received
#
# @rx-packets: total packets received
#
# @rx-errs: bad packets received
#
# @rx-dropped: receiver dropped packets
#
# @tx-bytes: total bytes transmitted
#
# @tx-packets: total packets transmitted
#
# @tx-errs: packet transmit problems
#
# @tx-dropped: dropped packets transmitted
#
# Since: 2.11
##
{ 'struct': 'GuestNetworkInterfaceStat',
'data': {'rx-bytes': 'uint64',
'rx-packets': 'uint64',
'rx-errs': 'uint64',
'rx-dropped': 'uint64',
'tx-bytes': 'uint64',
'tx-packets': 'uint64',
'tx-errs': 'uint64',
'tx-dropped': 'uint64'
} }
##
# @GuestNetworkInterface:
#
# @name: The name of interface for which info are being delivered
#
# @hardware-address: Hardware address of @name
#
# @ip-addresses: List of addresses assigned to @name
#
# @statistics: various statistic counters related to @name (since
# 2.11)
#
# Since: 1.1
##
{ 'struct': 'GuestNetworkInterface',
'data': {'name': 'str',
'*hardware-address': 'str',
'*ip-addresses': ['GuestIpAddress'],
'*statistics': 'GuestNetworkInterfaceStat' } }
##
# @guest-network-get-interfaces:
#
# Get list of guest IP addresses, MAC addresses and netmasks.
#
# Returns: List of GuestNetworkInterface
#
# Since: 1.1
##
{ 'command': 'guest-network-get-interfaces',
'returns': ['GuestNetworkInterface'] }
##
# @GuestLogicalProcessor:
#
# @logical-id: Arbitrary guest-specific unique identifier of the VCPU.
#
# @online: Whether the VCPU is enabled.
#
# @can-offline: Whether offlining the VCPU is possible. This member
# is always filled in by the guest agent when the structure is
# returned, and always ignored on input (hence it can be omitted
# then).
#
# Since: 1.5
##
{ 'struct': 'GuestLogicalProcessor',
'data': {'logical-id': 'int',
'online': 'bool',
'*can-offline': 'bool'} }
##
# @guest-get-vcpus:
#
# Retrieve the list of the guest's logical processors.
#
# This is a read-only operation.
#
# Returns: The list of all VCPUs the guest knows about. Each VCPU is
# put on the list exactly once, but their order is unspecified.
#
# Since: 1.5
##
{ 'command': 'guest-get-vcpus',
'returns': ['GuestLogicalProcessor'] }
##
# @guest-set-vcpus:
#
# Attempt to reconfigure (currently: enable/disable) logical
# processors inside the guest.
#
# @vcpus: The logical processors to be reconfigured. This list is
# processed node by node in order. In each node @logical-id is
# used to look up the guest VCPU, for which @online specifies the
# requested state. The set of distinct @logical-id's is only
# required to be a subset of the guest-supported identifiers.
# There's no restriction on list length or on repeating the same
# @logical-id (with possibly different @online field). Preferably
# the input list should describe a modified subset of
# @guest-get-vcpus' return value.
#
# Returns: The length of the initial sublist that has been
# successfully processed. The guest agent maximizes this value.
# Possible cases:
#
# - 0:
# if the @vcpus list was empty on input. Guest state has not
# been changed. Otherwise,
# - < length(@vcpus):
# more than zero initial nodes have been processed, but not the
# entire @vcpus list. Guest state has changed accordingly. To
# retrieve the error (assuming it persists), repeat the call
# with the successfully processed initial sublist removed.
# Otherwise,
# - length(@vcpus):
# call successful.
#
# Errors:
# - If the reconfiguration of the first node in @vcpus failed.
# Guest state has not been changed.
#
# Since: 1.5
##
{ 'command': 'guest-set-vcpus',
'data': {'vcpus': ['GuestLogicalProcessor'] },
'returns': 'int' }
qga: Add guest-get-fsinfo command Add command to get mounted filesystems information in the guest. The returned value contains a list of mountpoint paths and corresponding disks info such as disk bus type, drive address, and the disk controllers' PCI addresses, so that management layer such as libvirt can resolve the disk backends. For example, when `lsblk' result is: NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sdb 8:16 0 1G 0 disk `-sdb1 8:17 0 1024M 0 part `-vg0-lv0 253:1 0 1.4G 0 lvm /mnt/test sdc 8:32 0 1G 0 disk `-sdc1 8:33 0 512M 0 part `-vg0-lv0 253:1 0 1.4G 0 lvm /mnt/test vda 252:0 0 25G 0 disk `-vda1 252:1 0 25G 0 part / where sdb is a SCSI disk with PCI controller 0000:00:0a.0 and ID=1, sdc is an IDE disk with PCI controller 0000:00:01.1, and vda is a virtio-blk disk with PCI device 0000:00:06.0, guest-get-fsinfo command will return the following result: {"return": [{"name":"dm-1", "mountpoint":"/mnt/test", "disk":[ {"bus-type":"scsi","bus":0,"unit":1,"target":0, "pci-controller":{"bus":0,"slot":10,"domain":0,"function":0}}, {"bus-type":"ide","bus":0,"unit":0,"target":0, "pci-controller":{"bus":0,"slot":1,"domain":0,"function":1}}], "type":"xfs"}, {"name":"vda1", "mountpoint":"/", "disk":[ {"bus-type":"virtio","bus":0,"unit":0,"target":0, "pci-controller":{"bus":0,"slot":6,"domain":0,"function":0}}], "type":"ext4"}]} In Linux guest, the disk information is resolved from sysfs. So far, it only supports virtio-blk, virtio-scsi, IDE, SATA, SCSI disks on x86 hosts, and "disk" parameter may be empty for unsupported disk types. Signed-off-by: Tomoki Sekiyama <tomoki.sekiyama@hds.com> *updated schema to report 2.2 as initial supported version Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2014-07-01 01:51:34 +04:00
##
# @GuestDiskBusType:
qga: Add guest-get-fsinfo command Add command to get mounted filesystems information in the guest. The returned value contains a list of mountpoint paths and corresponding disks info such as disk bus type, drive address, and the disk controllers' PCI addresses, so that management layer such as libvirt can resolve the disk backends. For example, when `lsblk' result is: NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sdb 8:16 0 1G 0 disk `-sdb1 8:17 0 1024M 0 part `-vg0-lv0 253:1 0 1.4G 0 lvm /mnt/test sdc 8:32 0 1G 0 disk `-sdc1 8:33 0 512M 0 part `-vg0-lv0 253:1 0 1.4G 0 lvm /mnt/test vda 252:0 0 25G 0 disk `-vda1 252:1 0 25G 0 part / where sdb is a SCSI disk with PCI controller 0000:00:0a.0 and ID=1, sdc is an IDE disk with PCI controller 0000:00:01.1, and vda is a virtio-blk disk with PCI device 0000:00:06.0, guest-get-fsinfo command will return the following result: {"return": [{"name":"dm-1", "mountpoint":"/mnt/test", "disk":[ {"bus-type":"scsi","bus":0,"unit":1,"target":0, "pci-controller":{"bus":0,"slot":10,"domain":0,"function":0}}, {"bus-type":"ide","bus":0,"unit":0,"target":0, "pci-controller":{"bus":0,"slot":1,"domain":0,"function":1}}], "type":"xfs"}, {"name":"vda1", "mountpoint":"/", "disk":[ {"bus-type":"virtio","bus":0,"unit":0,"target":0, "pci-controller":{"bus":0,"slot":6,"domain":0,"function":0}}], "type":"ext4"}]} In Linux guest, the disk information is resolved from sysfs. So far, it only supports virtio-blk, virtio-scsi, IDE, SATA, SCSI disks on x86 hosts, and "disk" parameter may be empty for unsupported disk types. Signed-off-by: Tomoki Sekiyama <tomoki.sekiyama@hds.com> *updated schema to report 2.2 as initial supported version Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2014-07-01 01:51:34 +04:00
#
# An enumeration of bus type of disks
#
# @ide: IDE disks
#
qga: Add guest-get-fsinfo command Add command to get mounted filesystems information in the guest. The returned value contains a list of mountpoint paths and corresponding disks info such as disk bus type, drive address, and the disk controllers' PCI addresses, so that management layer such as libvirt can resolve the disk backends. For example, when `lsblk' result is: NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sdb 8:16 0 1G 0 disk `-sdb1 8:17 0 1024M 0 part `-vg0-lv0 253:1 0 1.4G 0 lvm /mnt/test sdc 8:32 0 1G 0 disk `-sdc1 8:33 0 512M 0 part `-vg0-lv0 253:1 0 1.4G 0 lvm /mnt/test vda 252:0 0 25G 0 disk `-vda1 252:1 0 25G 0 part / where sdb is a SCSI disk with PCI controller 0000:00:0a.0 and ID=1, sdc is an IDE disk with PCI controller 0000:00:01.1, and vda is a virtio-blk disk with PCI device 0000:00:06.0, guest-get-fsinfo command will return the following result: {"return": [{"name":"dm-1", "mountpoint":"/mnt/test", "disk":[ {"bus-type":"scsi","bus":0,"unit":1,"target":0, "pci-controller":{"bus":0,"slot":10,"domain":0,"function":0}}, {"bus-type":"ide","bus":0,"unit":0,"target":0, "pci-controller":{"bus":0,"slot":1,"domain":0,"function":1}}], "type":"xfs"}, {"name":"vda1", "mountpoint":"/", "disk":[ {"bus-type":"virtio","bus":0,"unit":0,"target":0, "pci-controller":{"bus":0,"slot":6,"domain":0,"function":0}}], "type":"ext4"}]} In Linux guest, the disk information is resolved from sysfs. So far, it only supports virtio-blk, virtio-scsi, IDE, SATA, SCSI disks on x86 hosts, and "disk" parameter may be empty for unsupported disk types. Signed-off-by: Tomoki Sekiyama <tomoki.sekiyama@hds.com> *updated schema to report 2.2 as initial supported version Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2014-07-01 01:51:34 +04:00
# @fdc: floppy disks
#
qga: Add guest-get-fsinfo command Add command to get mounted filesystems information in the guest. The returned value contains a list of mountpoint paths and corresponding disks info such as disk bus type, drive address, and the disk controllers' PCI addresses, so that management layer such as libvirt can resolve the disk backends. For example, when `lsblk' result is: NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sdb 8:16 0 1G 0 disk `-sdb1 8:17 0 1024M 0 part `-vg0-lv0 253:1 0 1.4G 0 lvm /mnt/test sdc 8:32 0 1G 0 disk `-sdc1 8:33 0 512M 0 part `-vg0-lv0 253:1 0 1.4G 0 lvm /mnt/test vda 252:0 0 25G 0 disk `-vda1 252:1 0 25G 0 part / where sdb is a SCSI disk with PCI controller 0000:00:0a.0 and ID=1, sdc is an IDE disk with PCI controller 0000:00:01.1, and vda is a virtio-blk disk with PCI device 0000:00:06.0, guest-get-fsinfo command will return the following result: {"return": [{"name":"dm-1", "mountpoint":"/mnt/test", "disk":[ {"bus-type":"scsi","bus":0,"unit":1,"target":0, "pci-controller":{"bus":0,"slot":10,"domain":0,"function":0}}, {"bus-type":"ide","bus":0,"unit":0,"target":0, "pci-controller":{"bus":0,"slot":1,"domain":0,"function":1}}], "type":"xfs"}, {"name":"vda1", "mountpoint":"/", "disk":[ {"bus-type":"virtio","bus":0,"unit":0,"target":0, "pci-controller":{"bus":0,"slot":6,"domain":0,"function":0}}], "type":"ext4"}]} In Linux guest, the disk information is resolved from sysfs. So far, it only supports virtio-blk, virtio-scsi, IDE, SATA, SCSI disks on x86 hosts, and "disk" parameter may be empty for unsupported disk types. Signed-off-by: Tomoki Sekiyama <tomoki.sekiyama@hds.com> *updated schema to report 2.2 as initial supported version Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2014-07-01 01:51:34 +04:00
# @scsi: SCSI disks
#
qga: Add guest-get-fsinfo command Add command to get mounted filesystems information in the guest. The returned value contains a list of mountpoint paths and corresponding disks info such as disk bus type, drive address, and the disk controllers' PCI addresses, so that management layer such as libvirt can resolve the disk backends. For example, when `lsblk' result is: NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sdb 8:16 0 1G 0 disk `-sdb1 8:17 0 1024M 0 part `-vg0-lv0 253:1 0 1.4G 0 lvm /mnt/test sdc 8:32 0 1G 0 disk `-sdc1 8:33 0 512M 0 part `-vg0-lv0 253:1 0 1.4G 0 lvm /mnt/test vda 252:0 0 25G 0 disk `-vda1 252:1 0 25G 0 part / where sdb is a SCSI disk with PCI controller 0000:00:0a.0 and ID=1, sdc is an IDE disk with PCI controller 0000:00:01.1, and vda is a virtio-blk disk with PCI device 0000:00:06.0, guest-get-fsinfo command will return the following result: {"return": [{"name":"dm-1", "mountpoint":"/mnt/test", "disk":[ {"bus-type":"scsi","bus":0,"unit":1,"target":0, "pci-controller":{"bus":0,"slot":10,"domain":0,"function":0}}, {"bus-type":"ide","bus":0,"unit":0,"target":0, "pci-controller":{"bus":0,"slot":1,"domain":0,"function":1}}], "type":"xfs"}, {"name":"vda1", "mountpoint":"/", "disk":[ {"bus-type":"virtio","bus":0,"unit":0,"target":0, "pci-controller":{"bus":0,"slot":6,"domain":0,"function":0}}], "type":"ext4"}]} In Linux guest, the disk information is resolved from sysfs. So far, it only supports virtio-blk, virtio-scsi, IDE, SATA, SCSI disks on x86 hosts, and "disk" parameter may be empty for unsupported disk types. Signed-off-by: Tomoki Sekiyama <tomoki.sekiyama@hds.com> *updated schema to report 2.2 as initial supported version Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2014-07-01 01:51:34 +04:00
# @virtio: virtio disks
#
qga: Add guest-get-fsinfo command Add command to get mounted filesystems information in the guest. The returned value contains a list of mountpoint paths and corresponding disks info such as disk bus type, drive address, and the disk controllers' PCI addresses, so that management layer such as libvirt can resolve the disk backends. For example, when `lsblk' result is: NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sdb 8:16 0 1G 0 disk `-sdb1 8:17 0 1024M 0 part `-vg0-lv0 253:1 0 1.4G 0 lvm /mnt/test sdc 8:32 0 1G 0 disk `-sdc1 8:33 0 512M 0 part `-vg0-lv0 253:1 0 1.4G 0 lvm /mnt/test vda 252:0 0 25G 0 disk `-vda1 252:1 0 25G 0 part / where sdb is a SCSI disk with PCI controller 0000:00:0a.0 and ID=1, sdc is an IDE disk with PCI controller 0000:00:01.1, and vda is a virtio-blk disk with PCI device 0000:00:06.0, guest-get-fsinfo command will return the following result: {"return": [{"name":"dm-1", "mountpoint":"/mnt/test", "disk":[ {"bus-type":"scsi","bus":0,"unit":1,"target":0, "pci-controller":{"bus":0,"slot":10,"domain":0,"function":0}}, {"bus-type":"ide","bus":0,"unit":0,"target":0, "pci-controller":{"bus":0,"slot":1,"domain":0,"function":1}}], "type":"xfs"}, {"name":"vda1", "mountpoint":"/", "disk":[ {"bus-type":"virtio","bus":0,"unit":0,"target":0, "pci-controller":{"bus":0,"slot":6,"domain":0,"function":0}}], "type":"ext4"}]} In Linux guest, the disk information is resolved from sysfs. So far, it only supports virtio-blk, virtio-scsi, IDE, SATA, SCSI disks on x86 hosts, and "disk" parameter may be empty for unsupported disk types. Signed-off-by: Tomoki Sekiyama <tomoki.sekiyama@hds.com> *updated schema to report 2.2 as initial supported version Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2014-07-01 01:51:34 +04:00
# @xen: Xen disks
#
qga: Add guest-get-fsinfo command Add command to get mounted filesystems information in the guest. The returned value contains a list of mountpoint paths and corresponding disks info such as disk bus type, drive address, and the disk controllers' PCI addresses, so that management layer such as libvirt can resolve the disk backends. For example, when `lsblk' result is: NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sdb 8:16 0 1G 0 disk `-sdb1 8:17 0 1024M 0 part `-vg0-lv0 253:1 0 1.4G 0 lvm /mnt/test sdc 8:32 0 1G 0 disk `-sdc1 8:33 0 512M 0 part `-vg0-lv0 253:1 0 1.4G 0 lvm /mnt/test vda 252:0 0 25G 0 disk `-vda1 252:1 0 25G 0 part / where sdb is a SCSI disk with PCI controller 0000:00:0a.0 and ID=1, sdc is an IDE disk with PCI controller 0000:00:01.1, and vda is a virtio-blk disk with PCI device 0000:00:06.0, guest-get-fsinfo command will return the following result: {"return": [{"name":"dm-1", "mountpoint":"/mnt/test", "disk":[ {"bus-type":"scsi","bus":0,"unit":1,"target":0, "pci-controller":{"bus":0,"slot":10,"domain":0,"function":0}}, {"bus-type":"ide","bus":0,"unit":0,"target":0, "pci-controller":{"bus":0,"slot":1,"domain":0,"function":1}}], "type":"xfs"}, {"name":"vda1", "mountpoint":"/", "disk":[ {"bus-type":"virtio","bus":0,"unit":0,"target":0, "pci-controller":{"bus":0,"slot":6,"domain":0,"function":0}}], "type":"ext4"}]} In Linux guest, the disk information is resolved from sysfs. So far, it only supports virtio-blk, virtio-scsi, IDE, SATA, SCSI disks on x86 hosts, and "disk" parameter may be empty for unsupported disk types. Signed-off-by: Tomoki Sekiyama <tomoki.sekiyama@hds.com> *updated schema to report 2.2 as initial supported version Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2014-07-01 01:51:34 +04:00
# @usb: USB disks
#
qga: Add guest-get-fsinfo command Add command to get mounted filesystems information in the guest. The returned value contains a list of mountpoint paths and corresponding disks info such as disk bus type, drive address, and the disk controllers' PCI addresses, so that management layer such as libvirt can resolve the disk backends. For example, when `lsblk' result is: NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sdb 8:16 0 1G 0 disk `-sdb1 8:17 0 1024M 0 part `-vg0-lv0 253:1 0 1.4G 0 lvm /mnt/test sdc 8:32 0 1G 0 disk `-sdc1 8:33 0 512M 0 part `-vg0-lv0 253:1 0 1.4G 0 lvm /mnt/test vda 252:0 0 25G 0 disk `-vda1 252:1 0 25G 0 part / where sdb is a SCSI disk with PCI controller 0000:00:0a.0 and ID=1, sdc is an IDE disk with PCI controller 0000:00:01.1, and vda is a virtio-blk disk with PCI device 0000:00:06.0, guest-get-fsinfo command will return the following result: {"return": [{"name":"dm-1", "mountpoint":"/mnt/test", "disk":[ {"bus-type":"scsi","bus":0,"unit":1,"target":0, "pci-controller":{"bus":0,"slot":10,"domain":0,"function":0}}, {"bus-type":"ide","bus":0,"unit":0,"target":0, "pci-controller":{"bus":0,"slot":1,"domain":0,"function":1}}], "type":"xfs"}, {"name":"vda1", "mountpoint":"/", "disk":[ {"bus-type":"virtio","bus":0,"unit":0,"target":0, "pci-controller":{"bus":0,"slot":6,"domain":0,"function":0}}], "type":"ext4"}]} In Linux guest, the disk information is resolved from sysfs. So far, it only supports virtio-blk, virtio-scsi, IDE, SATA, SCSI disks on x86 hosts, and "disk" parameter may be empty for unsupported disk types. Signed-off-by: Tomoki Sekiyama <tomoki.sekiyama@hds.com> *updated schema to report 2.2 as initial supported version Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2014-07-01 01:51:34 +04:00
# @uml: UML disks
#
qga: Add guest-get-fsinfo command Add command to get mounted filesystems information in the guest. The returned value contains a list of mountpoint paths and corresponding disks info such as disk bus type, drive address, and the disk controllers' PCI addresses, so that management layer such as libvirt can resolve the disk backends. For example, when `lsblk' result is: NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sdb 8:16 0 1G 0 disk `-sdb1 8:17 0 1024M 0 part `-vg0-lv0 253:1 0 1.4G 0 lvm /mnt/test sdc 8:32 0 1G 0 disk `-sdc1 8:33 0 512M 0 part `-vg0-lv0 253:1 0 1.4G 0 lvm /mnt/test vda 252:0 0 25G 0 disk `-vda1 252:1 0 25G 0 part / where sdb is a SCSI disk with PCI controller 0000:00:0a.0 and ID=1, sdc is an IDE disk with PCI controller 0000:00:01.1, and vda is a virtio-blk disk with PCI device 0000:00:06.0, guest-get-fsinfo command will return the following result: {"return": [{"name":"dm-1", "mountpoint":"/mnt/test", "disk":[ {"bus-type":"scsi","bus":0,"unit":1,"target":0, "pci-controller":{"bus":0,"slot":10,"domain":0,"function":0}}, {"bus-type":"ide","bus":0,"unit":0,"target":0, "pci-controller":{"bus":0,"slot":1,"domain":0,"function":1}}], "type":"xfs"}, {"name":"vda1", "mountpoint":"/", "disk":[ {"bus-type":"virtio","bus":0,"unit":0,"target":0, "pci-controller":{"bus":0,"slot":6,"domain":0,"function":0}}], "type":"ext4"}]} In Linux guest, the disk information is resolved from sysfs. So far, it only supports virtio-blk, virtio-scsi, IDE, SATA, SCSI disks on x86 hosts, and "disk" parameter may be empty for unsupported disk types. Signed-off-by: Tomoki Sekiyama <tomoki.sekiyama@hds.com> *updated schema to report 2.2 as initial supported version Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2014-07-01 01:51:34 +04:00
# @sata: SATA disks
#
qga: Add guest-get-fsinfo command Add command to get mounted filesystems information in the guest. The returned value contains a list of mountpoint paths and corresponding disks info such as disk bus type, drive address, and the disk controllers' PCI addresses, so that management layer such as libvirt can resolve the disk backends. For example, when `lsblk' result is: NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sdb 8:16 0 1G 0 disk `-sdb1 8:17 0 1024M 0 part `-vg0-lv0 253:1 0 1.4G 0 lvm /mnt/test sdc 8:32 0 1G 0 disk `-sdc1 8:33 0 512M 0 part `-vg0-lv0 253:1 0 1.4G 0 lvm /mnt/test vda 252:0 0 25G 0 disk `-vda1 252:1 0 25G 0 part / where sdb is a SCSI disk with PCI controller 0000:00:0a.0 and ID=1, sdc is an IDE disk with PCI controller 0000:00:01.1, and vda is a virtio-blk disk with PCI device 0000:00:06.0, guest-get-fsinfo command will return the following result: {"return": [{"name":"dm-1", "mountpoint":"/mnt/test", "disk":[ {"bus-type":"scsi","bus":0,"unit":1,"target":0, "pci-controller":{"bus":0,"slot":10,"domain":0,"function":0}}, {"bus-type":"ide","bus":0,"unit":0,"target":0, "pci-controller":{"bus":0,"slot":1,"domain":0,"function":1}}], "type":"xfs"}, {"name":"vda1", "mountpoint":"/", "disk":[ {"bus-type":"virtio","bus":0,"unit":0,"target":0, "pci-controller":{"bus":0,"slot":6,"domain":0,"function":0}}], "type":"ext4"}]} In Linux guest, the disk information is resolved from sysfs. So far, it only supports virtio-blk, virtio-scsi, IDE, SATA, SCSI disks on x86 hosts, and "disk" parameter may be empty for unsupported disk types. Signed-off-by: Tomoki Sekiyama <tomoki.sekiyama@hds.com> *updated schema to report 2.2 as initial supported version Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2014-07-01 01:51:34 +04:00
# @sd: SD cards
#
# @unknown: Unknown bus type
#
# @ieee1394: Win IEEE 1394 bus type
#
# @ssa: Win SSA bus type
#
# @fibre: Win fiber channel bus type
#
# @raid: Win RAID bus type
#
# @iscsi: Win iScsi bus type
#
# @sas: Win serial-attaches SCSI bus type
#
# @mmc: Win multimedia card (MMC) bus type
#
# @virtual: Win virtual bus type
#
# @file-backed-virtual: Win file-backed bus type
#
# @nvme: NVMe disks (since 7.1)
qga: Add guest-get-fsinfo command Add command to get mounted filesystems information in the guest. The returned value contains a list of mountpoint paths and corresponding disks info such as disk bus type, drive address, and the disk controllers' PCI addresses, so that management layer such as libvirt can resolve the disk backends. For example, when `lsblk' result is: NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sdb 8:16 0 1G 0 disk `-sdb1 8:17 0 1024M 0 part `-vg0-lv0 253:1 0 1.4G 0 lvm /mnt/test sdc 8:32 0 1G 0 disk `-sdc1 8:33 0 512M 0 part `-vg0-lv0 253:1 0 1.4G 0 lvm /mnt/test vda 252:0 0 25G 0 disk `-vda1 252:1 0 25G 0 part / where sdb is a SCSI disk with PCI controller 0000:00:0a.0 and ID=1, sdc is an IDE disk with PCI controller 0000:00:01.1, and vda is a virtio-blk disk with PCI device 0000:00:06.0, guest-get-fsinfo command will return the following result: {"return": [{"name":"dm-1", "mountpoint":"/mnt/test", "disk":[ {"bus-type":"scsi","bus":0,"unit":1,"target":0, "pci-controller":{"bus":0,"slot":10,"domain":0,"function":0}}, {"bus-type":"ide","bus":0,"unit":0,"target":0, "pci-controller":{"bus":0,"slot":1,"domain":0,"function":1}}], "type":"xfs"}, {"name":"vda1", "mountpoint":"/", "disk":[ {"bus-type":"virtio","bus":0,"unit":0,"target":0, "pci-controller":{"bus":0,"slot":6,"domain":0,"function":0}}], "type":"ext4"}]} In Linux guest, the disk information is resolved from sysfs. So far, it only supports virtio-blk, virtio-scsi, IDE, SATA, SCSI disks on x86 hosts, and "disk" parameter may be empty for unsupported disk types. Signed-off-by: Tomoki Sekiyama <tomoki.sekiyama@hds.com> *updated schema to report 2.2 as initial supported version Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2014-07-01 01:51:34 +04:00
#
# Since: 2.2; 'Unknown' and all entries below since 2.4
qga: Add guest-get-fsinfo command Add command to get mounted filesystems information in the guest. The returned value contains a list of mountpoint paths and corresponding disks info such as disk bus type, drive address, and the disk controllers' PCI addresses, so that management layer such as libvirt can resolve the disk backends. For example, when `lsblk' result is: NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sdb 8:16 0 1G 0 disk `-sdb1 8:17 0 1024M 0 part `-vg0-lv0 253:1 0 1.4G 0 lvm /mnt/test sdc 8:32 0 1G 0 disk `-sdc1 8:33 0 512M 0 part `-vg0-lv0 253:1 0 1.4G 0 lvm /mnt/test vda 252:0 0 25G 0 disk `-vda1 252:1 0 25G 0 part / where sdb is a SCSI disk with PCI controller 0000:00:0a.0 and ID=1, sdc is an IDE disk with PCI controller 0000:00:01.1, and vda is a virtio-blk disk with PCI device 0000:00:06.0, guest-get-fsinfo command will return the following result: {"return": [{"name":"dm-1", "mountpoint":"/mnt/test", "disk":[ {"bus-type":"scsi","bus":0,"unit":1,"target":0, "pci-controller":{"bus":0,"slot":10,"domain":0,"function":0}}, {"bus-type":"ide","bus":0,"unit":0,"target":0, "pci-controller":{"bus":0,"slot":1,"domain":0,"function":1}}], "type":"xfs"}, {"name":"vda1", "mountpoint":"/", "disk":[ {"bus-type":"virtio","bus":0,"unit":0,"target":0, "pci-controller":{"bus":0,"slot":6,"domain":0,"function":0}}], "type":"ext4"}]} In Linux guest, the disk information is resolved from sysfs. So far, it only supports virtio-blk, virtio-scsi, IDE, SATA, SCSI disks on x86 hosts, and "disk" parameter may be empty for unsupported disk types. Signed-off-by: Tomoki Sekiyama <tomoki.sekiyama@hds.com> *updated schema to report 2.2 as initial supported version Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2014-07-01 01:51:34 +04:00
##
{ 'enum': 'GuestDiskBusType',
'data': [ 'ide', 'fdc', 'scsi', 'virtio', 'xen', 'usb', 'uml', 'sata',
'sd', 'unknown', 'ieee1394', 'ssa', 'fibre', 'raid', 'iscsi',
'sas', 'mmc', 'virtual', 'file-backed-virtual', 'nvme' ] }
qga: Add guest-get-fsinfo command Add command to get mounted filesystems information in the guest. The returned value contains a list of mountpoint paths and corresponding disks info such as disk bus type, drive address, and the disk controllers' PCI addresses, so that management layer such as libvirt can resolve the disk backends. For example, when `lsblk' result is: NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sdb 8:16 0 1G 0 disk `-sdb1 8:17 0 1024M 0 part `-vg0-lv0 253:1 0 1.4G 0 lvm /mnt/test sdc 8:32 0 1G 0 disk `-sdc1 8:33 0 512M 0 part `-vg0-lv0 253:1 0 1.4G 0 lvm /mnt/test vda 252:0 0 25G 0 disk `-vda1 252:1 0 25G 0 part / where sdb is a SCSI disk with PCI controller 0000:00:0a.0 and ID=1, sdc is an IDE disk with PCI controller 0000:00:01.1, and vda is a virtio-blk disk with PCI device 0000:00:06.0, guest-get-fsinfo command will return the following result: {"return": [{"name":"dm-1", "mountpoint":"/mnt/test", "disk":[ {"bus-type":"scsi","bus":0,"unit":1,"target":0, "pci-controller":{"bus":0,"slot":10,"domain":0,"function":0}}, {"bus-type":"ide","bus":0,"unit":0,"target":0, "pci-controller":{"bus":0,"slot":1,"domain":0,"function":1}}], "type":"xfs"}, {"name":"vda1", "mountpoint":"/", "disk":[ {"bus-type":"virtio","bus":0,"unit":0,"target":0, "pci-controller":{"bus":0,"slot":6,"domain":0,"function":0}}], "type":"ext4"}]} In Linux guest, the disk information is resolved from sysfs. So far, it only supports virtio-blk, virtio-scsi, IDE, SATA, SCSI disks on x86 hosts, and "disk" parameter may be empty for unsupported disk types. Signed-off-by: Tomoki Sekiyama <tomoki.sekiyama@hds.com> *updated schema to report 2.2 as initial supported version Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2014-07-01 01:51:34 +04:00
##
# @GuestPCIAddress:
#
# @domain: domain id
#
qga: Add guest-get-fsinfo command Add command to get mounted filesystems information in the guest. The returned value contains a list of mountpoint paths and corresponding disks info such as disk bus type, drive address, and the disk controllers' PCI addresses, so that management layer such as libvirt can resolve the disk backends. For example, when `lsblk' result is: NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sdb 8:16 0 1G 0 disk `-sdb1 8:17 0 1024M 0 part `-vg0-lv0 253:1 0 1.4G 0 lvm /mnt/test sdc 8:32 0 1G 0 disk `-sdc1 8:33 0 512M 0 part `-vg0-lv0 253:1 0 1.4G 0 lvm /mnt/test vda 252:0 0 25G 0 disk `-vda1 252:1 0 25G 0 part / where sdb is a SCSI disk with PCI controller 0000:00:0a.0 and ID=1, sdc is an IDE disk with PCI controller 0000:00:01.1, and vda is a virtio-blk disk with PCI device 0000:00:06.0, guest-get-fsinfo command will return the following result: {"return": [{"name":"dm-1", "mountpoint":"/mnt/test", "disk":[ {"bus-type":"scsi","bus":0,"unit":1,"target":0, "pci-controller":{"bus":0,"slot":10,"domain":0,"function":0}}, {"bus-type":"ide","bus":0,"unit":0,"target":0, "pci-controller":{"bus":0,"slot":1,"domain":0,"function":1}}], "type":"xfs"}, {"name":"vda1", "mountpoint":"/", "disk":[ {"bus-type":"virtio","bus":0,"unit":0,"target":0, "pci-controller":{"bus":0,"slot":6,"domain":0,"function":0}}], "type":"ext4"}]} In Linux guest, the disk information is resolved from sysfs. So far, it only supports virtio-blk, virtio-scsi, IDE, SATA, SCSI disks on x86 hosts, and "disk" parameter may be empty for unsupported disk types. Signed-off-by: Tomoki Sekiyama <tomoki.sekiyama@hds.com> *updated schema to report 2.2 as initial supported version Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2014-07-01 01:51:34 +04:00
# @bus: bus id
#
qga: Add guest-get-fsinfo command Add command to get mounted filesystems information in the guest. The returned value contains a list of mountpoint paths and corresponding disks info such as disk bus type, drive address, and the disk controllers' PCI addresses, so that management layer such as libvirt can resolve the disk backends. For example, when `lsblk' result is: NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sdb 8:16 0 1G 0 disk `-sdb1 8:17 0 1024M 0 part `-vg0-lv0 253:1 0 1.4G 0 lvm /mnt/test sdc 8:32 0 1G 0 disk `-sdc1 8:33 0 512M 0 part `-vg0-lv0 253:1 0 1.4G 0 lvm /mnt/test vda 252:0 0 25G 0 disk `-vda1 252:1 0 25G 0 part / where sdb is a SCSI disk with PCI controller 0000:00:0a.0 and ID=1, sdc is an IDE disk with PCI controller 0000:00:01.1, and vda is a virtio-blk disk with PCI device 0000:00:06.0, guest-get-fsinfo command will return the following result: {"return": [{"name":"dm-1", "mountpoint":"/mnt/test", "disk":[ {"bus-type":"scsi","bus":0,"unit":1,"target":0, "pci-controller":{"bus":0,"slot":10,"domain":0,"function":0}}, {"bus-type":"ide","bus":0,"unit":0,"target":0, "pci-controller":{"bus":0,"slot":1,"domain":0,"function":1}}], "type":"xfs"}, {"name":"vda1", "mountpoint":"/", "disk":[ {"bus-type":"virtio","bus":0,"unit":0,"target":0, "pci-controller":{"bus":0,"slot":6,"domain":0,"function":0}}], "type":"ext4"}]} In Linux guest, the disk information is resolved from sysfs. So far, it only supports virtio-blk, virtio-scsi, IDE, SATA, SCSI disks on x86 hosts, and "disk" parameter may be empty for unsupported disk types. Signed-off-by: Tomoki Sekiyama <tomoki.sekiyama@hds.com> *updated schema to report 2.2 as initial supported version Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2014-07-01 01:51:34 +04:00
# @slot: slot id
#
qga: Add guest-get-fsinfo command Add command to get mounted filesystems information in the guest. The returned value contains a list of mountpoint paths and corresponding disks info such as disk bus type, drive address, and the disk controllers' PCI addresses, so that management layer such as libvirt can resolve the disk backends. For example, when `lsblk' result is: NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sdb 8:16 0 1G 0 disk `-sdb1 8:17 0 1024M 0 part `-vg0-lv0 253:1 0 1.4G 0 lvm /mnt/test sdc 8:32 0 1G 0 disk `-sdc1 8:33 0 512M 0 part `-vg0-lv0 253:1 0 1.4G 0 lvm /mnt/test vda 252:0 0 25G 0 disk `-vda1 252:1 0 25G 0 part / where sdb is a SCSI disk with PCI controller 0000:00:0a.0 and ID=1, sdc is an IDE disk with PCI controller 0000:00:01.1, and vda is a virtio-blk disk with PCI device 0000:00:06.0, guest-get-fsinfo command will return the following result: {"return": [{"name":"dm-1", "mountpoint":"/mnt/test", "disk":[ {"bus-type":"scsi","bus":0,"unit":1,"target":0, "pci-controller":{"bus":0,"slot":10,"domain":0,"function":0}}, {"bus-type":"ide","bus":0,"unit":0,"target":0, "pci-controller":{"bus":0,"slot":1,"domain":0,"function":1}}], "type":"xfs"}, {"name":"vda1", "mountpoint":"/", "disk":[ {"bus-type":"virtio","bus":0,"unit":0,"target":0, "pci-controller":{"bus":0,"slot":6,"domain":0,"function":0}}], "type":"ext4"}]} In Linux guest, the disk information is resolved from sysfs. So far, it only supports virtio-blk, virtio-scsi, IDE, SATA, SCSI disks on x86 hosts, and "disk" parameter may be empty for unsupported disk types. Signed-off-by: Tomoki Sekiyama <tomoki.sekiyama@hds.com> *updated schema to report 2.2 as initial supported version Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2014-07-01 01:51:34 +04:00
# @function: function id
#
# Since: 2.2
##
{ 'struct': 'GuestPCIAddress',
qga: Add guest-get-fsinfo command Add command to get mounted filesystems information in the guest. The returned value contains a list of mountpoint paths and corresponding disks info such as disk bus type, drive address, and the disk controllers' PCI addresses, so that management layer such as libvirt can resolve the disk backends. For example, when `lsblk' result is: NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sdb 8:16 0 1G 0 disk `-sdb1 8:17 0 1024M 0 part `-vg0-lv0 253:1 0 1.4G 0 lvm /mnt/test sdc 8:32 0 1G 0 disk `-sdc1 8:33 0 512M 0 part `-vg0-lv0 253:1 0 1.4G 0 lvm /mnt/test vda 252:0 0 25G 0 disk `-vda1 252:1 0 25G 0 part / where sdb is a SCSI disk with PCI controller 0000:00:0a.0 and ID=1, sdc is an IDE disk with PCI controller 0000:00:01.1, and vda is a virtio-blk disk with PCI device 0000:00:06.0, guest-get-fsinfo command will return the following result: {"return": [{"name":"dm-1", "mountpoint":"/mnt/test", "disk":[ {"bus-type":"scsi","bus":0,"unit":1,"target":0, "pci-controller":{"bus":0,"slot":10,"domain":0,"function":0}}, {"bus-type":"ide","bus":0,"unit":0,"target":0, "pci-controller":{"bus":0,"slot":1,"domain":0,"function":1}}], "type":"xfs"}, {"name":"vda1", "mountpoint":"/", "disk":[ {"bus-type":"virtio","bus":0,"unit":0,"target":0, "pci-controller":{"bus":0,"slot":6,"domain":0,"function":0}}], "type":"ext4"}]} In Linux guest, the disk information is resolved from sysfs. So far, it only supports virtio-blk, virtio-scsi, IDE, SATA, SCSI disks on x86 hosts, and "disk" parameter may be empty for unsupported disk types. Signed-off-by: Tomoki Sekiyama <tomoki.sekiyama@hds.com> *updated schema to report 2.2 as initial supported version Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2014-07-01 01:51:34 +04:00
'data': {'domain': 'int', 'bus': 'int',
'slot': 'int', 'function': 'int'} }
##
# @GuestCCWAddress:
#
# @cssid: channel subsystem image id
#
# @ssid: subchannel set id
#
# @subchno: subchannel number
#
# @devno: device number
#
# Since: 6.0
##
{ 'struct': 'GuestCCWAddress',
'data': {'cssid': 'int',
'ssid': 'int',
'subchno': 'int',
'devno': 'int'} }
qga: Add guest-get-fsinfo command Add command to get mounted filesystems information in the guest. The returned value contains a list of mountpoint paths and corresponding disks info such as disk bus type, drive address, and the disk controllers' PCI addresses, so that management layer such as libvirt can resolve the disk backends. For example, when `lsblk' result is: NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sdb 8:16 0 1G 0 disk `-sdb1 8:17 0 1024M 0 part `-vg0-lv0 253:1 0 1.4G 0 lvm /mnt/test sdc 8:32 0 1G 0 disk `-sdc1 8:33 0 512M 0 part `-vg0-lv0 253:1 0 1.4G 0 lvm /mnt/test vda 252:0 0 25G 0 disk `-vda1 252:1 0 25G 0 part / where sdb is a SCSI disk with PCI controller 0000:00:0a.0 and ID=1, sdc is an IDE disk with PCI controller 0000:00:01.1, and vda is a virtio-blk disk with PCI device 0000:00:06.0, guest-get-fsinfo command will return the following result: {"return": [{"name":"dm-1", "mountpoint":"/mnt/test", "disk":[ {"bus-type":"scsi","bus":0,"unit":1,"target":0, "pci-controller":{"bus":0,"slot":10,"domain":0,"function":0}}, {"bus-type":"ide","bus":0,"unit":0,"target":0, "pci-controller":{"bus":0,"slot":1,"domain":0,"function":1}}], "type":"xfs"}, {"name":"vda1", "mountpoint":"/", "disk":[ {"bus-type":"virtio","bus":0,"unit":0,"target":0, "pci-controller":{"bus":0,"slot":6,"domain":0,"function":0}}], "type":"ext4"}]} In Linux guest, the disk information is resolved from sysfs. So far, it only supports virtio-blk, virtio-scsi, IDE, SATA, SCSI disks on x86 hosts, and "disk" parameter may be empty for unsupported disk types. Signed-off-by: Tomoki Sekiyama <tomoki.sekiyama@hds.com> *updated schema to report 2.2 as initial supported version Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2014-07-01 01:51:34 +04:00
##
# @GuestDiskAddress:
#
# @pci-controller: controller's PCI address (fields are set to -1 if
# invalid)
#
# @bus-type: bus type
#
qga: Add guest-get-fsinfo command Add command to get mounted filesystems information in the guest. The returned value contains a list of mountpoint paths and corresponding disks info such as disk bus type, drive address, and the disk controllers' PCI addresses, so that management layer such as libvirt can resolve the disk backends. For example, when `lsblk' result is: NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sdb 8:16 0 1G 0 disk `-sdb1 8:17 0 1024M 0 part `-vg0-lv0 253:1 0 1.4G 0 lvm /mnt/test sdc 8:32 0 1G 0 disk `-sdc1 8:33 0 512M 0 part `-vg0-lv0 253:1 0 1.4G 0 lvm /mnt/test vda 252:0 0 25G 0 disk `-vda1 252:1 0 25G 0 part / where sdb is a SCSI disk with PCI controller 0000:00:0a.0 and ID=1, sdc is an IDE disk with PCI controller 0000:00:01.1, and vda is a virtio-blk disk with PCI device 0000:00:06.0, guest-get-fsinfo command will return the following result: {"return": [{"name":"dm-1", "mountpoint":"/mnt/test", "disk":[ {"bus-type":"scsi","bus":0,"unit":1,"target":0, "pci-controller":{"bus":0,"slot":10,"domain":0,"function":0}}, {"bus-type":"ide","bus":0,"unit":0,"target":0, "pci-controller":{"bus":0,"slot":1,"domain":0,"function":1}}], "type":"xfs"}, {"name":"vda1", "mountpoint":"/", "disk":[ {"bus-type":"virtio","bus":0,"unit":0,"target":0, "pci-controller":{"bus":0,"slot":6,"domain":0,"function":0}}], "type":"ext4"}]} In Linux guest, the disk information is resolved from sysfs. So far, it only supports virtio-blk, virtio-scsi, IDE, SATA, SCSI disks on x86 hosts, and "disk" parameter may be empty for unsupported disk types. Signed-off-by: Tomoki Sekiyama <tomoki.sekiyama@hds.com> *updated schema to report 2.2 as initial supported version Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2014-07-01 01:51:34 +04:00
# @bus: bus id
#
qga: Add guest-get-fsinfo command Add command to get mounted filesystems information in the guest. The returned value contains a list of mountpoint paths and corresponding disks info such as disk bus type, drive address, and the disk controllers' PCI addresses, so that management layer such as libvirt can resolve the disk backends. For example, when `lsblk' result is: NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sdb 8:16 0 1G 0 disk `-sdb1 8:17 0 1024M 0 part `-vg0-lv0 253:1 0 1.4G 0 lvm /mnt/test sdc 8:32 0 1G 0 disk `-sdc1 8:33 0 512M 0 part `-vg0-lv0 253:1 0 1.4G 0 lvm /mnt/test vda 252:0 0 25G 0 disk `-vda1 252:1 0 25G 0 part / where sdb is a SCSI disk with PCI controller 0000:00:0a.0 and ID=1, sdc is an IDE disk with PCI controller 0000:00:01.1, and vda is a virtio-blk disk with PCI device 0000:00:06.0, guest-get-fsinfo command will return the following result: {"return": [{"name":"dm-1", "mountpoint":"/mnt/test", "disk":[ {"bus-type":"scsi","bus":0,"unit":1,"target":0, "pci-controller":{"bus":0,"slot":10,"domain":0,"function":0}}, {"bus-type":"ide","bus":0,"unit":0,"target":0, "pci-controller":{"bus":0,"slot":1,"domain":0,"function":1}}], "type":"xfs"}, {"name":"vda1", "mountpoint":"/", "disk":[ {"bus-type":"virtio","bus":0,"unit":0,"target":0, "pci-controller":{"bus":0,"slot":6,"domain":0,"function":0}}], "type":"ext4"}]} In Linux guest, the disk information is resolved from sysfs. So far, it only supports virtio-blk, virtio-scsi, IDE, SATA, SCSI disks on x86 hosts, and "disk" parameter may be empty for unsupported disk types. Signed-off-by: Tomoki Sekiyama <tomoki.sekiyama@hds.com> *updated schema to report 2.2 as initial supported version Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2014-07-01 01:51:34 +04:00
# @target: target id
#
qga: Add guest-get-fsinfo command Add command to get mounted filesystems information in the guest. The returned value contains a list of mountpoint paths and corresponding disks info such as disk bus type, drive address, and the disk controllers' PCI addresses, so that management layer such as libvirt can resolve the disk backends. For example, when `lsblk' result is: NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sdb 8:16 0 1G 0 disk `-sdb1 8:17 0 1024M 0 part `-vg0-lv0 253:1 0 1.4G 0 lvm /mnt/test sdc 8:32 0 1G 0 disk `-sdc1 8:33 0 512M 0 part `-vg0-lv0 253:1 0 1.4G 0 lvm /mnt/test vda 252:0 0 25G 0 disk `-vda1 252:1 0 25G 0 part / where sdb is a SCSI disk with PCI controller 0000:00:0a.0 and ID=1, sdc is an IDE disk with PCI controller 0000:00:01.1, and vda is a virtio-blk disk with PCI device 0000:00:06.0, guest-get-fsinfo command will return the following result: {"return": [{"name":"dm-1", "mountpoint":"/mnt/test", "disk":[ {"bus-type":"scsi","bus":0,"unit":1,"target":0, "pci-controller":{"bus":0,"slot":10,"domain":0,"function":0}}, {"bus-type":"ide","bus":0,"unit":0,"target":0, "pci-controller":{"bus":0,"slot":1,"domain":0,"function":1}}], "type":"xfs"}, {"name":"vda1", "mountpoint":"/", "disk":[ {"bus-type":"virtio","bus":0,"unit":0,"target":0, "pci-controller":{"bus":0,"slot":6,"domain":0,"function":0}}], "type":"ext4"}]} In Linux guest, the disk information is resolved from sysfs. So far, it only supports virtio-blk, virtio-scsi, IDE, SATA, SCSI disks on x86 hosts, and "disk" parameter may be empty for unsupported disk types. Signed-off-by: Tomoki Sekiyama <tomoki.sekiyama@hds.com> *updated schema to report 2.2 as initial supported version Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2014-07-01 01:51:34 +04:00
# @unit: unit id
#
# @serial: serial number (since: 3.1)
#
# @dev: device node (POSIX) or device UNC (Windows) (since: 3.1)
#
# @ccw-address: CCW address on s390x (since: 6.0)
qga: Add guest-get-fsinfo command Add command to get mounted filesystems information in the guest. The returned value contains a list of mountpoint paths and corresponding disks info such as disk bus type, drive address, and the disk controllers' PCI addresses, so that management layer such as libvirt can resolve the disk backends. For example, when `lsblk' result is: NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sdb 8:16 0 1G 0 disk `-sdb1 8:17 0 1024M 0 part `-vg0-lv0 253:1 0 1.4G 0 lvm /mnt/test sdc 8:32 0 1G 0 disk `-sdc1 8:33 0 512M 0 part `-vg0-lv0 253:1 0 1.4G 0 lvm /mnt/test vda 252:0 0 25G 0 disk `-vda1 252:1 0 25G 0 part / where sdb is a SCSI disk with PCI controller 0000:00:0a.0 and ID=1, sdc is an IDE disk with PCI controller 0000:00:01.1, and vda is a virtio-blk disk with PCI device 0000:00:06.0, guest-get-fsinfo command will return the following result: {"return": [{"name":"dm-1", "mountpoint":"/mnt/test", "disk":[ {"bus-type":"scsi","bus":0,"unit":1,"target":0, "pci-controller":{"bus":0,"slot":10,"domain":0,"function":0}}, {"bus-type":"ide","bus":0,"unit":0,"target":0, "pci-controller":{"bus":0,"slot":1,"domain":0,"function":1}}], "type":"xfs"}, {"name":"vda1", "mountpoint":"/", "disk":[ {"bus-type":"virtio","bus":0,"unit":0,"target":0, "pci-controller":{"bus":0,"slot":6,"domain":0,"function":0}}], "type":"ext4"}]} In Linux guest, the disk information is resolved from sysfs. So far, it only supports virtio-blk, virtio-scsi, IDE, SATA, SCSI disks on x86 hosts, and "disk" parameter may be empty for unsupported disk types. Signed-off-by: Tomoki Sekiyama <tomoki.sekiyama@hds.com> *updated schema to report 2.2 as initial supported version Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2014-07-01 01:51:34 +04:00
#
# Since: 2.2
##
{ 'struct': 'GuestDiskAddress',
qga: Add guest-get-fsinfo command Add command to get mounted filesystems information in the guest. The returned value contains a list of mountpoint paths and corresponding disks info such as disk bus type, drive address, and the disk controllers' PCI addresses, so that management layer such as libvirt can resolve the disk backends. For example, when `lsblk' result is: NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sdb 8:16 0 1G 0 disk `-sdb1 8:17 0 1024M 0 part `-vg0-lv0 253:1 0 1.4G 0 lvm /mnt/test sdc 8:32 0 1G 0 disk `-sdc1 8:33 0 512M 0 part `-vg0-lv0 253:1 0 1.4G 0 lvm /mnt/test vda 252:0 0 25G 0 disk `-vda1 252:1 0 25G 0 part / where sdb is a SCSI disk with PCI controller 0000:00:0a.0 and ID=1, sdc is an IDE disk with PCI controller 0000:00:01.1, and vda is a virtio-blk disk with PCI device 0000:00:06.0, guest-get-fsinfo command will return the following result: {"return": [{"name":"dm-1", "mountpoint":"/mnt/test", "disk":[ {"bus-type":"scsi","bus":0,"unit":1,"target":0, "pci-controller":{"bus":0,"slot":10,"domain":0,"function":0}}, {"bus-type":"ide","bus":0,"unit":0,"target":0, "pci-controller":{"bus":0,"slot":1,"domain":0,"function":1}}], "type":"xfs"}, {"name":"vda1", "mountpoint":"/", "disk":[ {"bus-type":"virtio","bus":0,"unit":0,"target":0, "pci-controller":{"bus":0,"slot":6,"domain":0,"function":0}}], "type":"ext4"}]} In Linux guest, the disk information is resolved from sysfs. So far, it only supports virtio-blk, virtio-scsi, IDE, SATA, SCSI disks on x86 hosts, and "disk" parameter may be empty for unsupported disk types. Signed-off-by: Tomoki Sekiyama <tomoki.sekiyama@hds.com> *updated schema to report 2.2 as initial supported version Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2014-07-01 01:51:34 +04:00
'data': {'pci-controller': 'GuestPCIAddress',
'bus-type': 'GuestDiskBusType',
'bus': 'int', 'target': 'int', 'unit': 'int',
'*serial': 'str', '*dev': 'str',
'*ccw-address': 'GuestCCWAddress'} }
qga: Add guest-get-fsinfo command Add command to get mounted filesystems information in the guest. The returned value contains a list of mountpoint paths and corresponding disks info such as disk bus type, drive address, and the disk controllers' PCI addresses, so that management layer such as libvirt can resolve the disk backends. For example, when `lsblk' result is: NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sdb 8:16 0 1G 0 disk `-sdb1 8:17 0 1024M 0 part `-vg0-lv0 253:1 0 1.4G 0 lvm /mnt/test sdc 8:32 0 1G 0 disk `-sdc1 8:33 0 512M 0 part `-vg0-lv0 253:1 0 1.4G 0 lvm /mnt/test vda 252:0 0 25G 0 disk `-vda1 252:1 0 25G 0 part / where sdb is a SCSI disk with PCI controller 0000:00:0a.0 and ID=1, sdc is an IDE disk with PCI controller 0000:00:01.1, and vda is a virtio-blk disk with PCI device 0000:00:06.0, guest-get-fsinfo command will return the following result: {"return": [{"name":"dm-1", "mountpoint":"/mnt/test", "disk":[ {"bus-type":"scsi","bus":0,"unit":1,"target":0, "pci-controller":{"bus":0,"slot":10,"domain":0,"function":0}}, {"bus-type":"ide","bus":0,"unit":0,"target":0, "pci-controller":{"bus":0,"slot":1,"domain":0,"function":1}}], "type":"xfs"}, {"name":"vda1", "mountpoint":"/", "disk":[ {"bus-type":"virtio","bus":0,"unit":0,"target":0, "pci-controller":{"bus":0,"slot":6,"domain":0,"function":0}}], "type":"ext4"}]} In Linux guest, the disk information is resolved from sysfs. So far, it only supports virtio-blk, virtio-scsi, IDE, SATA, SCSI disks on x86 hosts, and "disk" parameter may be empty for unsupported disk types. Signed-off-by: Tomoki Sekiyama <tomoki.sekiyama@hds.com> *updated schema to report 2.2 as initial supported version Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2014-07-01 01:51:34 +04:00
##
# @GuestNVMeSmart:
#
# NVMe smart information, based on NVMe specification, section
# <SMART / Health Information (Log Identifier 02h)>
#
# TODO: document members briefly
#
# Since: 7.1
##
{ 'struct': 'GuestNVMeSmart',
'data': {'critical-warning': 'int',
'temperature': 'int',
'available-spare': 'int',
'available-spare-threshold': 'int',
'percentage-used': 'int',
'data-units-read-lo': 'uint64',
'data-units-read-hi': 'uint64',
'data-units-written-lo': 'uint64',
'data-units-written-hi': 'uint64',
'host-read-commands-lo': 'uint64',
'host-read-commands-hi': 'uint64',
'host-write-commands-lo': 'uint64',
'host-write-commands-hi': 'uint64',
'controller-busy-time-lo': 'uint64',
'controller-busy-time-hi': 'uint64',
'power-cycles-lo': 'uint64',
'power-cycles-hi': 'uint64',
'power-on-hours-lo': 'uint64',
'power-on-hours-hi': 'uint64',
'unsafe-shutdowns-lo': 'uint64',
'unsafe-shutdowns-hi': 'uint64',
'media-errors-lo': 'uint64',
'media-errors-hi': 'uint64',
'number-of-error-log-entries-lo': 'uint64',
'number-of-error-log-entries-hi': 'uint64' } }
##
# @GuestDiskSmart:
#
# Disk type related smart information.
#
# @type: disk bus type
#
# Since: 7.1
##
{ 'union': 'GuestDiskSmart',
'base': { 'type': 'GuestDiskBusType' },
'discriminator': 'type',
'data': { 'nvme': 'GuestNVMeSmart' } }
##
# @GuestDiskInfo:
#
# @name: device node (Linux) or device UNC (Windows)
#
# @partition: whether this is a partition or disk
#
# @dependencies: list of device dependencies; e.g. for LVs of the LVM
# this will hold the list of PVs, for LUKS encrypted volume this
# will contain the disk where the volume is placed. (Linux)
#
# @address: disk address information (only for non-virtual devices)
#
# @alias: optional alias assigned to the disk, on Linux this is a name
# assigned by device mapper
#
# @smart: disk smart information (Since 7.1)
#
# Since: 5.2
##
{ 'struct': 'GuestDiskInfo',
'data': {'name': 'str', 'partition': 'bool', '*dependencies': ['str'],
'*address': 'GuestDiskAddress', '*alias': 'str',
'*smart': 'GuestDiskSmart'} }
##
# @guest-get-disks:
#
# Returns: The list of disks in the guest. For Windows these are only
# the physical disks. On Linux these are all root block devices
# of non-zero size including e.g. removable devices, loop devices,
# NBD, etc.
#
# Since: 5.2
##
{ 'command': 'guest-get-disks',
'returns': ['GuestDiskInfo'] }
qga: Add guest-get-fsinfo command Add command to get mounted filesystems information in the guest. The returned value contains a list of mountpoint paths and corresponding disks info such as disk bus type, drive address, and the disk controllers' PCI addresses, so that management layer such as libvirt can resolve the disk backends. For example, when `lsblk' result is: NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sdb 8:16 0 1G 0 disk `-sdb1 8:17 0 1024M 0 part `-vg0-lv0 253:1 0 1.4G 0 lvm /mnt/test sdc 8:32 0 1G 0 disk `-sdc1 8:33 0 512M 0 part `-vg0-lv0 253:1 0 1.4G 0 lvm /mnt/test vda 252:0 0 25G 0 disk `-vda1 252:1 0 25G 0 part / where sdb is a SCSI disk with PCI controller 0000:00:0a.0 and ID=1, sdc is an IDE disk with PCI controller 0000:00:01.1, and vda is a virtio-blk disk with PCI device 0000:00:06.0, guest-get-fsinfo command will return the following result: {"return": [{"name":"dm-1", "mountpoint":"/mnt/test", "disk":[ {"bus-type":"scsi","bus":0,"unit":1,"target":0, "pci-controller":{"bus":0,"slot":10,"domain":0,"function":0}}, {"bus-type":"ide","bus":0,"unit":0,"target":0, "pci-controller":{"bus":0,"slot":1,"domain":0,"function":1}}], "type":"xfs"}, {"name":"vda1", "mountpoint":"/", "disk":[ {"bus-type":"virtio","bus":0,"unit":0,"target":0, "pci-controller":{"bus":0,"slot":6,"domain":0,"function":0}}], "type":"ext4"}]} In Linux guest, the disk information is resolved from sysfs. So far, it only supports virtio-blk, virtio-scsi, IDE, SATA, SCSI disks on x86 hosts, and "disk" parameter may be empty for unsupported disk types. Signed-off-by: Tomoki Sekiyama <tomoki.sekiyama@hds.com> *updated schema to report 2.2 as initial supported version Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2014-07-01 01:51:34 +04:00
##
# @GuestFilesystemInfo:
qga: Add guest-get-fsinfo command Add command to get mounted filesystems information in the guest. The returned value contains a list of mountpoint paths and corresponding disks info such as disk bus type, drive address, and the disk controllers' PCI addresses, so that management layer such as libvirt can resolve the disk backends. For example, when `lsblk' result is: NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sdb 8:16 0 1G 0 disk `-sdb1 8:17 0 1024M 0 part `-vg0-lv0 253:1 0 1.4G 0 lvm /mnt/test sdc 8:32 0 1G 0 disk `-sdc1 8:33 0 512M 0 part `-vg0-lv0 253:1 0 1.4G 0 lvm /mnt/test vda 252:0 0 25G 0 disk `-vda1 252:1 0 25G 0 part / where sdb is a SCSI disk with PCI controller 0000:00:0a.0 and ID=1, sdc is an IDE disk with PCI controller 0000:00:01.1, and vda is a virtio-blk disk with PCI device 0000:00:06.0, guest-get-fsinfo command will return the following result: {"return": [{"name":"dm-1", "mountpoint":"/mnt/test", "disk":[ {"bus-type":"scsi","bus":0,"unit":1,"target":0, "pci-controller":{"bus":0,"slot":10,"domain":0,"function":0}}, {"bus-type":"ide","bus":0,"unit":0,"target":0, "pci-controller":{"bus":0,"slot":1,"domain":0,"function":1}}], "type":"xfs"}, {"name":"vda1", "mountpoint":"/", "disk":[ {"bus-type":"virtio","bus":0,"unit":0,"target":0, "pci-controller":{"bus":0,"slot":6,"domain":0,"function":0}}], "type":"ext4"}]} In Linux guest, the disk information is resolved from sysfs. So far, it only supports virtio-blk, virtio-scsi, IDE, SATA, SCSI disks on x86 hosts, and "disk" parameter may be empty for unsupported disk types. Signed-off-by: Tomoki Sekiyama <tomoki.sekiyama@hds.com> *updated schema to report 2.2 as initial supported version Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2014-07-01 01:51:34 +04:00
#
# @name: disk name
#
qga: Add guest-get-fsinfo command Add command to get mounted filesystems information in the guest. The returned value contains a list of mountpoint paths and corresponding disks info such as disk bus type, drive address, and the disk controllers' PCI addresses, so that management layer such as libvirt can resolve the disk backends. For example, when `lsblk' result is: NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sdb 8:16 0 1G 0 disk `-sdb1 8:17 0 1024M 0 part `-vg0-lv0 253:1 0 1.4G 0 lvm /mnt/test sdc 8:32 0 1G 0 disk `-sdc1 8:33 0 512M 0 part `-vg0-lv0 253:1 0 1.4G 0 lvm /mnt/test vda 252:0 0 25G 0 disk `-vda1 252:1 0 25G 0 part / where sdb is a SCSI disk with PCI controller 0000:00:0a.0 and ID=1, sdc is an IDE disk with PCI controller 0000:00:01.1, and vda is a virtio-blk disk with PCI device 0000:00:06.0, guest-get-fsinfo command will return the following result: {"return": [{"name":"dm-1", "mountpoint":"/mnt/test", "disk":[ {"bus-type":"scsi","bus":0,"unit":1,"target":0, "pci-controller":{"bus":0,"slot":10,"domain":0,"function":0}}, {"bus-type":"ide","bus":0,"unit":0,"target":0, "pci-controller":{"bus":0,"slot":1,"domain":0,"function":1}}], "type":"xfs"}, {"name":"vda1", "mountpoint":"/", "disk":[ {"bus-type":"virtio","bus":0,"unit":0,"target":0, "pci-controller":{"bus":0,"slot":6,"domain":0,"function":0}}], "type":"ext4"}]} In Linux guest, the disk information is resolved from sysfs. So far, it only supports virtio-blk, virtio-scsi, IDE, SATA, SCSI disks on x86 hosts, and "disk" parameter may be empty for unsupported disk types. Signed-off-by: Tomoki Sekiyama <tomoki.sekiyama@hds.com> *updated schema to report 2.2 as initial supported version Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2014-07-01 01:51:34 +04:00
# @mountpoint: mount point path
#
qga: Add guest-get-fsinfo command Add command to get mounted filesystems information in the guest. The returned value contains a list of mountpoint paths and corresponding disks info such as disk bus type, drive address, and the disk controllers' PCI addresses, so that management layer such as libvirt can resolve the disk backends. For example, when `lsblk' result is: NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sdb 8:16 0 1G 0 disk `-sdb1 8:17 0 1024M 0 part `-vg0-lv0 253:1 0 1.4G 0 lvm /mnt/test sdc 8:32 0 1G 0 disk `-sdc1 8:33 0 512M 0 part `-vg0-lv0 253:1 0 1.4G 0 lvm /mnt/test vda 252:0 0 25G 0 disk `-vda1 252:1 0 25G 0 part / where sdb is a SCSI disk with PCI controller 0000:00:0a.0 and ID=1, sdc is an IDE disk with PCI controller 0000:00:01.1, and vda is a virtio-blk disk with PCI device 0000:00:06.0, guest-get-fsinfo command will return the following result: {"return": [{"name":"dm-1", "mountpoint":"/mnt/test", "disk":[ {"bus-type":"scsi","bus":0,"unit":1,"target":0, "pci-controller":{"bus":0,"slot":10,"domain":0,"function":0}}, {"bus-type":"ide","bus":0,"unit":0,"target":0, "pci-controller":{"bus":0,"slot":1,"domain":0,"function":1}}], "type":"xfs"}, {"name":"vda1", "mountpoint":"/", "disk":[ {"bus-type":"virtio","bus":0,"unit":0,"target":0, "pci-controller":{"bus":0,"slot":6,"domain":0,"function":0}}], "type":"ext4"}]} In Linux guest, the disk information is resolved from sysfs. So far, it only supports virtio-blk, virtio-scsi, IDE, SATA, SCSI disks on x86 hosts, and "disk" parameter may be empty for unsupported disk types. Signed-off-by: Tomoki Sekiyama <tomoki.sekiyama@hds.com> *updated schema to report 2.2 as initial supported version Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2014-07-01 01:51:34 +04:00
# @type: file system type string
#
# @used-bytes: file system used bytes (since 3.0)
#
# @total-bytes: filesystem capacity in bytes for unprivileged users (since 3.0)
#
# @total-bytes-privileged: filesystem capacity in bytes for privileged users
# (since 9.1)
#
# @disk: an array of disk hardware information that the volume lies
# on, which may be empty if the disk type is not supported
qga: Add guest-get-fsinfo command Add command to get mounted filesystems information in the guest. The returned value contains a list of mountpoint paths and corresponding disks info such as disk bus type, drive address, and the disk controllers' PCI addresses, so that management layer such as libvirt can resolve the disk backends. For example, when `lsblk' result is: NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sdb 8:16 0 1G 0 disk `-sdb1 8:17 0 1024M 0 part `-vg0-lv0 253:1 0 1.4G 0 lvm /mnt/test sdc 8:32 0 1G 0 disk `-sdc1 8:33 0 512M 0 part `-vg0-lv0 253:1 0 1.4G 0 lvm /mnt/test vda 252:0 0 25G 0 disk `-vda1 252:1 0 25G 0 part / where sdb is a SCSI disk with PCI controller 0000:00:0a.0 and ID=1, sdc is an IDE disk with PCI controller 0000:00:01.1, and vda is a virtio-blk disk with PCI device 0000:00:06.0, guest-get-fsinfo command will return the following result: {"return": [{"name":"dm-1", "mountpoint":"/mnt/test", "disk":[ {"bus-type":"scsi","bus":0,"unit":1,"target":0, "pci-controller":{"bus":0,"slot":10,"domain":0,"function":0}}, {"bus-type":"ide","bus":0,"unit":0,"target":0, "pci-controller":{"bus":0,"slot":1,"domain":0,"function":1}}], "type":"xfs"}, {"name":"vda1", "mountpoint":"/", "disk":[ {"bus-type":"virtio","bus":0,"unit":0,"target":0, "pci-controller":{"bus":0,"slot":6,"domain":0,"function":0}}], "type":"ext4"}]} In Linux guest, the disk information is resolved from sysfs. So far, it only supports virtio-blk, virtio-scsi, IDE, SATA, SCSI disks on x86 hosts, and "disk" parameter may be empty for unsupported disk types. Signed-off-by: Tomoki Sekiyama <tomoki.sekiyama@hds.com> *updated schema to report 2.2 as initial supported version Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2014-07-01 01:51:34 +04:00
#
# Since: 2.2
##
{ 'struct': 'GuestFilesystemInfo',
qga: Add guest-get-fsinfo command Add command to get mounted filesystems information in the guest. The returned value contains a list of mountpoint paths and corresponding disks info such as disk bus type, drive address, and the disk controllers' PCI addresses, so that management layer such as libvirt can resolve the disk backends. For example, when `lsblk' result is: NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sdb 8:16 0 1G 0 disk `-sdb1 8:17 0 1024M 0 part `-vg0-lv0 253:1 0 1.4G 0 lvm /mnt/test sdc 8:32 0 1G 0 disk `-sdc1 8:33 0 512M 0 part `-vg0-lv0 253:1 0 1.4G 0 lvm /mnt/test vda 252:0 0 25G 0 disk `-vda1 252:1 0 25G 0 part / where sdb is a SCSI disk with PCI controller 0000:00:0a.0 and ID=1, sdc is an IDE disk with PCI controller 0000:00:01.1, and vda is a virtio-blk disk with PCI device 0000:00:06.0, guest-get-fsinfo command will return the following result: {"return": [{"name":"dm-1", "mountpoint":"/mnt/test", "disk":[ {"bus-type":"scsi","bus":0,"unit":1,"target":0, "pci-controller":{"bus":0,"slot":10,"domain":0,"function":0}}, {"bus-type":"ide","bus":0,"unit":0,"target":0, "pci-controller":{"bus":0,"slot":1,"domain":0,"function":1}}], "type":"xfs"}, {"name":"vda1", "mountpoint":"/", "disk":[ {"bus-type":"virtio","bus":0,"unit":0,"target":0, "pci-controller":{"bus":0,"slot":6,"domain":0,"function":0}}], "type":"ext4"}]} In Linux guest, the disk information is resolved from sysfs. So far, it only supports virtio-blk, virtio-scsi, IDE, SATA, SCSI disks on x86 hosts, and "disk" parameter may be empty for unsupported disk types. Signed-off-by: Tomoki Sekiyama <tomoki.sekiyama@hds.com> *updated schema to report 2.2 as initial supported version Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2014-07-01 01:51:34 +04:00
'data': {'name': 'str', 'mountpoint': 'str', 'type': 'str',
'*used-bytes': 'uint64', '*total-bytes': 'uint64',
'*total-bytes-privileged': 'uint64', 'disk': ['GuestDiskAddress']} }
qga: Add guest-get-fsinfo command Add command to get mounted filesystems information in the guest. The returned value contains a list of mountpoint paths and corresponding disks info such as disk bus type, drive address, and the disk controllers' PCI addresses, so that management layer such as libvirt can resolve the disk backends. For example, when `lsblk' result is: NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sdb 8:16 0 1G 0 disk `-sdb1 8:17 0 1024M 0 part `-vg0-lv0 253:1 0 1.4G 0 lvm /mnt/test sdc 8:32 0 1G 0 disk `-sdc1 8:33 0 512M 0 part `-vg0-lv0 253:1 0 1.4G 0 lvm /mnt/test vda 252:0 0 25G 0 disk `-vda1 252:1 0 25G 0 part / where sdb is a SCSI disk with PCI controller 0000:00:0a.0 and ID=1, sdc is an IDE disk with PCI controller 0000:00:01.1, and vda is a virtio-blk disk with PCI device 0000:00:06.0, guest-get-fsinfo command will return the following result: {"return": [{"name":"dm-1", "mountpoint":"/mnt/test", "disk":[ {"bus-type":"scsi","bus":0,"unit":1,"target":0, "pci-controller":{"bus":0,"slot":10,"domain":0,"function":0}}, {"bus-type":"ide","bus":0,"unit":0,"target":0, "pci-controller":{"bus":0,"slot":1,"domain":0,"function":1}}], "type":"xfs"}, {"name":"vda1", "mountpoint":"/", "disk":[ {"bus-type":"virtio","bus":0,"unit":0,"target":0, "pci-controller":{"bus":0,"slot":6,"domain":0,"function":0}}], "type":"ext4"}]} In Linux guest, the disk information is resolved from sysfs. So far, it only supports virtio-blk, virtio-scsi, IDE, SATA, SCSI disks on x86 hosts, and "disk" parameter may be empty for unsupported disk types. Signed-off-by: Tomoki Sekiyama <tomoki.sekiyama@hds.com> *updated schema to report 2.2 as initial supported version Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2014-07-01 01:51:34 +04:00
##
# @guest-get-fsinfo:
#
# Returns: The list of filesystems information mounted in the guest.
# The returned mountpoints may be specified to
# @guest-fsfreeze-freeze-list. Network filesystems (such as CIFS
# and NFS) are not listed.
qga: Add guest-get-fsinfo command Add command to get mounted filesystems information in the guest. The returned value contains a list of mountpoint paths and corresponding disks info such as disk bus type, drive address, and the disk controllers' PCI addresses, so that management layer such as libvirt can resolve the disk backends. For example, when `lsblk' result is: NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sdb 8:16 0 1G 0 disk `-sdb1 8:17 0 1024M 0 part `-vg0-lv0 253:1 0 1.4G 0 lvm /mnt/test sdc 8:32 0 1G 0 disk `-sdc1 8:33 0 512M 0 part `-vg0-lv0 253:1 0 1.4G 0 lvm /mnt/test vda 252:0 0 25G 0 disk `-vda1 252:1 0 25G 0 part / where sdb is a SCSI disk with PCI controller 0000:00:0a.0 and ID=1, sdc is an IDE disk with PCI controller 0000:00:01.1, and vda is a virtio-blk disk with PCI device 0000:00:06.0, guest-get-fsinfo command will return the following result: {"return": [{"name":"dm-1", "mountpoint":"/mnt/test", "disk":[ {"bus-type":"scsi","bus":0,"unit":1,"target":0, "pci-controller":{"bus":0,"slot":10,"domain":0,"function":0}}, {"bus-type":"ide","bus":0,"unit":0,"target":0, "pci-controller":{"bus":0,"slot":1,"domain":0,"function":1}}], "type":"xfs"}, {"name":"vda1", "mountpoint":"/", "disk":[ {"bus-type":"virtio","bus":0,"unit":0,"target":0, "pci-controller":{"bus":0,"slot":6,"domain":0,"function":0}}], "type":"ext4"}]} In Linux guest, the disk information is resolved from sysfs. So far, it only supports virtio-blk, virtio-scsi, IDE, SATA, SCSI disks on x86 hosts, and "disk" parameter may be empty for unsupported disk types. Signed-off-by: Tomoki Sekiyama <tomoki.sekiyama@hds.com> *updated schema to report 2.2 as initial supported version Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2014-07-01 01:51:34 +04:00
#
# Since: 2.2
##
{ 'command': 'guest-get-fsinfo',
'returns': ['GuestFilesystemInfo'] }
qga: add guest-set-user-password command Add a new 'guest-set-user-password' command for changing the password of guest OS user accounts. This command is needed to enable OpenStack to support its API for changing the admin password of guests running on KVM/QEMU. It is not practical to provide a command at the QEMU level explicitly targetting administrator account password change only, since different guest OS have different names for the admin account. While UNIX systems use 'root', Windows systems typically use 'Administrator' and even that can be renamed. Higher level apps like OpenStack have the ability to figure out the correct admin account name since they have info that QEMU/libvirt do not. The command accepts either the clear text password string, encoded in base64 to make it 8-bit safe in JSON: $ echo -n "123456" | base64 MTIzNDU2 $ virsh -c qemu:///system qemu-agent-command f21x86_64 \ '{ "execute": "guest-set-user-password", "arguments": { "crypted": false, "username": "root", "password": "MTIzNDU2" } }' {"return":{}} Or a password that has already been run though a crypt(3) like algorithm appropriate for the guest, again then base64 encoded: $ echo -n '$6$n01A2Tau$e...snip...DfMOP7of9AJ1I8q0' | base64 JDYkb...snip...YT2Ey $ virsh -c qemu:///system qemu-agent-command f21x86_64 \ '{ "execute": "guest-set-user-password", "arguments": { "crypted": true, "username": "root", "password": "JDYkb...snip...YT2Ey" } }' NB windows support is desirable, but not implemented in this patch. Signed-off-by: Daniel P. Berrange <berrange@redhat.com> Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2015-02-11 14:26:12 +03:00
##
# @guest-set-user-password:
qga: add guest-set-user-password command Add a new 'guest-set-user-password' command for changing the password of guest OS user accounts. This command is needed to enable OpenStack to support its API for changing the admin password of guests running on KVM/QEMU. It is not practical to provide a command at the QEMU level explicitly targetting administrator account password change only, since different guest OS have different names for the admin account. While UNIX systems use 'root', Windows systems typically use 'Administrator' and even that can be renamed. Higher level apps like OpenStack have the ability to figure out the correct admin account name since they have info that QEMU/libvirt do not. The command accepts either the clear text password string, encoded in base64 to make it 8-bit safe in JSON: $ echo -n "123456" | base64 MTIzNDU2 $ virsh -c qemu:///system qemu-agent-command f21x86_64 \ '{ "execute": "guest-set-user-password", "arguments": { "crypted": false, "username": "root", "password": "MTIzNDU2" } }' {"return":{}} Or a password that has already been run though a crypt(3) like algorithm appropriate for the guest, again then base64 encoded: $ echo -n '$6$n01A2Tau$e...snip...DfMOP7of9AJ1I8q0' | base64 JDYkb...snip...YT2Ey $ virsh -c qemu:///system qemu-agent-command f21x86_64 \ '{ "execute": "guest-set-user-password", "arguments": { "crypted": true, "username": "root", "password": "JDYkb...snip...YT2Ey" } }' NB windows support is desirable, but not implemented in this patch. Signed-off-by: Daniel P. Berrange <berrange@redhat.com> Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2015-02-11 14:26:12 +03:00
#
# @username: the user account whose password to change
#
qga: add guest-set-user-password command Add a new 'guest-set-user-password' command for changing the password of guest OS user accounts. This command is needed to enable OpenStack to support its API for changing the admin password of guests running on KVM/QEMU. It is not practical to provide a command at the QEMU level explicitly targetting administrator account password change only, since different guest OS have different names for the admin account. While UNIX systems use 'root', Windows systems typically use 'Administrator' and even that can be renamed. Higher level apps like OpenStack have the ability to figure out the correct admin account name since they have info that QEMU/libvirt do not. The command accepts either the clear text password string, encoded in base64 to make it 8-bit safe in JSON: $ echo -n "123456" | base64 MTIzNDU2 $ virsh -c qemu:///system qemu-agent-command f21x86_64 \ '{ "execute": "guest-set-user-password", "arguments": { "crypted": false, "username": "root", "password": "MTIzNDU2" } }' {"return":{}} Or a password that has already been run though a crypt(3) like algorithm appropriate for the guest, again then base64 encoded: $ echo -n '$6$n01A2Tau$e...snip...DfMOP7of9AJ1I8q0' | base64 JDYkb...snip...YT2Ey $ virsh -c qemu:///system qemu-agent-command f21x86_64 \ '{ "execute": "guest-set-user-password", "arguments": { "crypted": true, "username": "root", "password": "JDYkb...snip...YT2Ey" } }' NB windows support is desirable, but not implemented in this patch. Signed-off-by: Daniel P. Berrange <berrange@redhat.com> Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2015-02-11 14:26:12 +03:00
# @password: the new password entry string, base64 encoded
#
qga: add guest-set-user-password command Add a new 'guest-set-user-password' command for changing the password of guest OS user accounts. This command is needed to enable OpenStack to support its API for changing the admin password of guests running on KVM/QEMU. It is not practical to provide a command at the QEMU level explicitly targetting administrator account password change only, since different guest OS have different names for the admin account. While UNIX systems use 'root', Windows systems typically use 'Administrator' and even that can be renamed. Higher level apps like OpenStack have the ability to figure out the correct admin account name since they have info that QEMU/libvirt do not. The command accepts either the clear text password string, encoded in base64 to make it 8-bit safe in JSON: $ echo -n "123456" | base64 MTIzNDU2 $ virsh -c qemu:///system qemu-agent-command f21x86_64 \ '{ "execute": "guest-set-user-password", "arguments": { "crypted": false, "username": "root", "password": "MTIzNDU2" } }' {"return":{}} Or a password that has already been run though a crypt(3) like algorithm appropriate for the guest, again then base64 encoded: $ echo -n '$6$n01A2Tau$e...snip...DfMOP7of9AJ1I8q0' | base64 JDYkb...snip...YT2Ey $ virsh -c qemu:///system qemu-agent-command f21x86_64 \ '{ "execute": "guest-set-user-password", "arguments": { "crypted": true, "username": "root", "password": "JDYkb...snip...YT2Ey" } }' NB windows support is desirable, but not implemented in this patch. Signed-off-by: Daniel P. Berrange <berrange@redhat.com> Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2015-02-11 14:26:12 +03:00
# @crypted: true if password is already crypt()d, false if raw
#
# If the @crypted flag is true, it is the caller's responsibility to
# ensure the correct crypt() encryption scheme is used. This command
# does not attempt to interpret or report on the encryption scheme.
# Refer to the documentation of the guest operating system in question
# to determine what is supported.
qga: add guest-set-user-password command Add a new 'guest-set-user-password' command for changing the password of guest OS user accounts. This command is needed to enable OpenStack to support its API for changing the admin password of guests running on KVM/QEMU. It is not practical to provide a command at the QEMU level explicitly targetting administrator account password change only, since different guest OS have different names for the admin account. While UNIX systems use 'root', Windows systems typically use 'Administrator' and even that can be renamed. Higher level apps like OpenStack have the ability to figure out the correct admin account name since they have info that QEMU/libvirt do not. The command accepts either the clear text password string, encoded in base64 to make it 8-bit safe in JSON: $ echo -n "123456" | base64 MTIzNDU2 $ virsh -c qemu:///system qemu-agent-command f21x86_64 \ '{ "execute": "guest-set-user-password", "arguments": { "crypted": false, "username": "root", "password": "MTIzNDU2" } }' {"return":{}} Or a password that has already been run though a crypt(3) like algorithm appropriate for the guest, again then base64 encoded: $ echo -n '$6$n01A2Tau$e...snip...DfMOP7of9AJ1I8q0' | base64 JDYkb...snip...YT2Ey $ virsh -c qemu:///system qemu-agent-command f21x86_64 \ '{ "execute": "guest-set-user-password", "arguments": { "crypted": true, "username": "root", "password": "JDYkb...snip...YT2Ey" } }' NB windows support is desirable, but not implemented in this patch. Signed-off-by: Daniel P. Berrange <berrange@redhat.com> Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2015-02-11 14:26:12 +03:00
#
# Not all guest operating systems will support use of the @crypted
# flag, as they may require the clear-text password
qga: add guest-set-user-password command Add a new 'guest-set-user-password' command for changing the password of guest OS user accounts. This command is needed to enable OpenStack to support its API for changing the admin password of guests running on KVM/QEMU. It is not practical to provide a command at the QEMU level explicitly targetting administrator account password change only, since different guest OS have different names for the admin account. While UNIX systems use 'root', Windows systems typically use 'Administrator' and even that can be renamed. Higher level apps like OpenStack have the ability to figure out the correct admin account name since they have info that QEMU/libvirt do not. The command accepts either the clear text password string, encoded in base64 to make it 8-bit safe in JSON: $ echo -n "123456" | base64 MTIzNDU2 $ virsh -c qemu:///system qemu-agent-command f21x86_64 \ '{ "execute": "guest-set-user-password", "arguments": { "crypted": false, "username": "root", "password": "MTIzNDU2" } }' {"return":{}} Or a password that has already been run though a crypt(3) like algorithm appropriate for the guest, again then base64 encoded: $ echo -n '$6$n01A2Tau$e...snip...DfMOP7of9AJ1I8q0' | base64 JDYkb...snip...YT2Ey $ virsh -c qemu:///system qemu-agent-command f21x86_64 \ '{ "execute": "guest-set-user-password", "arguments": { "crypted": true, "username": "root", "password": "JDYkb...snip...YT2Ey" } }' NB windows support is desirable, but not implemented in this patch. Signed-off-by: Daniel P. Berrange <berrange@redhat.com> Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2015-02-11 14:26:12 +03:00
#
# The @password parameter must always be base64 encoded before
# transmission, even if already crypt()d, to ensure it is 8-bit safe
# when passed as JSON.
qga: add guest-set-user-password command Add a new 'guest-set-user-password' command for changing the password of guest OS user accounts. This command is needed to enable OpenStack to support its API for changing the admin password of guests running on KVM/QEMU. It is not practical to provide a command at the QEMU level explicitly targetting administrator account password change only, since different guest OS have different names for the admin account. While UNIX systems use 'root', Windows systems typically use 'Administrator' and even that can be renamed. Higher level apps like OpenStack have the ability to figure out the correct admin account name since they have info that QEMU/libvirt do not. The command accepts either the clear text password string, encoded in base64 to make it 8-bit safe in JSON: $ echo -n "123456" | base64 MTIzNDU2 $ virsh -c qemu:///system qemu-agent-command f21x86_64 \ '{ "execute": "guest-set-user-password", "arguments": { "crypted": false, "username": "root", "password": "MTIzNDU2" } }' {"return":{}} Or a password that has already been run though a crypt(3) like algorithm appropriate for the guest, again then base64 encoded: $ echo -n '$6$n01A2Tau$e...snip...DfMOP7of9AJ1I8q0' | base64 JDYkb...snip...YT2Ey $ virsh -c qemu:///system qemu-agent-command f21x86_64 \ '{ "execute": "guest-set-user-password", "arguments": { "crypted": true, "username": "root", "password": "JDYkb...snip...YT2Ey" } }' NB windows support is desirable, but not implemented in this patch. Signed-off-by: Daniel P. Berrange <berrange@redhat.com> Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2015-02-11 14:26:12 +03:00
#
# Since: 2.3
qga: add guest-set-user-password command Add a new 'guest-set-user-password' command for changing the password of guest OS user accounts. This command is needed to enable OpenStack to support its API for changing the admin password of guests running on KVM/QEMU. It is not practical to provide a command at the QEMU level explicitly targetting administrator account password change only, since different guest OS have different names for the admin account. While UNIX systems use 'root', Windows systems typically use 'Administrator' and even that can be renamed. Higher level apps like OpenStack have the ability to figure out the correct admin account name since they have info that QEMU/libvirt do not. The command accepts either the clear text password string, encoded in base64 to make it 8-bit safe in JSON: $ echo -n "123456" | base64 MTIzNDU2 $ virsh -c qemu:///system qemu-agent-command f21x86_64 \ '{ "execute": "guest-set-user-password", "arguments": { "crypted": false, "username": "root", "password": "MTIzNDU2" } }' {"return":{}} Or a password that has already been run though a crypt(3) like algorithm appropriate for the guest, again then base64 encoded: $ echo -n '$6$n01A2Tau$e...snip...DfMOP7of9AJ1I8q0' | base64 JDYkb...snip...YT2Ey $ virsh -c qemu:///system qemu-agent-command f21x86_64 \ '{ "execute": "guest-set-user-password", "arguments": { "crypted": true, "username": "root", "password": "JDYkb...snip...YT2Ey" } }' NB windows support is desirable, but not implemented in this patch. Signed-off-by: Daniel P. Berrange <berrange@redhat.com> Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2015-02-11 14:26:12 +03:00
##
{ 'command': 'guest-set-user-password',
'data': { 'username': 'str', 'password': 'str', 'crypted': 'bool' } }
##
# @GuestMemoryBlock:
#
# @phys-index: Arbitrary guest-specific unique identifier of the
# MEMORY BLOCK.
#
# @online: Whether the MEMORY BLOCK is enabled in guest.
#
# @can-offline: Whether offlining the MEMORY BLOCK is possible. This
# member is always filled in by the guest agent when the structure
# is returned, and always ignored on input (hence it can be
# omitted then).
#
# Since: 2.3
##
{ 'struct': 'GuestMemoryBlock',
'data': {'phys-index': 'uint64',
'online': 'bool',
'*can-offline': 'bool'} }
##
# @guest-get-memory-blocks:
#
# Retrieve the list of the guest's memory blocks.
#
# This is a read-only operation.
#
# Returns: The list of all memory blocks the guest knows about. Each
# memory block is put on the list exactly once, but their order is
# unspecified.
#
# Since: 2.3
##
{ 'command': 'guest-get-memory-blocks',
'returns': ['GuestMemoryBlock'] }
##
# @GuestMemoryBlockResponseType:
#
# An enumeration of memory block operation result.
#
# @success: the operation of online/offline memory block is
# successful.
#
# @not-found: can't find the corresponding memoryXXX directory in
# sysfs.
#
# @operation-not-supported: for some old kernels, it does not support
# online or offline memory block.
#
# @operation-failed: the operation of online/offline memory block
# fails, because of some errors happen.
#
# Since: 2.3
##
{ 'enum': 'GuestMemoryBlockResponseType',
'data': ['success', 'not-found', 'operation-not-supported',
'operation-failed'] }
##
# @GuestMemoryBlockResponse:
#
# @phys-index: same with the 'phys-index' member of @GuestMemoryBlock.
#
# @response: the result of memory block operation.
#
# @error-code: the error number. When memory block operation fails,
# we assign the value of 'errno' to this member, it indicates what
# goes wrong. When the operation succeeds, it will be omitted.
#
# Since: 2.3
##
{ 'struct': 'GuestMemoryBlockResponse',
'data': { 'phys-index': 'uint64',
'response': 'GuestMemoryBlockResponseType',
'*error-code': 'int' }}
##
# @guest-set-memory-blocks:
#
# Attempt to reconfigure (currently: enable/disable) state of memory
# blocks inside the guest.
#
# @mem-blks: The memory blocks to be reconfigured. This list is
# processed node by node in order. In each node @phys-index is
# used to look up the guest MEMORY BLOCK, for which @online
# specifies the requested state. The set of distinct
# @phys-index's is only required to be a subset of the
# guest-supported identifiers. There's no restriction on list
# length or on repeating the same @phys-index (with possibly
# different @online field). Preferably the input list should
# describe a modified subset of @guest-get-memory-blocks' return
# value.
#
# Returns: The operation results, it is a list of
# @GuestMemoryBlockResponse, which is corresponding to the input
# list.
#
# Note: it will return an empty list if the @mem-blks list was
# empty on input, or there is an error, and in this case, guest
# state will not be changed.
#
# Since: 2.3
##
{ 'command': 'guest-set-memory-blocks',
'data': {'mem-blks': ['GuestMemoryBlock'] },
'returns': ['GuestMemoryBlockResponse'] }
##
# @GuestMemoryBlockInfo:
#
# @size: the size (in bytes) of the guest memory blocks, which are the
# minimal units of memory block online/offline operations (also
# called Logical Memory Hotplug).
#
# Since: 2.3
##
{ 'struct': 'GuestMemoryBlockInfo',
'data': {'size': 'uint64'} }
##
# @guest-get-memory-block-info:
#
# Get information relating to guest memory blocks.
#
# Returns: @GuestMemoryBlockInfo
#
# Since: 2.3
##
{ 'command': 'guest-get-memory-block-info',
'returns': 'GuestMemoryBlockInfo' }
##
# @GuestExecStatus:
#
# @exited: true if process has already terminated.
#
# @exitcode: process exit code if it was normally terminated.
#
# @signal: signal number (linux) or unhandled exception code (windows)
# if the process was abnormally terminated.
#
# @out-data: base64-encoded stdout of the process. This field will
# only be populated after the process exits.
#
# @err-data: base64-encoded stderr of the process. Note: @out-data
# and @err-data are present only if 'capture-output' was specified
# for 'guest-exec'. This field will only be populated after the
# process exits.
#
# @out-truncated: true if stdout was not fully captured due to size
# limitation.
#
# @err-truncated: true if stderr was not fully captured due to size
# limitation.
#
# Since: 2.5
##
{ 'struct': 'GuestExecStatus',
'data': { 'exited': 'bool', '*exitcode': 'int', '*signal': 'int',
'*out-data': 'str', '*err-data': 'str',
'*out-truncated': 'bool', '*err-truncated': 'bool' }}
##
# @guest-exec-status:
#
# Check status of process associated with PID retrieved via
# guest-exec. Reap the process and associated metadata if it has
# exited.
#
# @pid: pid returned from guest-exec
#
# Returns: GuestExecStatus
#
# Since: 2.5
##
{ 'command': 'guest-exec-status',
'data': { 'pid': 'int' },
'returns': 'GuestExecStatus' }
##
# @GuestExec:
#
# @pid: pid of child process in guest OS
#
# Since: 2.5
##
{ 'struct': 'GuestExec',
'data': { 'pid': 'int'} }
##
# @GuestExecCaptureOutputMode:
#
# An enumeration of guest-exec capture modes.
#
# @none: do not capture any output
#
# @stdout: only capture stdout
#
# @stderr: only capture stderr
#
# @separated: capture both stdout and stderr, but separated into
# GuestExecStatus out-data and err-data, respectively
#
# @merged: capture both stdout and stderr, but merge together into
# out-data. Not effective on windows guests.
#
# Since: 8.0
##
{ 'enum': 'GuestExecCaptureOutputMode',
'data': [ 'none', 'stdout', 'stderr', 'separated',
{ 'name': 'merged', 'if': { 'not': 'CONFIG_WIN32' } } ] }
##
# @GuestExecCaptureOutput:
#
# Controls what guest-exec output gets captures.
#
# @flag: captures both stdout and stderr if true. Equivalent to
# GuestExecCaptureOutputMode::all. (since 2.5)
#
# @mode: capture mode; preferred interface
#
# Since: 8.0
##
{ 'alternate': 'GuestExecCaptureOutput',
'data': { 'flag': 'bool',
'mode': 'GuestExecCaptureOutputMode'} }
##
# @guest-exec:
#
# Execute a command in the guest
#
# @path: path or executable name to execute
#
# @arg: argument list to pass to executable
#
# @env: environment variables to pass to executable
#
# @input-data: data to be passed to process stdin (base64 encoded)
#
# @capture-output: bool flag to enable capture of stdout/stderr of
# running process. Defaults to false.
#
# Returns: PID
#
# Since: 2.5
##
{ 'command': 'guest-exec',
'data': { 'path': 'str', '*arg': ['str'], '*env': ['str'],
'*input-data': 'str', '*capture-output': 'GuestExecCaptureOutput' },
'returns': 'GuestExec' }
##
# @GuestHostName:
#
# @host-name: Fully qualified domain name of the guest OS
#
# Since: 2.10
##
{ 'struct': 'GuestHostName',
'data': { 'host-name': 'str' } }
##
# @guest-get-host-name:
#
# Return a name for the machine.
#
# The returned name is not necessarily a fully-qualified domain name,
# or even present in DNS or some other name service at all. It need
# not even be unique on your local network or site, but usually it is.
#
# Returns: the host name of the machine
#
# Since: 2.10
##
{ 'command': 'guest-get-host-name',
'returns': 'GuestHostName' }
##
# @GuestUser:
#
# @user: Username
#
# @domain: Logon domain (windows only)
#
# @login-time: Time of login of this user on the computer. If
# multiple instances of the user are logged in, the earliest login
# time is reported. The value is in fractional seconds since
# epoch time.
#
# Since: 2.10
##
{ 'struct': 'GuestUser',
'data': { 'user': 'str', 'login-time': 'number', '*domain': 'str' } }
##
# @guest-get-users:
#
# Retrieves a list of currently active users on the VM.
#
# Returns: A unique list of users.
#
# Since: 2.10
##
{ 'command': 'guest-get-users',
'returns': ['GuestUser'] }
##
# @GuestTimezone:
#
# @zone: Timezone name. These values may differ depending on guest/OS
# and should only be used for informational purposes.
#
# @offset: Offset to UTC in seconds, negative numbers for time zones
# west of GMT, positive numbers for east
#
# Since: 2.10
##
{ 'struct': 'GuestTimezone',
'data': { '*zone': 'str', 'offset': 'int' } }
##
# @guest-get-timezone:
#
# Retrieves the timezone information from the guest.
#
# Returns: A GuestTimezone dictionary.
#
# Since: 2.10
##
{ 'command': 'guest-get-timezone',
'returns': 'GuestTimezone' }
##
# @GuestOSInfo:
#
# @kernel-release:
# * POSIX: release field returned by uname(2)
# * Windows: build number of the OS
#
# @kernel-version:
# * POSIX: version field returned by uname(2)
# * Windows: version number of the OS
#
# @machine:
# * POSIX: machine field returned by uname(2)
# * Windows: one of x86, x86_64, arm, ia64
#
# @id:
# * POSIX: as defined by os-release(5)
# * Windows: contains string "mswindows"
#
# @name:
# * POSIX: as defined by os-release(5)
# * Windows: contains string "Microsoft Windows"
#
# @pretty-name:
# * POSIX: as defined by os-release(5)
# * Windows: product name, e.g. "Microsoft Windows 10 Enterprise"
#
# @version:
# * POSIX: as defined by os-release(5)
# * Windows: long version string, e.g. "Microsoft Windows Server
# 2008"
#
# @version-id:
# * POSIX: as defined by os-release(5)
# * Windows: short version identifier, e.g. "7" or "20012r2"
#
# @variant:
# * POSIX: as defined by os-release(5)
# * Windows: contains string "server" or "client"
#
# @variant-id:
# * POSIX: as defined by os-release(5)
# * Windows: contains string "server" or "client"
#
# Notes: On POSIX systems the fields @id, @name, @pretty-name,
# @version, @version-id, @variant and @variant-id follow the
# definition specified in os-release(5). Refer to the manual page
# for exact description of the fields. Their values are taken
# from the os-release file. If the file is not present in the
# system, or the values are not present in the file, the fields
# are not included.
#
# On Windows the values are filled from information gathered from
# the system.
#
# Since: 2.10
##
{ 'struct': 'GuestOSInfo',
'data': {
'*kernel-release': 'str', '*kernel-version': 'str',
'*machine': 'str', '*id': 'str', '*name': 'str',
'*pretty-name': 'str', '*version': 'str', '*version-id': 'str',
'*variant': 'str', '*variant-id': 'str' } }
##
# @guest-get-osinfo:
#
# Retrieve guest operating system information
#
# Returns: @GuestOSInfo
#
# Since: 2.10
##
{ 'command': 'guest-get-osinfo',
'returns': 'GuestOSInfo' }
##
# @GuestDeviceType:
#
# @pci: PCI device
##
{ 'enum': 'GuestDeviceType',
'data': [ 'pci' ] }
##
# @GuestDeviceIdPCI:
#
# @vendor-id: vendor ID
#
# @device-id: device ID
#
# Since: 5.2
##
{ 'struct': 'GuestDeviceIdPCI',
'data': { 'vendor-id': 'uint16', 'device-id': 'uint16' } }
##
# @GuestDeviceId:
#
# Id of the device
#
# @type: device type
#
# Since: 5.2
##
{ 'union': 'GuestDeviceId',
'base': { 'type': 'GuestDeviceType' },
'discriminator': 'type',
'data': { 'pci': 'GuestDeviceIdPCI' } }
##
# @GuestDeviceInfo:
#
# @driver-name: name of the associated driver
#
# @driver-date: driver release date, in nanoseconds since the epoch
#
# @driver-version: driver version
#
# @id: device ID
#
# Since: 5.2
##
{ 'struct': 'GuestDeviceInfo',
'data': {
'driver-name': 'str',
'*driver-date': 'int',
'*driver-version': 'str',
'*id': 'GuestDeviceId'
} }
##
# @guest-get-devices:
#
# Retrieve information about device drivers in Windows guest
#
# Returns: @GuestDeviceInfo
#
# Since: 5.2
##
{ 'command': 'guest-get-devices',
'returns': ['GuestDeviceInfo'] }
##
# @GuestAuthorizedKeys:
#
# @keys: public keys (in OpenSSH/sshd(8) authorized_keys format)
#
# Since: 5.2
##
{ 'struct': 'GuestAuthorizedKeys',
'data': {
'keys': ['str']
}
}
##
# @guest-ssh-get-authorized-keys:
#
# Return the public keys from user .ssh/authorized_keys on Unix
# systems (not implemented for other systems).
#
# @username: the user account to add the authorized keys
#
# Returns: @GuestAuthorizedKeys
#
# Since: 5.2
##
{ 'command': 'guest-ssh-get-authorized-keys',
'data': { 'username': 'str' },
'returns': 'GuestAuthorizedKeys'
}
##
# @guest-ssh-add-authorized-keys:
#
# Append public keys to user .ssh/authorized_keys on Unix systems (not
# implemented for other systems).
#
# @username: the user account to add the authorized keys
#
# @keys: the public keys to add (in OpenSSH/sshd(8) authorized_keys
# format)
#
# @reset: ignore the existing content, set it with the given keys only
#
# Since: 5.2
##
{ 'command': 'guest-ssh-add-authorized-keys',
'data': { 'username': 'str', 'keys': ['str'], '*reset': 'bool' }
}
##
# @guest-ssh-remove-authorized-keys:
#
# Remove public keys from the user .ssh/authorized_keys on Unix
# systems (not implemented for other systems). It's not an error if
# the key is already missing.
#
# @username: the user account to remove the authorized keys
#
# @keys: the public keys to remove (in OpenSSH/sshd(8) authorized_keys
# format)
#
# Since: 5.2
##
{ 'command': 'guest-ssh-remove-authorized-keys',
'data': { 'username': 'str', 'keys': ['str'] }
}
##
# @GuestDiskStats:
#
# @read-sectors: sectors read
#
# @read-ios: reads completed successfully
#
# @read-merges: read requests merged
#
# @write-sectors: sectors written
#
# @write-ios: writes completed
#
# @write-merges: write requests merged
#
# @discard-sectors: sectors discarded
#
# @discard-ios: discards completed successfully
#
# @discard-merges: discard requests merged
#
# @flush-ios: flush requests completed successfully
#
# @read-ticks: time spent reading(ms)
#
# @write-ticks: time spent writing(ms)
#
# @discard-ticks: time spent discarding(ms)
#
# @flush-ticks: time spent flushing(ms)
#
# @ios-pgr: number of I/Os currently in flight
#
# @total-ticks: time spent doing I/Os (ms)
#
# @weight-ticks: weighted time spent doing I/Os since the last update
# of this field(ms)
#
# Since: 7.1
##
{ 'struct': 'GuestDiskStats',
'data': {'*read-sectors': 'uint64',
'*read-ios': 'uint64',
'*read-merges': 'uint64',
'*write-sectors': 'uint64',
'*write-ios': 'uint64',
'*write-merges': 'uint64',
'*discard-sectors': 'uint64',
'*discard-ios': 'uint64',
'*discard-merges': 'uint64',
'*flush-ios': 'uint64',
'*read-ticks': 'uint64',
'*write-ticks': 'uint64',
'*discard-ticks': 'uint64',
'*flush-ticks': 'uint64',
'*ios-pgr': 'uint64',
'*total-ticks': 'uint64',
'*weight-ticks': 'uint64'
} }
##
# @GuestDiskStatsInfo:
#
# @name: disk name
#
# @major: major device number of disk
#
# @minor: minor device number of disk
#
# @stats: I/O statistics
##
{ 'struct': 'GuestDiskStatsInfo',
'data': {'name': 'str',
'major': 'uint64',
'minor': 'uint64',
'stats': 'GuestDiskStats' } }
##
# @guest-get-diskstats:
#
# Retrieve information about disk stats.
#
# Returns: List of disk stats of guest.
#
# Since: 7.1
##
{ 'command': 'guest-get-diskstats',
'returns': ['GuestDiskStatsInfo']
}
##
# @GuestCpuStatsType:
#
# Guest operating systems supporting CPU statistics
#
# @linux: Linux
#
# Since: 7.1
##
{ 'enum': 'GuestCpuStatsType',
'data': [ 'linux' ] }
##
# @GuestLinuxCpuStats:
#
# CPU statistics of Linux
#
# @cpu: CPU index in guest OS
#
# @user: Time spent in user mode
#
# @nice: Time spent in user mode with low priority (nice)
#
# @system: Time spent in system mode
#
# @idle: Time spent in the idle task
#
# @iowait: Time waiting for I/O to complete (since Linux 2.5.41)
#
# @irq: Time servicing interrupts (since Linux 2.6.0-test4)
#
# @softirq: Time servicing softirqs (since Linux 2.6.0-test4)
#
# @steal: Stolen time by host (since Linux 2.6.11)
#
# @guest: ime spent running a virtual CPU for guest operating systems
# under the control of the Linux kernel (since Linux 2.6.24)
#
# @guestnice: Time spent running a niced guest (since Linux 2.6.33)
#
# Since: 7.1
##
{ 'struct': 'GuestLinuxCpuStats',
'data': {'cpu': 'int',
'user': 'uint64',
'nice': 'uint64',
'system': 'uint64',
'idle': 'uint64',
'*iowait': 'uint64',
'*irq': 'uint64',
'*softirq': 'uint64',
'*steal': 'uint64',
'*guest': 'uint64',
'*guestnice': 'uint64'
} }
##
# @GuestCpuStats:
#
# Get statistics of each CPU in millisecond.
#
# @type: guest operating system
#
# Since: 7.1
##
{ 'union': 'GuestCpuStats',
'base': { 'type': 'GuestCpuStatsType' },
'discriminator': 'type',
'data': { 'linux': 'GuestLinuxCpuStats' } }
##
# @guest-get-cpustats:
#
# Retrieve information about CPU stats.
#
# Returns: List of CPU stats of guest.
#
# Since: 7.1
##
{ 'command': 'guest-get-cpustats',
'returns': ['GuestCpuStats']
}