qemu-block-drivers

package: qemu-common

title: qemu-block-drivers(7)

summary: QEMU block drivers reference

text:
# qemu-block-drivers(7)

## NAME
qemu-block-drivers - QEMU block drivers reference

## SYNOPSIS
QEMU block driver reference manual

## DESCRIPTION

### Disk image file formats
QEMU supports many image file formats that can be used with VMs as well as with any of the tools (like qemu-img). This includes the preferred formats raw and qcow2 as well as formats that are supported for compatibility with older QEMU versions or other hypervisors.

Depending on the image format, different options can be passed to qemu-img create and qemu-img convert using the -o option. This section describes each format and the options that are supported for it.

raw

Raw disk image format. This format has the advantage of being simple and easily exportable to all other emulators. If your file system supports holes (for example in ext2 or ext3 on Linux or NTFS on Windows), then only the written sectors will reserve space. Use qemu-img info to know the real size used by the image or ls -ls on Unix/Linux. Supported options:

preallocation

Preallocation mode (allowed values: off, falloc, full). falloc mode preallocates space for image by calling posix_fallocate(). full mode preallocates space for image by writing data to underlying storage. This data may or may not be zero, depending on the storage location.

qcow2

QEMU image format, the most versatile format. Use it to have smaller images (useful if your filesystem does not supports holes, for example on Windows), zlib based compression and support of multiple VM snapshots. Supported options:

compat

Determines the qcow2 version to use. compat=0.10 uses the traditional image format that can be read by any QEMU since 0.10. compat=1.1 enables image format extensions that only QEMU 1.1 and newer understand (this is the default). Amongst others, this includes zero clusters, which allow efficient copy-on-read for sparse images.

backing_file

File name of a base image (see create subcommand)

backing_fmt

Image format of the base image

encryption

This option is deprecated and equivalent to encrypt.format=aes

encrypt.format

If this is set to luks, it requests that the qcow2 payload (not qcow2 header) be encrypted using the LUKS format. The passphrase to use to unlock the LUKS key slot is given by the encrypt.key-secret parameter. LUKS encryption parameters can be tuned with the other encrypt.* parameters. If this is set to aes, the image is encrypted with 128-bit AES-CBC. The encryption key is given by the encrypt.key-secret parameter. This encryption format is considered to be flawed by modern cryptography standards, suffering from a number of design problems:

- The AES-CBC cipher is used with predictable initialization vectors based on the sector number. This makes it vulnerable to chosen plaintext attacks which can reveal the existence of encrypted data.

- The user passphrase is directly used as the encryption key. A poorly chosen or short passphrase will compromise the security of the encryption.

- In the event of the passphrase being compromised there is no way to change the passphrase to protect data in any qcow images. The files must be cloned, using a different encryption passphrase in the new file. The original file must then be securely erased using a program like shred, though even this is ineffective with many modern storage technologies.

The use of this is no longer supported in system emulators. Support only remains in the command line utilities, for the purposes of data liberation and interoperability with old versions of QEMU. The luks format should be used instead.

encrypt.key-secret

Provides the ID of a secret object that contains the passphrase (encrypt.format=luks) or encryption key (encrypt.format=aes).

encrypt.cipher-alg

Name of the cipher algorithm and key length. Currently defaults to aes-256. Only used when encrypt.format=luks.

encrypt.cipher-mode

Name of the encryption mode to use. Currently defaults to xts. Only used when encrypt.format=luks.

encrypt.ivgen-alg

Name of the initialization vector generator algorithm. Currently defaults to plain64. Only used when encrypt.format=luks.

encrypt.ivgen-hash-alg

Name of the hash algorithm to use with the initialization vector generator (if required). Defaults to sha256. Only used when encrypt.format=luks.

encrypt.hash-alg

Name of the hash algorithm to use for PBKDF algorithm Defaults to sha256. Only used when encrypt.format=luks.

encrypt.iter-time

Amount of time, in milliseconds, to use for PBKDF algorithm per key slot. Defaults to 2000. Only used when encrypt.format=luks.

cluster_size

Changes the qcow2 cluster size (must be between 512 and 2M). Smaller cluster sizes can improve the image file size whereas larger cluster sizes generally provide better performance.

preallocation

Preallocation mode (allowed values: off, metadata, falloc, full). An image with preallocated metadata is initially larger but can improve performance when the image needs to grow. falloc and full preallocations are like the same options of raw format, but sets up metadata also.

lazy_refcounts

If this option is set to on, reference count updates are postponed with the goal of avoiding metadata I/O and improving performance. This is particularly interesting with cache=writethrough which doesn't batch metadata updates. The tradeoff is that after a host crash, the reference count tables must be rebuilt, i.e. on the next open an (automatic) qemu-img check -r all is required, which may take some time. This option can only be enabled if compat=1.1 is specified.

nocow

If this option is set to on, it will turn off COW of the file. It's only valid on btrfs, no effect on other file systems. Btrfs has low performance when hosting a VM image file, even more when the guest on the VM also using btrfs as file system. Turning off COW is a way to mitigate this bad performance. Generally there are two ways to turn off COW on btrfs:

- Disable it by mounting with nodatacow, then all newly created files will be NOCOW.

- For an empty file, add the NOCOW file attribute. That's what this option does.

Note: this option is only valid to new or empty files. If there is an existing file which is COW and has data blocks already, it couldn't be changed to NOCOW by setting nocow=on. One can issue lsattr filename to check if the NOCOW flag is set or not (Capital 'C' is NOCOW flag).

qed

Old QEMU image format with support for backing files and compact image files (when your filesystem or transport medium does not support holes). When converting QED images to qcow2, you might want to consider using the lazy_refcounts=on option to get a more QED-like behaviour.

Supported options:

backing_file

File name of a base image (see create subcommand).

backing_fmt

Image file format of backing file (optional). Useful if the format cannot be autodetected because it has no header, like some vhd/vpc files.

cluster_size

Changes the cluster size (must be power-of-2 between 4K and 64K). Smaller cluster sizes can improve the image file size whereas larger cluster sizes generally provide better performance.

table_size

Changes the number of clusters per L1/L2 table (must be power-of-2 between 1 and 16). There is normally no need to change this value but this option can between used for performance benchmarking.

qcow

Old QEMU image format with support for backing files, compact image files, encryption and compression. Supported options:

backing_file

File name of a base image (see create subcommand)

encryption

This option is deprecated and equivalent to encrypt.format=aes

encrypt.format

If this is set to aes, the image is encrypted with 128-bit AES-CBC. The encryption key is given by the encrypt.key-secret parameter. This encryption format is considered to be flawed by modern cryptography standards, suffering from a number of design problems enumerated previously against the qcow2 image format. The use of this is no longer supported in system emulators. Support only remains in the command line utilities, for the purposes of data liberation and interoperability with old versions of QEMU.

Users requiring native encryption should use the qcow2 format instead with encrypt.format=luks.

encrypt.key-secret

Provides the ID of a secret object that contains the encryption key (encrypt.format=aes).

luks

LUKS v1 encryption format, compatible with Linux dm-crypt/cryptsetup Supported options:

key-secret

Provides the ID of a secret object that contains the passphrase.

cipher-alg

Name of the cipher algorithm and key length. Currently defaults to aes-256.

cipher-mode

Name of the encryption mode to use. Currently defaults to xts.

ivgen-alg

Name of the initialization vector generator algorithm. Currently defaults to plain64.

ivgen-hash-alg

Name of the hash algorithm to use with the initialization vector generator (if required). Defaults to sha256.

hash-alg

Name of the hash algorithm to use for PBKDF algorithm Defaults to sha256.

iter-time

Amount of time, in milliseconds, to use for PBKDF algorithm per key slot. Defaults to 2000.

vdi

VirtualBox 1.1 compatible image format. Supported options:

static

If this option is set to on, the image is created with metadata preallocation.

vmdk

VMware 3 and 4 compatible image format. Supported options:

backing_file

File name of a base image (see create subcommand).

compat6

Create a VMDK version 6 image (instead of version 4)

hwversion

Specify vmdk virtual hardware version. Compat6 flag cannot be enabled if hwversion is specified.

subformat

Specifies which VMDK subformat to use. Valid options are monolithicSparse (default), monolithicFlat, twoGbMaxExtentSparse, twoGbMaxExtentFlat and streamOptimized.

vpc

VirtualPC compatible image format (VHD). Supported options:

subformat

Specifies which VHD subformat to use. Valid options are dynamic (default) and fixed.

VHDX

Hyper-V compatible image format (VHDX). Supported options:

subformat

Specifies which VHDX subformat to use. Valid options are dynamic (default) and fixed.

block_state_zero

Force use of payload blocks of type 'ZERO'. Can be set to on (default) or off. When set to off, new blocks will be created as PAYLOAD_BLOCK_NOT_PRESENT, which means parsers are free to return arbitrary data for those blocks. Do not set to off when using qemu-img convert with subformat=dynamic.

