default

默認主機策略

preferred

首選給定的主機節(jié)點列表進行分配

bind

將內(nèi)存分配限制為給定的主機節(jié)點列表

interleave

在給定主機節(jié)點列表中交錯內(nèi)存分配

-object?memory-backend-file,id=id,size=size,mem-path=dir,share=on|off,discard-data=on|off,merge=on|off,dump=on|off,prealloc=on|off,host-nodes=host-nodes,policy=default|preferred|bind|interleave,align=align,readonly=on|off

創(chuàng)建內(nèi)存文件后端對象，該對象可用于支持具有大頁面的來賓 RAM。

該參數(shù)是一個唯一的 ID，將用于在其他參數(shù)（例如 、等）中引用此內(nèi)存區(qū)域。id-numa-device?nvdimm

該選項提供內(nèi)存區(qū)域的大小，并接受公共后綴，例如 。size500M

提供共享內(nèi)存或大頁面文件系統(tǒng)掛載的路徑。mem-path

布爾選項確定內(nèi)存區(qū)域是標記為 QEMU 專用還是共享。后者允許協(xié)同工作的外部進程訪問 QEMU 內(nèi)存區(qū)域。share

由于 Linux 提供的 RDMA API 中的限制，pvrdma 設(shè)備也需要 。share

在某些情況下，設(shè)置 share=on 可能會影響為內(nèi)存后端配置 NUMA 綁定的能力，有關(guān)其他詳細信息，請參閱 Linux 內(nèi)核源代碼樹上的文檔/vm/numa_memory_policy.txt。

將布爾選項設(shè)置為 on 表示在 QEMU 退出時可以銷毀文件內(nèi)容，以避免不必要地將數(shù)據(jù)刷新到支持文件。請注意，這只是一種優(yōu)化，如果 QEMU 意外中止或使用 SIGKILL 終止，QEMU 可能不會丟棄文件內(nèi)容。discard-datadiscard-data

布爾選項啟用內(nèi)存合并（也稱為MADV_MERGEABLE），以便內(nèi)核同頁合并將考慮內(nèi)存重復(fù)數(shù)據(jù)刪除的頁面。merge

將布爾選項設(shè)置為 off 會從核心轉(zhuǎn)儲中排除內(nèi)存。此功能也稱為MADV_DONTDUMP。dump

布爾選項啟用內(nèi)存預(yù)分配。prealloc

該選項將內(nèi)存范圍綁定到 NUMA 主機節(jié)點的列表。host-nodes

該選項將 NUMA 策略設(shè)置為以下值之一：policy

該選項指定 QEMU mmap（2） 時的基址對齊方式，并接受常用后綴，例如 .指定的某些后端存儲需要與 QEMU 使用的默認對齊方式不同的對齊方式，例如設(shè)備 DAX /dev/dax0.0 需要 2M 對齊而不是 4K。在這種情況下，用戶可以通過此選項指定所需的對齊方式。alignmem-path2Mmem-path

該選項指定 由 指定的支持文件是否位于可以使用 SNIA NVM 編程模型（例如英特爾 NVDIMM）訪問的主機持久內(nèi)存中。如果設(shè)置為“on”，QEMU將采取必要的操作來保證其自身寫入的持久性（例如，在vNVDIMM標簽仿真和實時遷移中）。此外，我們將使用MAP_SYNC標志映射后端文件，以確保文件元數(shù)據(jù)在主機崩潰或電源故障的情況下保持同步。MAP_SYNC需要主機內(nèi)核（從 Linux 內(nèi)核 4.15 開始）和使用 DAX 選項掛載的文件系統(tǒng)的支持。pmemmem-pathpmemmem-pathmem-pathmem-path

該選項指定備份文件是以只讀方式打開還是以讀寫方式打開（默認值）。readonly

-object?memory-backend-ram,id=id,merge=on|off,dump=on|off,share=on|off,prealloc=on|off,size=size,host-nodes=host-nodes,policy=default|preferred|bind|interleave