block_size

Block size; min 1 MB, max 256 MB. 0 means auto-calculate based on image size.

log_size

Log size; min 1 MB.

### Read-only formats
More disk image file formats are supported in a read-only mode.

bochs

Bochs images of growing type.

cloop

Linux Compressed Loop image, useful only to reuse directly compressed CD-ROM images present for example in the Knoppix CD-ROMs.

dmg

Apple disk image.

parallels

Parallels disk image format.

### Using host drives
In addition to disk image files, QEMU can directly access host devices. We describe here the usage for QEMU version >= 0.8.3.

### Linux
On Linux, you can directly use the host device filename instead of a disk image filename provided you have enough privileges to access it. For example, use /dev/cdrom to access to the CDROM.

CD

You can specify a CDROM device even if no CDROM is loaded. QEMU has specific code to detect CDROM insertion or removal. CDROM ejection by the guest OS is supported. Currently only data CDs are supported.

Floppy

You can specify a floppy device even if no floppy is loaded. Floppy removal is currently not detected accurately (if you change floppy without doing floppy access while the floppy is not loaded, the guest OS will think that the same floppy is loaded). Use of the host's floppy device is deprecated, and support for it will be removed in a future release.

Hard disks

Hard disks can be used. Normally you must specify the whole disk (/dev/hdb instead of /dev/hdb1) so that the guest OS can see it as a partitioned disk. WARNING: unless you know what you do, it is better to only make READ-ONLY accesses to the hard disk otherwise you may corrupt your host data (use the -snapshot command line option or modify the device permissions accordingly).

Zoned block devices

Zoned block devices can be passed through to the guest if the emulated storage controller supports zoned storage. Use --blockdev host_device, node-name=drive0,filename=/dev/nullb0,cache.direct=on to pass through /dev/nullb0 as drive0.

### Windows
CD

The preferred syntax is the drive letter (e.g. d:). The alternate syntax \\.\d: is supported. /dev/cdrom is supported as an alias to the first CDROM drive. Currently there is no specific code to handle removable media, so it is better to use the change or eject monitor commands to change or eject media.

Hard disks

Hard disks can be used with the syntax: \\.\PhysicalDriveN where N is the drive number (0 is the first hard disk). WARNING: unless you know what you do, it is better to only make READ-ONLY accesses to the hard disk otherwise you may corrupt your host data (use the -snapshot command line so that the modifications are written in a temporary file).

### Mac OS X
/dev/cdrom is an alias to the first CDROM.

Currently there is no specific code to handle removable media, so it is better to use the change or eject monitor commands to change or eject media.

### Virtual FAT disk images
QEMU can automatically create a virtual FAT disk image from a directory tree. In order to use it, just type:

```
qemu-system-x86_64 linux.img -hdb fat:/my_directory
```

Then you access access to all the files in the /my_directory directory without having to copy them in a disk image or to export them via SAMBA or NFS. The default access is read-only.

Floppies can be emulated with the :floppy: option:

```
qemu-system-x86_64 linux.img -fda fat:floppy:/my_directory
```

A read/write support is available for testing (beta stage) with the :rw: option:

```
qemu-system-x86_64 linux.img -fda fat:floppy:rw:/my_directory
```

What you should never do:

- use non-ASCII filenames

- use "-snapshot" together with ":rw:"

- expect it to work when loadvm'ing

- write to the FAT directory on the host system while accessing it with the guest system

### NBD access
QEMU can access directly to block device exported using the Network Block Device protocol.

```
qemu-system-x86_64 linux.img -hdb nbd://my_nbd_server.mydomain.org:1024/
```

If the NBD server is located on the same host, you can use an unix socket instead of an inet socket:

```
qemu-system-x86_64 linux.img -hdb nbd+unix://?socket=/tmp/my_socket
```

In this case, the block device must be exported using qemu-nbd:

```
qemu-nbd --socket=/tmp/my_socket my_disk.qcow2
```

The use of qemu-nbd allows sharing of a disk between several guests:

```
qemu-nbd --socket=/tmp/my_socket --share=2 my_disk.qcow2
```

and then you can use it with two guests:

```
qemu-system-x86_64 linux1.img -hdb nbd+unix://?socket=/tmp/my_socket
qemu-system-x86_64 linux2.img -hdb nbd+unix://?socket=/tmp/my_socket
```

If the nbd-server uses named exports (supported since NBD 2.9.18, or with QEMU's own embedded NBD server), you must specify an export name in the URI:

```
qemu-system-x86_64 -cdrom nbd://localhost/debian-500-ppc-netinst
qemu-system-x86_64 -cdrom nbd://localhost/openSUSE-11.1-ppc-netinst
```

The URI syntax for NBD is supported since QEMU 1.3. An alternative syntax is also available. Here are some example of the older syntax:

```
qemu-system-x86_64 linux.img -hdb nbd:my_nbd_server.mydomain.org:1024
qemu-system-x86_64 linux2.img -hdb nbd:unix:/tmp/my_socket
qemu-system-x86_64 -cdrom nbd:localhost:10809:exportname=debian-500-ppc-netinst
```

### iSCSI LUNs
iSCSI is a popular protocol used to access SCSI devices across a computer network.

There are two different ways iSCSI devices can be used by QEMU.

The first method is to mount the iSCSI LUN on the host, and make it appear as any other ordinary SCSI device on the host and then to access this device as a /dev/sd device from QEMU. How to do this differs between host OSes.

The second method involves using the iSCSI initiator that is built into QEMU. This provides a mechanism that works the same way regardless of which host OS you are running QEMU on. This section will describe this second method of using iSCSI together with QEMU.

In QEMU, iSCSI devices are described using special iSCSI URLs. URL syntax:

```
iscsi://[<username>[%<password>]@]<host>[:<port>]/<target-iqn-name>/<lun>
```

Username and password are optional and only used if your target is set up using CHAP authentication for access control. Alternatively the username and password can also be set via environment variables to have these not show up in the process list:

```
export LIBISCSI_CHAP_USERNAME=<username>
export LIBISCSI_CHAP_PASSWORD=<password>
iscsi://<host>/<target-iqn-name>/<lun>
```

Various session related parameters can be set via special options, either in a configuration file provided via '-readconfig' or directly on the command line.

If the initiator-name is not specified qemu will use a default name of 'iqn.2008-11.org.linux-kvm[:<uuid>'] where <uuid> is the UUID of the virtual machine. If the UUID is not specified qemu will use 'iqn.2008-11.org.linux-kvm[:<name>'] where <name> is the name of the virtual machine.

Setting a specific initiator name to use when logging in to the target:

```
-iscsi initiator-name=iqn.qemu.test:my-initiator
```

Controlling which type of header digest to negotiate with the target:

```
-iscsi header-digest=CRC32C|CRC32C-NONE|NONE-CRC32C|NONE
```

These can also be set via a configuration file:

```
[iscsi]

  user = "CHAP username"

  password = "CHAP password"

  initiator-name = "iqn.qemu.test:my-initiator"

  # header digest is one of CRC32C|CRC32C-NONE|NONE-CRC32C|NONE

  header-digest = "CRC32C"
```

Setting the target name allows different options for different targets:

```
[iscsi "iqn.target.name"]

  user = "CHAP username"

  password = "CHAP password"

  initiator-name = "iqn.qemu.test:my-initiator"

  # header digest is one of CRC32C|CRC32C-NONE|NONE-CRC32C|NONE

  header-digest = "CRC32C"
```

How to use a configuration file to set iSCSI configuration options:

```
cat >iscsi.conf <<EOF
[iscsi]

  user = "me"

  password = "my password"

  initiator-name = "iqn.qemu.test:my-initiator"

  header-digest = "CRC32C"
EOF
qemu-system-x86_64 -drive file=iscsi://127.0.0.1/iqn.qemu.test/1 \

  -readconfig iscsi.conf
```

How to set up a simple iSCSI target on loopback and access it via QEMU: this example shows how to set up an iSCSI target with one CDROM and one DISK using the Linux STGT software target. This target is available on Red Hat based systems as the package 'scsi-target-utils'.

```
tgtd --iscsi portal=127.0.0.1:3260
tgtadm --lld iscsi --op new --mode target --tid 1 -T iqn.qemu.test
tgtadm --lld iscsi --mode logicalunit --op new --tid 1 --lun 1 \

    -b /IMAGES/disk.img --device-type=disk
tgtadm --lld iscsi --mode logicalunit --op new --tid 1 --lun 2 \

    -b /IMAGES/cd.iso --device-type=cd
tgtadm --lld iscsi --op bind --mode target --tid 1 -I ALL
qemu-system-x86_64 -iscsi initiator-name=iqn.qemu.test:my-initiator \

  -boot d -drive file=iscsi://127.0.0.1/iqn.qemu.test/1 \

  -cdrom iscsi://127.0.0.1/iqn.qemu.test/2
```

### GlusterFS disk images
GlusterFS is a user space distributed file system.

You can boot from the GlusterFS disk image with the command:

URI:

```
qemu-system-x86_64 -drive file=gluster[+TYPE]://[HOST}[:PORT]]/VOLUME/PATH

                             [?socket=...][,file.debug=9][,file.logfile=...]
```

JSON:

```
qemu-system-x86_64 'json:{"driver":"qcow2",

                         "file":{"driver":"gluster",

                                  "volume":"testvol","path":"a.img","debug":9,"logfile":"...",

                                  "server":[{"type":"tcp","host":"...","port":"..."},

                                            {"type":"unix","socket":"..."}]}}'
```

gluster is the protocol.

TYPE specifies the transport type used to connect to gluster management daemon (glusterd). Valid transport types are tcp and unix. In the URI form, if a transport type isn't specified, then tcp type is assumed.

HOST specifies the server where the volume file specification for the given volume resides. This can be either a hostname or an ipv4 address. If transport type is unix, then HOST field should not be specified. Instead socket field needs to be populated with the path to unix domain socket.

PORT is the port number on which glusterd is listening. This is optional and if not specified, it defaults to port 24007. If the transport type is unix, then PORT should not be specified.

VOLUME is the name of the gluster volume which contains the disk image.

PATH is the path to the actual disk image that resides on gluster volume.

debug is the logging level of the gluster protocol driver. Debug levels are 0-9, with 9 being the most verbose, and 0 representing no debugging output. The default level is 4. The current logging levels defined in the gluster source are 0 - None, 1 - Emergency, 2 - Alert, 3 - Critical, 4 - Error, 5 - Warning, 6 - Notice, 7 - Info, 8 - Debug, 9 - Trace

logfile is a commandline option to mention log file path which helps in logging to the specified file and also help in persisting the gfapi logs. The default is stderr.

You can create a GlusterFS disk image with the command:

```
qemu-img create gluster://HOST/VOLUME/PATH SIZE
```

Examples

```
qemu-system-x86_64 -drive file=gluster://1.2.3.4/testvol/a.img
qemu-system-x86_64 -drive file=gluster+tcp://1.2.3.4/testvol/a.img
qemu-system-x86_64 -drive file=gluster+tcp://1.2.3.4:24007/testvol/dir/a.img
qemu-system-x86_64 -drive file=gluster+tcp://[1:2:3:4:5:6:7:8]/testvol/dir/a.img
qemu-system-x86_64 -drive file=gluster+tcp://[1:2:3:4:5:6:7:8]:24007/testvol/dir/a.img
qemu-system-x86_64 -drive file=gluster+tcp://server.domain.com:24007/testvol/dir/a.img
qemu-system-x86_64 -drive file=gluster+unix:///testvol/dir/a.img?socket=/tmp/glusterd.socket
qemu-system-x86_64 -drive file=gluster+rdma://1.2.3.4:24007/testvol/a.img
qemu-system-x86_64 -drive file=gluster://1.2.3.4/testvol/a.img,file.debug=9,file.logfile=/var/log/qemu-gluster.log
qemu-system-x86_64 'json:{"driver":"qcow2",

                         "file":{"driver":"gluster",

                                  "volume":"testvol","path":"a.img",

                                  "debug":9,"logfile":"/var/log/qemu-gluster.log",

                                  "server":[{"type":"tcp","host":"1.2.3.4","port":24007},

                                            {"type":"unix","socket":"/var/run/glusterd.socket"}]}}'
qemu-system-x86_64 -drive driver=qcow2,file.driver=gluster,file.volume=testvol,file.path=/path/a.img,

                                     file.debug=9,file.logfile=/var/log/qemu-gluster.log,

                                     file.server.0.type=tcp,file.server.0.host=1.2.3.4,file.server.0.port=24007,

                                     file.server.1.type=unix,file.server.1.socket=/var/run/glusterd.socket
```

### Secure Shell (ssh) disk images
You can access disk images located on a remote ssh server by using the ssh protocol:

```
qemu-system-x86_64 -drive file=ssh://[USER@]SERVER[:PORT]/PATH[?host_key_check=HOST_KEY_CHECK]
```

Alternative syntax using properties:

```
qemu-system-x86_64 -drive file.driver=ssh[,file.user=USER],file.host=SERVER[,file.port=PORT],file.path=PATH[,file.host_key_check=HOST_KEY_CHECK]
```

ssh is the protocol.

USER is the remote user. If not specified, then the local username is tried.

SERVER specifies the remote ssh server. Any ssh server can be used, but it must implement the sftp-server protocol. Most Unix/Linux systems should work without requiring any extra configuration.

PORT is the port number on which sshd is listening. By default the standard ssh port (22) is used.

PATH is the path to the disk image.

The optional HOST_KEY_CHECK parameter controls how the remote host's key is checked. The default is yes which means to use the local .ssh/known_hosts file. Setting this to no turns off known-hosts checking. Or you can check that the host key matches a specific fingerprint. The fingerprint can be provided in md5, sha1, or sha256 format, however, it is strongly recommended to only use sha256, since the other options are considered insecure by modern standards. The fingerprint value must be given as a hex encoded string:

```
host_key_check=sha256:04ce2ae89ff4295a6b9c4111640bdcb3297858ee55cb434d9dd88796e93aa795
```

The key string may optionally contain ":" separators between each pair of hex digits.

The $HOME/.ssh/known_hosts file contains the base64 encoded host keys. These can be converted into the format needed for QEMU using a command such as:

```
$ for key in `grep 10.33.8.112 known_hosts | awk '{print $3}'`

  do

    echo $key | base64 -d | sha256sum

  done

  6c3aa525beda9dc83eadfbd7e5ba7d976ecb59575d1633c87cd06ed2ed6e366f  -

  12214fd9ea5b408086f98ecccd9958609bd9ac7c0ea316734006bc7818b45dc8  -

  d36420137bcbd101209ef70c3b15dc07362fbe0fa53c5b135eba6e6afa82f0ce  -
```

Note that there can be multiple keys present per host, each with different key ciphers. Care is needed to pick the key fingerprint that matches the cipher QEMU will negotiate with the remote server.

Currently authentication must be done using ssh-agent. Other authentication methods may be supported in future.

Note: Many ssh servers do not support an fsync-style operation. The ssh driver cannot guarantee that disk flush requests are obeyed, and this causes a risk of disk corruption if the remote server or network goes down during writes. The driver will print a warning when fsync is not supported:

```
warning: ssh server ssh.example.com:22 does not support fsync
```

With sufficiently new versions of libssh and OpenSSH, fsync is supported.

### NVMe disk images
NVM Express (NVMe) storage controllers can be accessed directly by a userspace driver in QEMU. This bypasses the host kernel file system and block layers while retaining QEMU block layer functionalities, such as block jobs, I/O throttling, image formats, etc. Disk I/O performance is typically higher than with -drive file=/dev/sda using either thread pool or linux-aio.

The controller will be exclusively used by the QEMU process once started. To be able to share storage between multiple VMs and other applications on the host, please use the file based protocols.

Before starting QEMU, bind the host NVMe controller to the host vfio-pci driver. For example:

```
# modprobe vfio-pci
# lspci -n -s 0000:06:0d.0
06:0d.0 0401: 1102:0002 (rev 08)
# echo 0000:06:0d.0 > /sys/bus/pci/devices/0000:06:0d.0/driver/unbind
# echo 1102 0002 > /sys/bus/pci/drivers/vfio-pci/new_id
# qemu-system-x86_64 -drive file=nvme://HOST:BUS:SLOT.FUNC/NAMESPACE
```

Alternative syntax using properties:

```
qemu-system-x86_64 -drive file.driver=nvme,file.device=HOST:BUS:SLOT.FUNC,file.namespace=NAMESPACE
```

HOST:BUS:SLOT.FUNC is the NVMe controller's PCI device address on the host.

NAMESPACE is the NVMe namespace number, starting from 1.

### Disk image file locking
By default, QEMU tries to protect image files from unexpected concurrent access, as long as it's supported by the block protocol driver and host operating system. If multiple QEMU processes (including QEMU emulators and utilities) try to open the same image with conflicting accessing modes, all but the first one will get an error.

This feature is currently supported by the file protocol on Linux with the Open File Descriptor (OFD) locking API, and can be configured to fall back to POSIX locking if the POSIX host doesn't support Linux OFD locking.

To explicitly enable image locking, specify "locking=on" in the file protocol driver options. If OFD locking is not possible, a warning will be printed and the POSIX locking API will be used. In this case there is a risk that the lock will get silently lost when doing hot plugging and block jobs, due to the shortcomings of the POSIX locking API.