創(chuàng)建內(nèi)存后端對象，該對象可用于備份來賓 RAM。內(nèi)存后端對象提供比傳統(tǒng)上用于定義來賓 RAM 的選項更多的控制。有關(guān)選項的說明，請參閱。-mmemory-backend-file

-object?memory-backend-memfd,id=id,merge=on|off,dump=on|off,share=on|off,prealloc=on|off,size=size,host-nodes=host-nodes,policy=default|preferred|bind|interleave,seal=on|off,hugetlb=on|off,hugetlbsize=size

創(chuàng)建一個匿名內(nèi)存文件后端對象，該對象允許 QEMU 與外部進程共享內(nèi)存（例如，使用 vhost-user 時）。內(nèi)存分配有 memfd 和可選密封。（僅限 Linux）

該選項創(chuàng)建一個密封文件，該文件將阻止進一步調(diào)整內(nèi)存大?。J情況下為“on”）。seal

該選項指定要創(chuàng)建的文件駐留在 hugetlbfs 文件系統(tǒng)中（從 Linux 4.14 開始）。與該選項結(jié)合使用時，該選項指定支持多個 hugetlb 頁面大小的系統(tǒng)上的 hugetlb 頁面大?。ㄋ仨毷窍到y(tǒng)支持的 2 的冪值）。hugetlbhugetlbhugetlbsize

在某些版本的 Linux 中，該選項與該選項不兼容（至少需要 Linux 4.16）。hugetlbseal

有關(guān)其他選項的說明，請參閱。memory-backend-file

The?boolean option is on by default with memfd.share

-object?rng-builtin,id=id

Creates a random number generator backend which obtains entropy from QEMU builtin functions. The?parameter is a unique ID that will be used to reference this entropy backend from the?device. By default, the?device uses this RNG backend.idvirtio-rngvirtio-rng

-object?rng-random,id=id,filename=/dev/random

Creates a random number generator backend which obtains entropy from a device on the host. The?parameter is a unique ID that will be used to reference this entropy backend from the?device. The?parameter specifies which file to obtain entropy from and if omitted defaults to?.idvirtio-rngfilename/dev/urandom

-object?rng-egd,id=id,chardev=chardevid

Creates a random number generator backend which obtains entropy from an external daemon running on the host. The?parameter is a unique ID that will be used to reference this entropy backend from the?device. The?parameter is the unique ID of a character device backend that provides the connection to the RNG daemon.idvirtio-rngchardev

-object?tls-creds-anon,id=id,endpoint=endpoint,dir=/path/to/cred/dir,verify-peer=on|off

Creates a TLS anonymous credentials object, which can be used to provide TLS support on network backends. The?parameter is a unique ID which network backends will use to access the credentials. The?is either?or?depending on whether the QEMU network backend that uses the credentials will be acting as a client or as a server. If?is enabled (the default) then once the handshake is completed, the peer credentials will be verified, though this is a no-op for anonymous credentials.idendpointserverclientverify-peer

The dir parameter tells QEMU where to find the credential files. For server endpoints, this directory may contain a file dh-params.pem providing diffie-hellman parameters to use for the TLS server. If the file is missing, QEMU will generate a set of DH parameters at startup. This is a computationally expensive operation that consumes random pool entropy, so it is recommended that a persistent set of parameters be generated upfront and saved.

-object?tls-creds-psk,id=id,endpoint=endpoint,dir=/path/to/keys/dir[,username=username]

Creates a TLS Pre-Shared Keys (PSK) credentials object, which can be used to provide TLS support on network backends. The?parameter is a unique ID which network backends will use to access the credentials. The?is either?or?depending on whether the QEMU network backend that uses the credentials will be acting as a client or as a server. For clients only,?is the username which will be sent to the server. If omitted it defaults to “qemu”.idendpointserverclientusername

The dir parameter tells QEMU where to find the keys file. It is called “dir/keys.psk” and contains “username:key” pairs. This file can most easily be created using the GnuTLS?program.psktool