QEMU transparently handles lock handover during shared storage migration. For shared virtual disk images between multiple VMs, the "share-rw" device option should be used.

By default, the guest has exclusive write access to its disk image. If the guest can safely share the disk image with other writers the -device ...,share-rw=on parameter can be used. This is only safe if the guest is running software, such as a cluster file system, that coordinates disk accesses to avoid corruption.

Note that share-rw=on only declares the guest's ability to share the disk. Some QEMU features, such as image file formats, require exclusive write access to the disk image and this is unaffected by the share-rw=on option.

Alternatively, locking can be fully disabled by "locking=off" block device option. In the command line, the option is usually in the form of "file.locking=off" as the protocol driver is normally placed as a "file" child under a format driver. For example:

```
-blockdev driver=qcow2,file.filename=/path/to/image,file.locking=off,file.driver=file
```

To check if image locking is active, check the output of the "lslocks" command on host and see if there are locks held by the QEMU process on the image file. More than one byte could be locked by the QEMU instance, each byte of which reflects a particular permission that is acquired or protected by the running block driver.

### Filter drivers
QEMU supports several filter drivers, which don't store any data, but perform some additional tasks, hooking io requests.

preallocate

The preallocate filter driver is intended to be inserted between format and protocol nodes and preallocates some additional space (expanding the protocol file) when writing past the file’s end. This can be useful for file-systems with slow allocation. Supported options:

prealloc-align

On preallocation, align the file length to this value (in bytes), default 1M.

prealloc-size

How much to preallocate (in bytes), default 128M.

## SEE ALSO
The HTML documentation of QEMU for more precise information and Linux user mode emulator invocation.

## AUTHOR
Fabrice Bellard and the QEMU Project developers

## COPYRIGHT
2024, The QEMU Project Developers


qemu-cpu-models

title: qemu-cpu-models(7)

summary: QEMU CPU Models

text:
# qemu-cpu-models(7)

## NAME
qemu-cpu-models - QEMU CPU Models

## SYNOPSIS
QEMU CPU Modelling Infrastructure manual

## DESCRIPTION

### Recommendations for KVM CPU model configuration on x86 hosts
The information that follows provides recommendations for configuring CPU models on x86 hosts. The goals are to maximise performance, while protecting guest OS against various CPU hardware flaws, and optionally enabling live migration between hosts with heterogeneous CPU models.

### Two ways to configure CPU models with QEMU / KVM
1.

Host passthrough This passes the host CPU model features, model, stepping, exactly to the guest. Note that KVM may filter out some host CPU model features if they cannot be supported with virtualization. Live migration is unsafe when this mode is used as libvirt / QEMU cannot guarantee a stable CPU is exposed to the guest across hosts. This is the recommended CPU to use, provided live migration is not required.

2.

Named model QEMU comes with a number of predefined named CPU models, that typically refer to specific generations of hardware released by Intel and AMD. These allow the guest VMs to have a degree of isolation from the host CPU, allowing greater flexibility in live migrating between hosts with differing hardware. @end table

In both cases, it is possible to optionally add or remove individual CPU features, to alter what is presented to the guest by default.

Libvirt supports a third way to configure CPU models known as "Host model". This uses the QEMU "Named model" feature, automatically picking a CPU model that is similar the host CPU, and then adding extra features to approximate the host model as closely as possible. This does not guarantee the CPU family, stepping, etc will precisely match the host CPU, as they would with "Host passthrough", but gives much of the benefit of passthrough, while making live migration safe.

### ABI compatibility levels for CPU models
The x86_64 architecture has a number of ABI compatibility levels defined. Traditionally most operating systems and toolchains would only target the original baseline ABI. It is expected that in future OS and toolchains are likely to target newer ABIs. The table that follows illustrates which ABI compatibility levels can be satisfied by the QEMU CPU models. Note that the table only lists the long term stable CPU model versions (eg Haswell-v4). In addition to what is listed, there are also many CPU model aliases which resolve to a different CPU model version, depending on the machine type is in use.

### x86-64 ABI compatibility levels
Model

baseline

v2

v3

v4

486-v1

Broadwell-v1

✅

✅

✅

Broadwell-v2

✅

✅

✅

Broadwell-v3

✅

✅

✅

Broadwell-v4

✅

✅

✅

Cascadelake-Server-v1

✅

✅

✅

✅

Cascadelake-Server-v2

✅

✅

✅

✅

Cascadelake-Server-v3

✅

✅

✅

✅

Cascadelake-Server-v4

✅

✅

✅

✅

Conroe-v1

✅

Cooperlake-v1

✅

✅

✅

✅

Denverton-v1

✅

✅

Denverton-v2

✅

✅

Dhyana-v1

✅

✅

✅

EPYC-Milan-v1

✅

✅

✅

EPYC-Rome-v1

✅

✅

✅

EPYC-Rome-v2

✅

✅

✅

EPYC-v1

✅

✅

✅

EPYC-v2

✅

✅

✅

EPYC-v3

✅

✅

✅

Haswell-v1

✅

✅

✅

Haswell-v2

✅

✅

✅

Haswell-v3

✅

✅

✅

Haswell-v4

✅

✅

✅

Icelake-Client-v1

✅

✅

✅

Icelake-Client-v2

✅

✅

✅

Icelake-Server-v1

✅

✅

✅

✅

Icelake-Server-v2

✅

✅

✅

✅

Icelake-Server-v3

✅

✅

✅

✅

Icelake-Server-v4

✅

✅

✅

✅

IvyBridge-v1

✅

✅

IvyBridge-v2

✅

✅

KnightsMill-v1

✅

✅

✅

Nehalem-v1

✅

✅

Nehalem-v2

✅

✅

Opteron_G1-v1

✅

Opteron_G2-v1

✅

Opteron_G3-v1

✅

Opteron_G4-v1

✅

✅

Opteron_G5-v1

✅

✅

Penryn-v1

✅

SandyBridge-v1

✅

✅

SandyBridge-v2

✅

✅

Skylake-Client-v1

✅

✅

✅

Skylake-Client-v2

✅

✅

✅

Skylake-Client-v3

✅

✅

✅

Skylake-Server-v1

✅

✅

✅

✅

Skylake-Server-v2

✅

✅

✅

✅

Skylake-Server-v3

✅

✅

✅

✅

Skylake-Server-v4

✅

✅

✅

✅

Snowridge-v1

✅

✅

Snowridge-v2

✅

✅

Westmere-v1

✅

✅

Westmere-v2

✅

✅

athlon-v1

core2duo-v1

✅

coreduo-v1

kvm32-v1

kvm64-v1

✅

n270-v1

pentium-v1

pentium2-v1

pentium3-v1

phenom-v1

✅

qemu32-v1

qemu64-v1

✅

### Preferred CPU models for Intel x86 hosts
The following CPU models are preferred for use on Intel hosts. Administrators / applications are recommended to use the CPU model that matches the generation of the host CPUs in use. In a deployment with a mixture of host CPU models between machines, if live migration compatibility is required, use the newest CPU model that is compatible across all desired hosts.

Cascadelake-Server, Cascadelake-Server-noTSX

Intel Xeon Processor (Cascade Lake, 2019), with "stepping" levels 6 or 7 only. (The Cascade Lake Xeon processor with stepping 5 is vulnerable to MDS variants.)

Skylake-Server, Skylake-Server-IBRS, Skylake-Server-IBRS-noTSX

Intel Xeon Processor (Skylake, 2016)

Skylake-Client, Skylake-Client-IBRS, Skylake-Client-noTSX-IBRS}

Intel Core Processor (Skylake, 2015)

Broadwell, Broadwell-IBRS, Broadwell-noTSX, Broadwell-noTSX-IBRS

Intel Core Processor (Broadwell, 2014)

Haswell, Haswell-IBRS, Haswell-noTSX, Haswell-noTSX-IBRS

Intel Core Processor (Haswell, 2013)

IvyBridge, IvyBridge-IBR

Intel Xeon E3-12xx v2 (Ivy Bridge, 2012)

SandyBridge, SandyBridge-IBRS

Intel Xeon E312xx (Sandy Bridge, 2011)

Westmere, Westmere-IBRS

Westmere E56xx/L56xx/X56xx (Nehalem-C, 2010)

Nehalem, Nehalem-IBRS

Intel Core i7 9xx (Nehalem Class Core i7, 2008)

Penryn

Intel Core 2 Duo P9xxx (Penryn Class Core 2, 2007)

Conroe

Intel Celeron_4x0 (Conroe/Merom Class Core 2, 2006)

### Important CPU features for Intel x86 hosts
The following are important CPU features that should be used on Intel x86 hosts, when available in the host CPU. Some of them require explicit configuration to enable, as they are not included by default in some, or all, of the named CPU models listed above. In general all of these features are included if using "Host passthrough" or "Host model".

pcid