For server endpoints, dir may also contain a file dh-params.pem providing diffie-hellman parameters to use for the TLS server. If the file is missing, QEMU will generate a set of DH parameters at startup. This is a computationally expensive operation that consumes random pool entropy, so it is recommended that a persistent set of parameters be generated up front and saved.

-object?tls-creds-x509,id=id,endpoint=endpoint,dir=/path/to/cred/dir,priority=priority,verify-peer=on|off,passwordid=id

Creates a TLS anonymous credentials object, which can be used to provide TLS support on network backends. The?parameter is a unique ID which network backends will use to access the credentials. The?is either?or?depending on whether the QEMU network backend that uses the credentials will be acting as a client or as a server. If?is enabled (the default) then once the handshake is completed, the peer credentials will be verified. With x509 certificates, this implies that the clients must be provided with valid client certificates too.idendpointserverclientverify-peer

The dir parameter tells QEMU where to find the credential files. For server endpoints, this directory may contain a file dh-params.pem providing diffie-hellman parameters to use for the TLS server. If the file is missing, QEMU will generate a set of DH parameters at startup. This is a computationally expensive operation that consumes random pool entropy, so it is recommended that a persistent set of parameters be generated upfront and saved.

For x509 certificate credentials the directory will contain further files providing the x509 certificates. The certificates must be stored in PEM format, in filenames ca-cert.pem, ca-crl.pem (optional), server-cert.pem (only servers), server-key.pem (only servers), client-cert.pem (only clients), and client-key.pem (only clients).

For the server-key.pem and client-key.pem files which contain sensitive private keys, it is possible to use an encrypted version by providing the passwordid parameter. This provides the ID of a previously created?object containing the password for decryption.secret

The priority parameter allows to override the global default priority used by gnutls. This can be useful if the system administrator needs to use a weaker set of crypto priorities for QEMU without potentially forcing the weakness onto all applications. Or conversely if one wants wants a stronger default for QEMU than for all other applications, they can do this through this parameter. Its format is a gnutls priority string as described at?https://gnutls.org/manual/html_node/Priority-Strings.html.

-object?tls-cipher-suites,id=id,priority=priority

Creates a TLS cipher suites object, which can be used to control the TLS cipher/protocol algorithms that applications are permitted to use.

The?parameter is a unique ID which frontends will use to access the ordered list of permitted TLS cipher suites from the host.id

The?parameter allows to override the global default priority used by gnutls. This can be useful if the system administrator needs to use a weaker set of crypto priorities for QEMU without potentially forcing the weakness onto all applications. Or conversely if one wants wants a stronger default for QEMU than for all other applications, they can do this through this parameter. Its format is a gnutls priority string as described at?https://gnutls.org/manual/html_node/Priority-Strings.html.priority

An example of use of this object is to control UEFI HTTPS Boot. The tls-cipher-suites object exposes the ordered list of permitted TLS cipher suites from the host side to the guest firmware, via fw_cfg. The list is represented as an array of IANA_TLS_CIPHER objects. The firmware uses the IANA_TLS_CIPHER array for configuring guest-side TLS.

In the following example, the priority at which the host-side policy is retrieved is given by the?property. Given that QEMU uses GNUTLS,?may be used to refer to /etc/crypto-policies/back-ends/gnutls.config.prioritypriority=@SYSTEM

# qemu-system-x86_64 \ ? ?-object tls-cipher-suites,id=mysuite0,priority=@SYSTEM \ ? ?-fw_cfg name=etc/edk2/https/ciphers,gen_id=mysuite0

-object?filter-buffer,id=id,netdev=netdevid,interval=t[,queue=all|rx|tx][,status=on|off][,position=head|tail|id=<id>][,insert=behind|before]

Interval t can’t be 0, this filter batches the packet delivery: all packets arriving in a given interval on netdev netdevid are delayed until the end of the interval. Interval is in microseconds.?is optional that indicate whether the netfilter is on (enabled) or off (disabled), the default status for netfilter will be ‘on’.status

queue all|rx|tx is an option that can be applied to any netfilter.

all: the filter is attached both to the receive and the transmit queue of the netdev (default).

rx: the filter is attached to the receive queue of the netdev, where it will receive packets sent to the netdev.