Recommended to mitigate the cost of the Meltdown (CVE-2017-5754) fix. Included by default in Haswell, Broadwell & Skylake Intel CPU models.

Should be explicitly turned on for Westmere, SandyBridge, and IvyBridge Intel CPU models. Note that some desktop/mobile Westmere CPUs cannot support this feature.

spec-ctrl

Required to enable the Spectre v2 (CVE-2017-5715) fix. Included by default in Intel CPU models with -IBRS suffix.

Must be explicitly turned on for Intel CPU models without -IBRS suffix.

Requires the host CPU microcode to support this feature before it can be used for guest CPUs.

stibp

Required to enable stronger Spectre v2 (CVE-2017-5715) fixes in some operating systems. Must be explicitly turned on for all Intel CPU models.

Requires the host CPU microcode to support this feature before it can be used for guest CPUs.

ssbd

Required to enable the CVE-2018-3639 fix. Not included by default in any Intel CPU model.

Must be explicitly turned on for all Intel CPU models.

Requires the host CPU microcode to support this feature before it can be used for guest CPUs.

pdpe1gb

Recommended to allow guest OS to use 1GB size pages. Not included by default in any Intel CPU model.

Should be explicitly turned on for all Intel CPU models.

Note that not all CPU hardware will support this feature.

md-clear

Required to confirm the MDS (CVE-2018-12126, CVE-2018-12127, CVE-2018-12130, CVE-2019-11091) fixes. Not included by default in any Intel CPU model.

Must be explicitly turned on for all Intel CPU models.

Requires the host CPU microcode to support this feature before it can be used for guest CPUs.

mds-no

Recommended to inform the guest OS that the host is not vulnerable to any of the MDS variants ([MFBDS] CVE-2018-12130, [MLPDS] CVE-2018-12127, [MSBDS] CVE-2018-12126). This is an MSR (Model-Specific Register) feature rather than a CPUID feature, so it will not appear in the Linux /proc/cpuinfo in the host or guest. Instead, the host kernel uses it to populate the MDS vulnerability file in sysfs.

So it should only be enabled for VMs if the host reports @code{Not affected} in the /sys/devices/system/cpu/vulnerabilities/mds file.

taa-no

Recommended to inform that the guest that the host is not vulnerable to CVE-2019-11135, TSX Asynchronous Abort (TAA). This too is an MSR feature, so it does not show up in the Linux /proc/cpuinfo in the host or guest.

It should only be enabled for VMs if the host reports Not affected in the /sys/devices/system/cpu/vulnerabilities/tsx_async_abort file.

tsx-ctrl