tx: the filter is attached to the transmit queue of the netdev, where it will receive packets sent by the netdev.

position head|tail|id=<id> is an option to specify where the filter should be inserted in the filter list. It can be applied to any netfilter.

head: the filter is inserted at the head of the filter list, before any existing filters.

tail: the filter is inserted at the tail of the filter list, behind any existing filters (default).

id=<id>: the filter is inserted before or behind the filter specified by <id>, see the insert option below.

insert behind|before is an option to specify where to insert the new filter relative to the one specified with position=id=<id>. It can be applied to any netfilter.

before: insert before the specified filter.

behind: insert behind the specified filter (default).

-object?filter-mirror,id=id,netdev=netdevid,outdev=chardevid,queue=all|rx|tx[,vnet_hdr_support][,position=head|tail|id=<id>][,insert=behind|before]

filter-mirror on netdev netdevid,mirror net packet to chardevchardevid, if it has the vnet_hdr_support flag, filter-mirror will mirror packet with vnet_hdr_len.

-object?filter-redirector,id=id,netdev=netdevid,indev=chardevid,outdev=chardevid,queue=all|rx|tx[,vnet_hdr_support][,position=head|tail|id=<id>][,insert=behind|before]

filter-redirector on netdev netdevid,redirect filter’s net packet to chardev chardevid,and redirect indev’s packet to filter.if it has the vnet_hdr_support flag, filter-redirector will redirect packet with vnet_hdr_len. Create a filter-redirector we need to differ outdev id from indev id, id can not be the same. we can just use indev or outdev, but at least one of indev or outdev need to be specified.

-object?filter-rewriter,id=id,netdev=netdevid,queue=all|rx|tx,[vnet_hdr_support][,position=head|tail|id=<id>][,insert=behind|before]

Filter-rewriter is a part of COLO project.It will rewrite tcp packet to secondary from primary to keep secondary tcp connection,and rewrite tcp packet to primary from secondary make tcp packet can be handled by client.if it has the vnet_hdr_support flag, we can parse packet with vnet header.

usage: colo secondary: -object filter-redirector,id=f1,netdev=hn0,queue=tx,indev=red0 -object filter-redirector,id=f2,netdev=hn0,queue=rx,outdev=red1 -object filter-rewriter,id=rew0,netdev=hn0,queue=all

-object?filter-dump,id=id,netdev=dev[,file=filename][,maxlen=len][,position=head|tail|id=<id>][,insert=behind|before]

Dump the network traffic on netdev dev to the file specified by filename. At most len bytes (64k by default) per packet are stored. The file format is libpcap, so it can be analyzed with tools such as tcpdump or Wireshark.

-object?colo-compare,id=id,primary_in=chardevid,secondary_in=chardevid,outdev=chardevid,iothread=id[,vnet_hdr_support][,notify_dev=id][,compare_timeout=@var{ms}][,expired_scan_cycle=@var{ms}][,max_queue_size=@var{size}]

Colo-compare gets packet from primary_in chardevid and secondary_in, then compare whether the payload of primary packet and secondary packet are the same. If same, it will output primary packet to out_dev, else it will notify COLO-framework to do checkpoint and send primary packet to out_dev. In order to improve efficiency, we need to put the task of comparison in another iothread. If it has the vnet_hdr_support flag, colo compare will send/recv packet with vnet_hdr_len. The?compare_timeout=@var{ms} determines the maximum time of the colo-compare hold the packet. The?expired_scan_cycle=@var{ms} is to set the period of scanning expired primary node network packets. The?max_queue_size=@var{size} is to set the max compare queue size depend on user environment. If user want to use Xen COLO, need to add the notify_dev to notify Xen colo-frame to do checkpoint.

COLO-compare must be used with the help of filter-mirror, filter-redirector and filter-rewriter.

KVM COLOprimary:-netdev tap,id=hn0,vhost=off,script=/etc/qemu-ifup,downscript=/etc/qemu-ifdown-device e1000,id=e0,netdev=hn0,mac=52:a4:00:12:78:66-chardev socket,id=mirror0,host=3.3.3.3,port=9003,server=on,wait=off-chardev socket,id=compare1,host=3.3.3.3,port=9004,server=on,wait=off-chardev socket,id=compare0,host=3.3.3.3,port=9001,server=on,wait=off-chardev socket,id=compare0-0,host=3.3.3.3,port=9001-chardev socket,id=compare_out,host=3.3.3.3,port=9005,server=on,wait=off-chardev socket,id=compare_out0,host=3.3.3.3,port=9005-object iothread,id=iothread1-object filter-mirror,id=m0,netdev=hn0,queue=tx,outdev=mirror0-object filter-redirector,netdev=hn0,id=redire0,queue=rx,indev=compare_out-object filter-redirector,netdev=hn0,id=redire1,queue=rx,outdev=compare0-object colo-compare,id=comp0,primary_in=compare0-0,secondary_in=compare1,outdev=compare_out0,iothread=iothread1secondary:-netdev tap,id=hn0,vhost=off,script=/etc/qemu-ifup,down script=/etc/qemu-ifdown-device e1000,netdev=hn0,mac=52:a4:00:12:78:66-chardev socket,id=red0,host=3.3.3.3,port=9003-chardev socket,id=red1,host=3.3.3.3,port=9004-object filter-redirector,id=f1,netdev=hn0,queue=tx,indev=red0-object filter-redirector,id=f2,netdev=hn0,queue=rx,outdev=red1Xen COLOprimary:-netdev tap,id=hn0,vhost=off,script=/etc/qemu-ifup,downscript=/etc/qemu-ifdown-device e1000,id=e0,netdev=hn0,mac=52:a4:00:12:78:66-chardev socket,id=mirror0,host=3.3.3.3,port=9003,server=on,wait=off-chardev socket,id=compare1,host=3.3.3.3,port=9004,server=on,wait=off-chardev socket,id=compare0,host=3.3.3.3,port=9001,server=on,wait=off-chardev socket,id=compare0-0,host=3.3.3.3,port=9001-chardev socket,id=compare_out,host=3.3.3.3,port=9005,server=on,wait=off-chardev socket,id=compare_out0,host=3.3.3.3,port=9005-chardev socket,id=notify_way,host=3.3.3.3,port=9009,server=on,wait=off-object filter-mirror,id=m0,netdev=hn0,queue=tx,outdev=mirror0-object filter-redirector,netdev=hn0,id=redire0,queue=rx,indev=compare_out-object filter-redirector,netdev=hn0,id=redire1,queue=rx,outdev=compare0-object iothread,id=iothread1-object colo-compare,id=comp0,primary_in=compare0-0,secondary_in=compare1,outdev=compare_out0,notify_dev=nofity_way,iothread=iothread1secondary:-netdev tap,id=hn0,vhost=off,script=/etc/qemu-ifup,down script=/etc/qemu-ifdown-device e1000,netdev=hn0,mac=52:a4:00:12:78:66-chardev socket,id=red0,host=3.3.3.3,port=9003-chardev socket,id=red1,host=3.3.3.3,port=9004-object filter-redirector,id=f1,netdev=hn0,queue=tx,indev=red0-object filter-redirector,id=f2,netdev=hn0,queue=rx,outdev=red1

如果你想知道上面命令行的細節(jié)，你可以閱讀colo-compare git日志。

-object?cryptodev-backend-builtin,id=id[,queues=queues]

創(chuàng)建一個加密開發(fā)后端，該后端從 QEMU 密碼 API 執(zhí)行加密操作。id 參數(shù)是一個唯一的 ID，將用于從設(shè)備引用此 cryptodev 后端。queues參數(shù)是可選的，它指定cryptodev后端的隊列編號，隊列的默認值為1。virtio-crypto

# qemu-system-x86_64 \ ?[...] \ ? ? ?-object cryptodev-backend-builtin,id=cryptodev0 \ ? ? ?-device virtio-crypto-pci,id=crypto0,cryptodev=cryptodev0 \ ?[...]