Recommended to inform the guest that it can disable the Intel TSX (Transactional Synchronization Extensions) feature; or, if the processor is vulnerable, use the Intel VERW instruction (a processor-level instruction that performs checks on memory access) as a mitigation for the TAA vulnerability. (For details, refer to Intel's deep dive into MDS.) Expose this to the guest OS if and only if: (a) the host has TSX enabled; and (b) the guest has rtm CPU flag enabled.

By disabling TSX, KVM-based guests can avoid paying the price of mitigating TSX-based attacks.

Note that tsx-ctrl too is an MSR feature, so it does not show up in the Linux /proc/cpuinfo in the host or guest.

To validate that Intel TSX is indeed disabled for the guest, there are two ways: (a) check for the absence of rtm in the guest's /proc/cpuinfo; or (b) the /sys/devices/system/cpu/vulnerabilities/tsx_async_abort file in the guest should report Mitigation: TSX disabled.

### Preferred CPU models for AMD x86 hosts
The following CPU models are preferred for use on AMD hosts. Administrators / applications are recommended to use the CPU model that matches the generation of the host CPUs in use. In a deployment with a mixture of host CPU models between machines, if live migration compatibility is required, use the newest CPU model that is compatible across all desired hosts.

EPYC, EPYC-IBPB

AMD EPYC Processor (2017)

Opteron_G5

AMD Opteron 63xx class CPU (2012)

Opteron_G4

AMD Opteron 62xx class CPU (2011)

Opteron_G3

AMD Opteron 23xx (Gen 3 Class Opteron, 2009)

Opteron_G2

AMD Opteron 22xx (Gen 2 Class Opteron, 2006)

Opteron_G1

AMD Opteron 240 (Gen 1 Class Opteron, 2004)

### Important CPU features for AMD x86 hosts
The following are important CPU features that should be used on AMD x86 hosts, when available in the host CPU. Some of them require explicit configuration to enable, as they are not included by default in some, or all, of the named CPU models listed above. In general all of these features are included if using "Host passthrough" or "Host model".

ibpb

Required to enable the Spectre v2 (CVE-2017-5715) fix. Included by default in AMD CPU models with -IBPB suffix.

Must be explicitly turned on for AMD CPU models without -IBPB suffix.

Requires the host CPU microcode to support this feature before it can be used for guest CPUs.

stibp

Required to enable stronger Spectre v2 (CVE-2017-5715) fixes in some operating systems. Must be explicitly turned on for all AMD CPU models.

Requires the host CPU microcode to support this feature before it can be used for guest CPUs.

virt-ssbd

Required to enable the CVE-2018-3639 fix Not included by default in any AMD CPU model.

Must be explicitly turned on for all AMD CPU models.

This should be provided to guests, even if amd-ssbd is also provided, for maximum guest compatibility.

Note for some QEMU / libvirt versions, this must be force enabled when when using "Host model", because this is a virtual feature that doesn't exist in the physical host CPUs.

amd-ssbd

Required to enable the CVE-2018-3639 fix Not included by default in any AMD CPU model.

Must be explicitly turned on for all AMD CPU models.

This provides higher performance than virt-ssbd so should be exposed to guests whenever available in the host. virt-ssbd should none the less also be exposed for maximum guest compatibility as some kernels only know about virt-ssbd.

amd-no-ssb

Recommended to indicate the host is not vulnerable CVE-2018-3639 Not included by default in any AMD CPU model.

Future hardware generations of CPU will not be vulnerable to CVE-2018-3639, and thus the guest should be told not to enable its mitigations, by exposing amd-no-ssb. This is mutually exclusive with virt-ssbd and amd-ssbd.

pdpe1gb

Recommended to allow guest OS to use 1GB size pages Not included by default in any AMD CPU model.

Should be explicitly turned on for all AMD CPU models.

Note that not all CPU hardware will support this feature.

### Default x86 CPU models
The default QEMU CPU models are designed such that they can run on all hosts. If an application does not wish to do perform any host compatibility checks before launching guests, the default is guaranteed to work.

The default CPU models will, however, leave the guest OS vulnerable to various CPU hardware flaws, so their use is strongly discouraged. Applications should follow the earlier guidance to setup a better CPU configuration, with host passthrough recommended if live migration is not needed.

qemu32, qemu64

QEMU Virtual CPU version 2.5+ (32 & 64 bit variants)

qemu64 is used for x86_64 guests and qemu32 is used for i686 guests, when no -cpu argument is given to QEMU, or no <cpu> is provided in libvirt XML.

### Other non-recommended x86 CPUs
The following CPUs models are compatible with most AMD and Intel x86 hosts, but their usage is discouraged, as they expose a very limited featureset, which prevents guests having optimal performance.

kvm32, kvm64

Common KVM processor (32 & 64 bit variants). Legacy models just for historical compatibility with ancient QEMU versions.

486, athlon, phenom, coreduo, core2duo, n270, pentium, pentium2, pentium3

Various very old x86 CPU models, mostly predating the introduction of hardware assisted virtualization, that should thus not be required for running virtual machines.

### Syntax for configuring CPU models
The examples below illustrate the approach to configuring the various CPU models / features in QEMU and libvirt.

### QEMU command line
Host passthrough:

```
qemu-system-x86_64 -cpu host
```

Host passthrough with feature customization:

```
qemu-system-x86_64 -cpu host,vmx=off,...
```

Named CPU models:

```
qemu-system-x86_64 -cpu Westmere
```

Named CPU models with feature customization:

```
qemu-system-x86_64 -cpu Westmere,pcid=on,...
```

### Libvirt guest XML
Host passthrough:

```
<cpu mode='host-passthrough'/>
```

Host passthrough with feature customization:

```
<cpu mode='host-passthrough'>

    <feature name="vmx" policy="disable"/>

    ...
</cpu>
```

Host model:

```
<cpu mode='host-model'/>
```

Host model with feature customization:

```
<cpu mode='host-model'>

    <feature name="vmx" policy="disable"/>

    ...
</cpu>
```

Named model:

```
<cpu mode='custom'>

    <model name="Westmere"/>
</cpu>
```

Named model with feature customization:

```
<cpu mode='custom'>

    <model name="Westmere"/>

    <feature name="pcid" policy="require"/>

    ...
</cpu>
```

### Supported CPU model configurations on MIPS hosts
QEMU supports variety of MIPS CPU models:

### Supported CPU models for MIPS32 hosts
The following CPU models are supported for use on MIPS32 hosts. Administrators / applications are recommended to use the CPU model that matches the generation of the host CPUs in use. In a deployment with a mixture of host CPU models between machines, if live migration compatibility is required, use the newest CPU model that is compatible across all desired hosts.

mips32r6-generic

MIPS32 Processor (Release 6, 2015)

P5600

MIPS32 Processor (P5600, 2014)

M14K, M14Kc

MIPS32 Processor (M14K, 2009)

74Kf

MIPS32 Processor (74K, 2007)

34Kf

MIPS32 Processor (34K, 2006)

24Kc, 24KEc, 24Kf

MIPS32 Processor (24K, 2003)

4Kc, 4Km, 4KEcR1, 4KEmR1, 4KEc, 4KEm

MIPS32 Processor (4K, 1999)

### Supported CPU models for MIPS64 hosts
The following CPU models are supported for use on MIPS64 hosts. Administrators / applications are recommended to use the CPU model that matches the generation of the host CPUs in use. In a deployment with a mixture of host CPU models between machines, if live migration compatibility is required, use the newest CPU model that is compatible across all desired hosts.

I6400

MIPS64 Processor (Release 6, 2014)

Loongson-2E

MIPS64 Processor (Loongson 2, 2006)

Loongson-2F

MIPS64 Processor (Loongson 2, 2008)

Loongson-3A1000

MIPS64 Processor (Loongson 3, 2010)

Loongson-3A4000

MIPS64 Processor (Loongson 3, 2018)

mips64dspr2

MIPS64 Processor (Release 2, 2006)

MIPS64R2-generic, 5KEc, 5KEf

MIPS64 Processor (Release 2, 2002)

20Kc

MIPS64 Processor (20K, 2000

5Kc, 5Kf

MIPS64 Processor (5K, 1999)

VR5432

MIPS64 Processor (VR, 1998)

R4000

MIPS64 Processor (MIPS III, 1991)

### Supported CPU models for nanoMIPS hosts
The following CPU models are supported for use on nanoMIPS hosts. Administrators / applications are recommended to use the CPU model that matches the generation of the host CPUs in use. In a deployment with a mixture of host CPU models between machines, if live migration compatibility is required, use the newest CPU model that is compatible across all desired hosts.

I7200

MIPS I7200 (nanoMIPS, 2018)

### Preferred CPU models for MIPS hosts
The following CPU models are preferred for use on different MIPS hosts:

MIPS III

R4000

MIPS32R2

34Kf

MIPS64R6

I6400

nanoMIPS

I7200

## SEE ALSO
The HTML documentation of QEMU for more precise information and Linux user mode emulator invocation.

## AUTHOR
The QEMU Project developers

## COPYRIGHT
2024, The QEMU Project Developers


qemu-ga-ref

title: qemu-ga-ref(7)

summary: QEMU Guest Agent Protocol Reference

text:
# qemu-ga-ref(7)

## NAME
qemu-ga-ref - QEMU Guest Agent Protocol Reference

### Contents
•

QEMU Guest Agent Protocol Reference

•

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

- guest-sync-delimited (Command)

- guest-sync (Command)

- guest-ping (Command)

- guest-get-time (Command)

- guest-set-time (Command)

- GuestAgentCommandInfo (Object)

- GuestAgentInfo (Object)

- guest-info (Command)

- guest-shutdown (Command)

- guest-file-open (Command)

- guest-file-close (Command)

- GuestFileRead (Object)

- guest-file-read (Command)

- GuestFileWrite (Object)

- guest-file-write (Command)

- GuestFileSeek (Object)

- QGASeek (Enum)

- GuestFileWhence (Alternate)

- guest-file-seek (Command)

- guest-file-flush (Command)

- GuestFsfreezeStatus (Enum)

- guest-fsfreeze-status (Command)

- guest-fsfreeze-freeze (Command)

- guest-fsfreeze-freeze-list (Command)

- guest-fsfreeze-thaw (Command)

- GuestFilesystemTrimResult (Object)

- GuestFilesystemTrimResponse (Object)

- guest-fstrim (Command)

- guest-suspend-disk (Command)

- guest-suspend-ram (Command)

- guest-suspend-hybrid (Command)

- GuestIpAddressType (Enum)

- GuestIpAddress (Object)

- GuestNetworkInterfaceStat (Object)

- GuestNetworkInterface (Object)

- guest-network-get-interfaces (Command)

- GuestLogicalProcessor (Object)

- guest-get-vcpus (Command)

- guest-set-vcpus (Command)

- GuestDiskBusType (Enum)

- GuestPCIAddress (Object)

- GuestCCWAddress (Object)

- GuestDiskAddress (Object)

- GuestNVMeSmart (Object)

- GuestDiskSmart (Object)

- GuestDiskInfo (Object)

- guest-get-disks (Command)

- GuestFilesystemInfo (Object)

- guest-get-fsinfo (Command)

- guest-set-user-password (Command)

- GuestMemoryBlock (Object)

- guest-get-memory-blocks (Command)

- GuestMemoryBlockResponseType (Enum)

- GuestMemoryBlockResponse (Object)

- guest-set-memory-blocks (Command)

- GuestMemoryBlockInfo (Object)

- guest-get-memory-block-info (Command)

- GuestExecStatus (Object)

- guest-exec-status (Command)

- GuestExec (Object)

- GuestExecCaptureOutputMode (Enum)

- GuestExecCaptureOutput (Alternate)

- guest-exec (Command)

- GuestHostName (Object)

- guest-get-host-name (Command)

- GuestUser (Object)

- guest-get-users (Command)

- GuestTimezone (Object)

- guest-get-timezone (Command)

- GuestOSInfo (Object)

- guest-get-osinfo (Command)

- GuestDeviceType (Enum)

- GuestDeviceIdPCI (Object)

- GuestDeviceId (Object)

- GuestDeviceInfo (Object)

- guest-get-devices (Command)

- GuestAuthorizedKeys (Object)

- guest-ssh-get-authorized-keys (Command)

- guest-ssh-add-authorized-keys (Command)

- guest-ssh-remove-authorized-keys (Command)

- GuestDiskStats (Object)

- GuestDiskStatsInfo (Object)

- guest-get-diskstats (Command)

- GuestCpuStatsType (Enum)

- GuestLinuxCpuStats (Object)

- GuestCpuStats (Object)

- guest-get-cpustats (Command)

## 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

### guest-sync-delimited (Command)
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.

### Arguments
id: int

randomly generated 64-bit integer

### Returns
The unique integer id passed in by the client

### Since
1.1

### guest-sync (Command)
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.

### Arguments
id: int

randomly generated 64-bit integer

### Returns
The unique integer id passed in by the client

### Since
0.15.0

### guest-ping (Command)
Ping the guest agent, a non-error return implies success

### Since
0.15.0

### guest-get-time (Command)
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

### guest-set-time (Command)
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.

### Arguments
time: int (optional)

time of nanoseconds, relative to the Epoch of 1970-01-01 in UTC.

### Returns
Nothing on success.

### Since
1.5

### GuestAgentCommandInfo (Object)
Information about guest agent commands.

### Members
name: string

name of the command

enabled: boolean

whether command is currently enabled by guest admin

success-response: boolean

whether command returns a response on success (since 1.7)

### Since
1.1.0

### GuestAgentInfo (Object)
Information about guest agent.

### Members
version: string

guest agent version

supported_commands: array of GuestAgentCommandInfo

Information about guest agent commands

### Since
0.15.0

### guest-info (Command)
Get some information about the guest agent.

### Returns
GuestAgentInfo

### Since
0.15.0

### guest-shutdown (Command)
Initiate guest-activated shutdown. Note: this is an asynchronous shutdown request, with no guarantee of successful shutdown.

### Arguments
mode: string (optional)

"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

### guest-file-open (Command)
Open a file in the guest and retrieve a file handle for it

### Arguments
path: string

Full path to the file in the guest to open.

mode: string (optional)

open mode, as per fopen(), "r" is the default.

### Returns
Guest file handle on success.

### Since
0.15.0

### guest-file-close (Command)
Close an open file in the guest

### Arguments
handle: int

filehandle returned by guest-file-open

### Returns
Nothing on success.

### Since
0.15.0

### GuestFileRead (Object)
Result of guest agent file-read operation

### Members
count: int

number of bytes read (note: count is before base64-encoding is applied)

buf-b64: string

base64-encoded bytes read

eof: boolean

whether EOF was encountered during read operation.

### Since
0.15.0

### guest-file-read (Command)
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.

### Arguments
handle: int

filehandle returned by guest-file-open

count: int (optional)

maximum number of bytes to read (default is 4KB, maximum is 48MB)

### Returns
GuestFileRead on success.

### Since
0.15.0

### GuestFileWrite (Object)
Result of guest agent file-write operation

### Members
count: int

number of bytes written (note: count is actual bytes written, after base64-decoding of provided buffer)

eof: boolean

whether EOF was encountered during write operation.

### Since
0.15.0

### guest-file-write (Command)
Write to an open file in the guest.

### Arguments
handle: int

filehandle returned by guest-file-open

buf-b64: string

base64-encoded string representing data to be written

count: int (optional)

bytes to write (actual bytes, after base64-decode), default is all content in buf-b64 buffer after base64 decoding

### Returns
GuestFileWrite on success.

### Since
0.15.0

### GuestFileSeek (Object)
Result of guest agent file-seek operation

### Members
position: int

current file position

eof: boolean

whether EOF was encountered during file seek

### Since
0.15.0

### QGASeek (Enum)
Symbolic names for use in guest-file-seek

### Values
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

### GuestFileWhence (Alternate)
Controls the meaning of offset to guest-file-seek.

### Members
value: int

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: QGASeek

Symbolic name, and preferred interface

### Since
2.6

### guest-file-seek (Command)
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.

### Arguments
handle: int

filehandle returned by guest-file-open

offset: int

bytes to skip over in the file stream

whence: GuestFileWhence

Symbolic or numeric code for interpreting offset

### Returns
GuestFileSeek on success.

### Since
0.15.0

### guest-file-flush (Command)
Write file changes buffered in userspace to disk/kernel buffers

### Arguments
handle: int

filehandle returned by guest-file-open

### Returns
Nothing on success.

### Since
0.15.0

### GuestFsfreezeStatus (Enum)
An enumeration of filesystem freeze states

### Values
thawed

filesystems thawed/unfrozen

frozen

all non-network guest filesystems frozen

### Since
0.15.0

### guest-fsfreeze-status (Command)
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

### guest-fsfreeze-freeze (Command)
Sync and freeze all freezable, local guest filesystems. If this command succeeded, you may call guest-fsfreeze-thaw later to unfreeze.

### 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.

### Returns
Number of file systems currently frozen. 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.

### Since
0.15.0

### guest-fsfreeze-freeze-list (Command)
Sync and freeze specified guest filesystems. See also guest-fsfreeze-freeze.

### Arguments
mountpoints: array of string (optional)

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. On error, all filesystems will be thawed.

### Since
2.2

### guest-fsfreeze-thaw (Command)
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

### Members
path: string

path that was trimmed

error: string (optional)

an error message when trim failed

trimmed: int (optional)

bytes trimmed for this path

minimum: int (optional)

reported effective minimum for this path

### Since
2.4

### Members
paths: array of GuestFilesystemTrimResult

list of GuestFilesystemTrimResult per path that was trimmed

### Since
2.4

### guest-fstrim (Command)
Discard (or "trim") blocks which are not in use by the filesystem.

### Arguments
minimum: int (optional)

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

### guest-suspend-disk (Command)
Suspend guest to disk.

This command attempts to suspend the guest using three strategies, in this order:

- systemd hibernate

- pm-utils (via pm-hibernate)

- manual write into sysfs

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.

The following errors may be returned:

•

If suspend to disk 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

### guest-suspend-ram (Command)
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"

The following errors may be returned:

•

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

### guest-suspend-hybrid (Command)
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"

The following errors may be returned:

•

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

### GuestIpAddressType (Enum)
An enumeration of supported IP address types

### Values
ipv4

IP version 4

ipv6

IP version 6

### Since
1.1

### Members
ip-address: string

IP address

ip-address-type: GuestIpAddressType

Type of ip-address (e.g. ipv4, ipv6)

prefix: int

Network prefix length of ip-address

### Since
1.1

### Members
rx-bytes: int

total bytes received

rx-packets: int

total packets received

rx-errs: int

bad packets received

rx-dropped: int

receiver dropped packets

tx-bytes: int

total bytes transmitted

tx-packets: int

total packets transmitted

tx-errs: int

packet transmit problems

tx-dropped: int

dropped packets transmitted

### Since
2.11

### Members
name: string

The name of interface for which info are being delivered

hardware-address: string (optional)

Hardware address of name

ip-addresses: array of GuestIpAddress (optional)

List of addresses assigned to name

statistics: GuestNetworkInterfaceStat (optional)

various statistic counters related to name (since 2.11)

### Since
1.1

### guest-network-get-interfaces (Command)
Get list of guest IP addresses, MAC addresses and netmasks.

### Returns
List of GuestNetworkInterface on success.

### Since
1.1

### Members
logical-id: int

Arbitrary guest-specific unique identifier of the VCPU.

online: boolean

Whether the VCPU is enabled.

can-offline: boolean (optional)

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

### guest-get-vcpus (Command)
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

### guest-set-vcpus (Command)
Attempt to reconfigure (currently: enable/disable) logical processors inside the guest.

The input 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.

### Arguments
vcpus: array of GuestLogicalProcessor

Not documented

### 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,

- Error: processing the first node of vcpus failed for the reason returned. 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.

### Since
1.5

### GuestDiskBusType (Enum)
An enumeration of bus type of disks

### Values
ide

IDE disks

fdc

floppy disks

scsi

SCSI disks

virtio

virtio disks

xen

Xen disks

usb

USB disks

uml

UML disks

sata

SATA disks

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)

### Since
2.2; 'Unknown' and all entries below since 2.4

### Members
domain: int

domain id

bus: int

bus id

slot: int

slot id

function: int

function id

### Since
2.2

### Members
cssid: int

channel subsystem image id

ssid: int

subchannel set id

subchno: int

subchannel number

devno: int

device number

### Since
6.0

### Members
pci-controller: GuestPCIAddress

controller's PCI address (fields are set to -1 if invalid)

bus-type: GuestDiskBusType

bus type

bus: int

bus id

target: int

target id

unit: int

unit id

serial: string (optional)

serial number (since: 3.1)

dev: string (optional)

device node (POSIX) or device UNC (Windows) (since: 3.1)

ccw-address: GuestCCWAddress (optional)

CCW address on s390x (since: 6.0)

### Since
2.2

### GuestNVMeSmart (Object)
NVMe smart information, based on NVMe specification, section <SMART / Health Information (Log Identifier 02h)>

### Members
critical-warning: int

Not documented

temperature: int

Not documented

available-spare: int

Not documented

available-spare-threshold: int

Not documented

percentage-used: int

Not documented

data-units-read-lo: int

Not documented

data-units-read-hi: int

Not documented

data-units-written-lo: int

Not documented

data-units-written-hi: int

Not documented

host-read-commands-lo: int

Not documented

host-read-commands-hi: int

Not documented

host-write-commands-lo: int

Not documented

host-write-commands-hi: int

Not documented

controller-busy-time-lo: int

Not documented

controller-busy-time-hi: int

Not documented

power-cycles-lo: int

Not documented

power-cycles-hi: int

Not documented

power-on-hours-lo: int

Not documented

power-on-hours-hi: int

Not documented

unsafe-shutdowns-lo: int

Not documented

unsafe-shutdowns-hi: int

Not documented

media-errors-lo: int

Not documented

media-errors-hi: int

Not documented

number-of-error-log-entries-lo: int

Not documented

number-of-error-log-entries-hi: int

Not documented

### Since
7.1

### GuestDiskSmart (Object)
Disk type related smart information.

•

nvme: NVMe disk smart

### Members
type: GuestDiskBusType

Not documented

The members of GuestNVMeSmart when type is "nvme"

### Since
7.1

### Members
name: string

device node (Linux) or device UNC (Windows)

partition: boolean

whether this is a partition or disk

dependencies: array of string (optional)

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: GuestDiskAddress (optional)

disk address information (only for non-virtual devices)

alias: string (optional)

optional alias assigned to the disk, on Linux this is a name assigned by device mapper

smart: GuestDiskSmart (optional)

disk smart information (Since 7.1)

### Since
5.2

### 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

### Members
name: string

disk name

mountpoint: string

mount point path

type: string

file system type string

used-bytes: int (optional)

file system used bytes (since 3.0)

total-bytes: int (optional)

non-root file system total bytes (since 3.0)

disk: array of GuestDiskAddress

an array of disk hardware information that the volume lies on, which may be empty if the disk type is not supported

### Since
2.2

### 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.

### Since
2.2

### Arguments
username: string

the user account whose password to change

password: string

the new password entry string, base64 encoded

crypted: boolean

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.

Not all guest operating systems will support use of the crypted flag, as they may require the clear-text password

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.

### Returns
Nothing on success.

### Since
2.3

### Members
phys-index: int

Arbitrary guest-specific unique identifier of the MEMORY BLOCK.

online: boolean

Whether the MEMORY BLOCK is enabled in guest.

can-offline: boolean (optional)

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

### guest-get-memory-blocks (Command)
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

### GuestMemoryBlockResponseType (Enum)
An enumeration of memory block operation result.

### Values
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

### Members
phys-index: int

same with the 'phys-index' member of GuestMemoryBlock.

response: GuestMemoryBlockResponseType

the result of memory block operation.

error-code: int (optional)

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

### guest-set-memory-blocks (Command)
Attempt to reconfigure (currently: enable/disable) state of memory blocks inside the guest.

The input 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.

### Arguments
mem-blks: array of GuestMemoryBlock

Not documented

### Returns
The operation results, it is a list of GuestMemoryBlockResponse, which is corresponding to the input list.

Note: it will return NULL 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

### Members
size: int

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

### guest-get-memory-block-info (Command)
Get information relating to guest memory blocks.

### Returns
GuestMemoryBlockInfo

### Since
2.3

### Members
exited: boolean

true if process has already terminated.

exitcode: int (optional)

process exit code if it was normally terminated.

signal: int (optional)

signal number (linux) or unhandled exception code (windows) if the process was abnormally terminated.

out-data: string (optional)

base64-encoded stdout of the process. This field will only be populated after the process exits.

err-data: string (optional)

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: boolean (optional)

true if stdout was not fully captured due to size limitation.

err-truncated: boolean (optional)

true if stderr was not fully captured due to size limitation.

### Since
2.5

### guest-exec-status (Command)
Check status of process associated with PID retrieved via guest-exec. Reap the process and associated metadata if it has exited.

### Arguments
pid: int

pid returned from guest-exec

### Returns
GuestExecStatus on success.

### Since
2.5

### Members
pid: int

pid of child process in guest OS

### Since
2.5

### GuestExecCaptureOutputMode (Enum)
An enumeration of guest-exec capture modes.

### Values
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 (If: not CONFIG_WIN32)

capture both stdout and stderr, but merge together into out-data. not effective on windows guests.

### Since
8.0

### GuestExecCaptureOutput (Alternate)
Controls what guest-exec output gets captures.

### Members
flag: boolean

captures both stdout and stderr if true. Equivalent to GuestExecCaptureOutputMode::all. (since 2.5)

mode: GuestExecCaptureOutputMode

capture mode; preferred interface

### Since
8.0

### guest-exec (Command)
Execute a command in the guest

### Arguments
path: string

path or executable name to execute

arg: array of string (optional)

argument list to pass to executable

env: array of string (optional)

environment variables to pass to executable

input-data: string (optional)

data to be passed to process stdin (base64 encoded)

capture-output: GuestExecCaptureOutput (optional)

bool flag to enable capture of stdout/stderr of running process. defaults to false.

### Returns
PID on success.

### Since
2.5

### Members
host-name: string

Fully qualified domain name of the guest OS

### Since
2.10

### guest-get-host-name (Command)
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 on success

### Since
2.10

### Members
user: string

Username

domain: string (optional)

Logon domain (windows only)

login-time: number

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

### guest-get-users (Command)
Retrieves a list of currently active users on the VM.

### Returns
A unique list of users.

### Since
2.10

### Members
zone: string (optional)

Timezone name. These values may differ depending on guest/OS and should only be used for informational purposes.

offset: int

Offset to UTC in seconds, negative numbers for time zones west of GMT, positive numbers for east

### Since
2.10

### guest-get-timezone (Command)
Retrieves the timezone information from the guest.

### Returns
A GuestTimezone dictionary.

### Since
2.10

### Members
kernel-release: string (optional)

- POSIX: release field returned by uname(2)

- Windows: build number of the OS

kernel-version: string (optional)

- POSIX: version field returned by uname(2)

- Windows: version number of the OS

machine: string (optional)

- POSIX: machine field returned by uname(2)

- Windows: one of x86, x86_64, arm, ia64

id: string (optional)

- POSIX: as defined by os-release(5)

- Windows: contains string "mswindows"

name: string (optional)

- POSIX: as defined by os-release(5)

- Windows: contains string "Microsoft Windows"

pretty-name: string (optional)

- POSIX: as defined by os-release(5)

- Windows: product name, e.g. "Microsoft Windows 10 Enterprise"

version: string (optional)

- POSIX: as defined by os-release(5)

- Windows: long version string, e.g. "Microsoft Windows Server 2008"

version-id: string (optional)

- POSIX: as defined by os-release(5)

- Windows: short version identifier, e.g. "7" or "20012r2"

variant: string (optional)

- POSIX: as defined by os-release(5)

- Windows: contains string "server" or "client"

variant-id: string (optional)

- 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

### guest-get-osinfo (Command)
Retrieve guest operating system information

### Returns
GuestOSInfo

### Since
2.10

### Values
pci

Not documented

### Members
vendor-id: int

vendor ID

device-id: int

device ID

### Since
5.2

### GuestDeviceId (Object)
Id of the device - pci: PCI ID, since: 5.2

### Members
type: GuestDeviceType

Not documented

The members of GuestDeviceIdPCI when type is "pci"

### Since
5.2

### Members
driver-name: string

name of the associated driver

driver-date: int (optional)

driver release date, in nanoseconds since the epoch

driver-version: string (optional)

driver version

id: GuestDeviceId (optional)

device ID

### Since
5.2

### guest-get-devices (Command)
Retrieve information about device drivers in Windows guest

### Returns
GuestDeviceInfo

### Since
5.2

### Members
keys: array of string

public keys (in OpenSSH/sshd(8) authorized_keys format)

### Since
5.2

### If
CONFIG_POSIX

### Arguments
username: string

the user account to add the authorized keys

Return the public keys from user .ssh/authorized_keys on Unix systems (not implemented for other systems).

### Returns
GuestAuthorizedKeys

### Since
5.2

### If
CONFIG_POSIX

### Arguments
username: string

the user account to add the authorized keys

keys: array of string

the public keys to add (in OpenSSH/sshd(8) authorized_keys format)

reset: boolean (optional)

ignore the existing content, set it with the given keys only

Append public keys to user .ssh/authorized_keys on Unix systems (not implemented for other systems).

### Returns
Nothing on success.

### Since
5.2

### If
CONFIG_POSIX

### Arguments
username: string

the user account to remove the authorized keys

keys: array of string

the public keys to remove (in OpenSSH/sshd(8) authorized_keys format)

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.

### Returns
Nothing on success.

### Since
5.2

### If
CONFIG_POSIX

### Members
read-sectors: int (optional)

sectors read

read-ios: int (optional)

reads completed successfully

read-merges: int (optional)

read requests merged

write-sectors: int (optional)

sectors written

write-ios: int (optional)

writes completed

write-merges: int (optional)

write requests merged

discard-sectors: int (optional)

sectors discarded

discard-ios: int (optional)

discards completed successfully

discard-merges: int (optional)

discard requests merged

flush-ios: int (optional)

flush requests completed successfully

read-ticks: int (optional)

time spent reading(ms)

write-ticks: int (optional)

time spent writing(ms)

discard-ticks: int (optional)

time spent discarding(ms)

flush-ticks: int (optional)

time spent flushing(ms)

ios-pgr: int (optional)

number of I/Os currently in flight

total-ticks: int (optional)

time spent doing I/Os (ms)

weight-ticks: int (optional)

weighted time spent doing I/Os since the last update of this field(ms)

### Since
7.1

### Members
name: string

disk name

major: int

major device number of disk

minor: int

minor device number of disk

stats: GuestDiskStats

Not documented

### guest-get-diskstats (Command)
Retrieve information about disk stats.

### Returns
List of disk stats of guest.

### Since
7.1

### GuestCpuStatsType (Enum)
An enumeration of OS type

### Values
linux

Not documented

### Since
7.1

### GuestLinuxCpuStats (Object)
CPU statistics of Linux

### Members
cpu: int

CPU index in guest OS

user: int

Time spent in user mode

nice: int

Time spent in user mode with low priority (nice)

system: int

Time spent in system mode

idle: int

Time spent in the idle task

iowait: int (optional)

Time waiting for I/O to complete (since Linux 2.5.41)

irq: int (optional)

Time servicing interrupts (since Linux 2.6.0-test4)

softirq: int (optional)

Time servicing softirqs (since Linux 2.6.0-test4)

steal: int (optional)

Stolen time by host (since Linux 2.6.11)

guest: int (optional)

ime spent running a virtual CPU for guest operating systems under the control of the Linux kernel (since Linux 2.6.24)

guestnice: int (optional)

Time spent running a niced guest (since Linux 2.6.33)

### Since
7.1

### GuestCpuStats (Object)
Get statistics of each CPU in millisecond.

•

linux: Linux style CPU statistics

### Members
type: GuestCpuStatsType

Not documented

The members of GuestLinuxCpuStats when type is "linux"

### Since
7.1

### guest-get-cpustats (Command)
Retrieve information about CPU stats.

### Returns
List of CPU stats of guest.

### Since
7.1

## COPYRIGHT
2024, The QEMU Project Developers