不是原創(chuàng)只提供翻譯!機(jī)器翻譯可能不正常!

已棄用的功能

通常，功能旨在無限期地支持一次 引入QEMU。如果需要?jiǎng)h除某個(gè)要素， 它將在本節(jié)中列出。該功能將保持功能 已棄用的版本和另一個(gè)版本。在這兩者之后 發(fā)布后，該功能可能會(huì)被刪除。已棄用的功能也可能 在 QEMU 啟動(dòng)時(shí)或在通過 監(jiān)視命令，但是，這不是強(qiáng)制性要求。

在 2.10.0 版本之前，沒有關(guān)于如何的官方政策 長功能在刪除之前將被棄用，也不會(huì) 任何已棄用的功能的文檔列表。因此 在 2.10.0 之前棄用的任何功能都將被視為 它們?cè)?2.10.0 版本中首次被棄用。

以下是當(dāng)前標(biāo)記為 荒廢的。

構(gòu)建選項(xiàng)

gprof內(nèi)部版本（自 8.0 起）

配置設(shè)置依賴于編譯器 檢測以收集其數(shù)據(jù)，這些數(shù)據(jù)可能會(huì)扭曲生成的 輪廓。由于其他非儀器工具可用，因此可提供 使用非檢測二進(jìn)制文件更全面地了解系統(tǒng) 棄用生成選項(xiàng)，不再在 CI 中保護(hù)它。分析測試用例的構(gòu)建選項(xiàng)仍然存在 覆蓋。--enable-gprof--enable-gcov

系統(tǒng)仿真器命令行參數(shù)

QEMU_AUDIO_環(huán)境變量和（自 4.0 起）-audio-help

參數(shù)現(xiàn)在是指定音頻的首選方法 后端設(shè)置而不是環(huán)境變量。為了簡化遷移到 新格式，該選項(xiàng)可用于轉(zhuǎn)換 環(huán)境變量到選項(xiàng)的當(dāng)前值。-audiodev-audiodev-help-audiodev

創(chuàng)建沒有屬性的聲卡設(shè)備和 vnc（從 4.2 開始）audiodev=

不使用已棄用的舊版音頻配置時(shí)，每個(gè)聲卡 應(yīng)指定一個(gè)屬性。此外，使用 VNC，如果您計(jì)劃指定一個(gè)屬性，則應(yīng)指定一個(gè)屬性 通過 VNC 協(xié)議傳輸音頻。audiodev=audiodev=

短格式布爾選項(xiàng)（自 6.0 起）

布爾選項(xiàng)，例如 / 可以寫入 簡稱為 和 ?，F(xiàn)已棄用 并會(huì)引起警告。share=onshare=offsharenoshare

delay套接字字符設(shè)備選項(xiàng)（自 6.0 起）

短格式布爾選項(xiàng)的替換是 而不是 。nodelaynodelay=ondelay=off

-smp（“參數(shù)=0” SMP 配置）（自 6.2 起）

指定的 CPU 拓?fù)鋮?shù)必須大于零。

在 SMP 配置中，用戶應(yīng)提供 CPU 拓?fù)?具有合理值（大于零）的參數(shù)或省略它 QEMU將計(jì)算缺失值。

但是，從歷史上看，它隱式地允許用戶提供 值為零的參數(shù)，這是沒有意義的，也可能 在 -SMP 分析中導(dǎo)致意外結(jié)果。所以支持這種 配置（例如 -smp 8，sockets=0）自 6.2 起被棄用，并且將 在不久的將來被移除，用戶要保證所有的拓?fù)浣Y(jié)構(gòu) 使用 -SMP 描述的成員大于零。

插件參數(shù)傳遞（自 6.1 起）arg=<string>

通過 TCG 插件參數(shù)傳遞是多余的，這使得 命令行的可讀性較差，尤其是當(dāng)參數(shù)本身由 名稱和值，例如 . 因此，用法是多余的。處理單字參數(shù) 作為短格式布爾值，并作為 . 但是，短格式布爾值已被棄用，首選完全顯式形式。arg=-plugin?plugin_name,arg="arg_name=arg_value"argarg_name=onarg_name=on

-no-hpet?(since 8.0)

The HPET setting has been turned into a machine property. Use?instead.-machine?hpet=off

-no-acpi?(since 8.0)

The?setting has been turned into a machine property. Use?instead.-no-acpi-machine?acpi=off

-accel?hax?(since 8.0)

The HAXM project has been retired (see?https://github.com/intel/haxm#status). Use “whpx” (on Windows) or “hvf” (on macOS) instead.

-async-teardown?(since 8.1)

Use?instead.-run-with?async-teardown=on

-chroot?(since 8.1)

Use?instead.-run-with?chroot=dir

-singlestep?(since 8.1)

The?option has been turned into an accelerator property, and given a name that better reflects what it actually does. Use?instead.-singlestep-accel?tcg,one-insn-per-tb=on

User-mode emulator command line arguments

-singlestep?(since 8.1)

The?option has been given a name that better reflects what it actually does. For both linux-user and bsd-user, use the new?option instead.-singlestep-one-insn-per-tb

QEMU Machine Protocol (QMP) commands

blockdev-open-tray,?argument?(since 2.8)blockdev-close-traydevice

Use argument?instead.id

eject?argument?(since 2.8)device

Use argument?instead.id

blockdev-change-medium?argument?(since 2.8)device

Use argument?instead.id

block_set_io_throttle?argument?(since 2.8)device

Use argument?instead.id

blockdev-add?empty string argument?(since 2.10)backing

Use argument value?instead.null

block-commit?arguments?and?(since 3.1)basetop

Use arguments?and?instead.base-nodetop-node

nbd-server-add?and?(since 5.2)nbd-server-remove

Use the more generic commands?and?instead. As part of this deprecation, where?used a single?, the new?uses a list of?.block-export-addblock-export-delnbd-server-addbitmapblock-export-addbitmaps

query-qmp-schema?return value member?(since 6.2)values

Member?in return value elements with meta-type?is deprecated. Use?instead.valuesenummembers

drive-backup?(since 6.2)

Use?in combination with?instead. This change primarily separates the creation/opening process of the backup target with explicit, separate steps.?uses mostly the same arguments as?, except the?and?options are removed in favor of using explicit?and?calls. See?Live Block Device Operations?for details.blockdev-backupblockdev-addblockdev-backupdrive-backupformatmodeblockdev-createblockdev-add

Incorrectly typed?arguments (since 6.2)device_add

Due to shortcomings in the internal implementation of?, QEMU incorrectly accepts certain invalid arguments: Any object or list arguments are silently ignored. Other argument types are not checked, but an implicit conversion happens, so that e.g. string values can be assigned to integer device properties or vice versa.device_add

This is a bug in QEMU that will be fixed in the future so that previously accepted incorrect commands will return an error. Users should make sure that all arguments passed to?are consistent with the documented property types.device_add

StatusInfo?member?(since 8.1)singlestep

The?member of the?returned from the?command is deprecated. This member has a confusing name and it never did what the documentation claimed or what its name suggests. We do not believe that anybody is actually using the information provided in this member.singlestepStatusInfoquery-status

The information it reports is whether the TCG JIT is in “one instruction per translated block” mode (which can be set on the command line or via the HMP, but not via QMP). The information remains available via the HMP ‘info jit’ command.

QEMU Machine Protocol (QMP) events

MEM_UNPLUG_ERROR?(since 6.2)

Use the more generic event?instead.DEVICE_UNPLUG_GUEST_ERROR

vcpu?trace events (since 8.1)

The ability to instrument QEMU helper functions with vCPU-aware trace points was removed in 7.0. However QMP still exposed the vcpu parameter. This argument has now been deprecated and the remaining remaining trace points that used it are selected just by name.

Human Monitor Protocol (HMP) commands

singlestep?(since 8.1)

The?command has been replaced by the?command, which has the same behaviour but a less misleading name.singlestepone-insn-per-tb

Host Architectures

BE MIPS (since 7.2)

As Debian 10 (“Buster”) moved into LTS the big endian 32 bit version of MIPS moved out of support making it hard to maintain our cross-compilation CI tests of the architecture. As we no longer have CI coverage support may bitrot away before the deprecation process completes. The little endian variants of MIPS (both 32 and 64 bit) are still a supported host architecture.

System emulation on 32-bit x86 hosts (since 8.0)

Support for 32-bit x86 host deployments is increasingly uncommon in mainstream OS distributions given the widespread availability of 64-bit x86 hardware. The QEMU project no longer considers 32-bit x86 support for system emulation to be an effective use of its limited resources, and thus intends to discontinue it. Since all recent x86 hardware from the past >10 years is capable of the 64-bit x86 extensions, a corresponding 64-bit OS should be used instead.

System emulator machines

Arm?machine?property (since 7.1)virtdtb-kaslr-seed

The?property on the?board has been deprecated; use the new name?instead. The new name better reflects the way this property affects all random data within the device tree blob, not just the?node.dtb-kaslr-seedvirtdtb-randomnesskaslr-seed

pc-i440fx-1.4?up to?(since 7.0)pc-i440fx-1.7

These old machine types are quite neglected nowadays and thus might have various pitfalls with regards to live migration. Use a newer machine type instead.

Backend options

Using non-persistent backing file with pmem=on (since 6.1)

This option is used when?is consumed by emulated NVDIMM device. However enabling?option, when backing file is (a) not DAX capable or (b) not on a filesystem that support direct mapping of persistent memory, is not safe and may lead to data loss or corruption in case of host crash. Options are:memory-backend-filememory-backend-file.pmem

• modify VM configuration to set?to continue using fake NVDIMM (without persistence guaranties) with backing file on non DAX storagepmem=off

• move backing file to NVDIMM storage and keep?(to have NVDIMM with persistence guaranties).pmem=on

Device options

Emulated device options

-device?virtio-blk,scsi=on|off?(since 5.0)

The virtio-blk SCSI passthrough feature is a legacy VIRTIO feature. VIRTIO 1.0 and later do not support it because the virtio-scsi device was introduced for full SCSI support. Use virtio-scsi instead when SCSI passthrough is required.

Note this also applies to?, which is an alias.-device?virtio-blk-pci,scsi=on|off

-device?nvme-ns,eui64-default=on|off?(since 7.1)

In QEMU versions 6.1, 6.2 and 7.0, the?generates an EUI-64 identifier that is not globally unique. If an EUI-64 identifier is required, the user must set it explicitly using the?device parameter?.nvme-nsnvme-nseui64

-device?nvme,use-intel-id=on|off?(since 7.1)

The?device originally used a PCI Vendor/Device Identifier combination from Intel that was not properly allocated. Since version 5.2, the controller has used a properly allocated identifier. Deprecate the?machine compatibility parameter.nvmeuse-intel-id

-device?cxl-type3,memdev=xxxx?(since 8.0)

The?device initially only used a single memory backend. With the addition of volatile memory support, it is now necessary to distinguish between persistent and volatile memory backends. As such, memdev is deprecated in favor of persistent-memdev.cxl-type3

-fsdev?proxy?and?(since 8.1)-virtfs?proxy

The 9p?filesystem backend driver has been deprecated and will be removed (along with its proxy helper daemon) in a future version of QEMU. Please use?or?for using the 9p?filesystem backend, or alternatively consider deploying virtiofsd instead.proxy-fsdev?local-virtfs?locallocal

The 9p?backend was originally developed as an alternative to the 9p?backend. The idea was to enhance security by dispatching actual low level filesystem operations from 9p server (QEMU process) over to a separate process (the virtfs-proxy-helper binary). However this alternative never gained momentum. The proxy backend is much slower than the local backend, hasn’t seen any development in years, and showed to be less secure, especially due to the fact that its helper daemon must be run as root, whereas with the local backend QEMU is typically run as unprivileged user and allows to tighten behaviour by mapping permissions et al by using its ‘mapped’ security model option.proxylocal

Nowadays it would make sense to reimplement the?backend by using QEMU’s?feature, which would eliminate the high latency costs under which the 9p?backend currently suffers. However as of to date nobody has indicated plans for such kind of reimplementation unfortunately.proxyvhostproxy

Block device options

"backing":?""?(since 2.12)

In order to prevent QEMU from automatically opening an image’s backing chain, use?instead."backing":?null

rbd?keyvalue pair encoded filenames:?(since 3.1)""

Options for?should be specified according to its runtime options, like other block drivers. Legacy parsing of keyvalue pair encoded filenames is useful to open images with the old format for backing files; These image files should be updated to use the current format.rbd

Example of legacy encoding:

json:{"file.driver":"rbd", "file.filename":"rbd:rbd/name"}

以上，轉(zhuǎn)換為當(dāng)前支持的格式：

json:{"file.driver":"rbd", "file.pool":"rbd", "file.image":"name"}

iscsi,password=xxx（自 8.0 起）

使用該選項(xiàng)在命令行上以純文本形式指定 iSCSI 密碼是不安全的。該選項(xiàng)應(yīng)為 改為，用于引用提供 通過文件或加密的密碼。passwordpassword-secret--object?secret...

向后兼容性

CPU 型號(hào)的可運(yùn)行性保證（從 4.1 開始）

以前版本的 QEMU 從未更改過現(xiàn)有的 CPU 型號(hào) 引入其他主機(jī)軟件或硬件的方式 對(duì) VM 的要求。這允許管理軟件 安全地更改現(xiàn)有 VM 的計(jì)算機(jī)類型，而無需 引入新要求（“運(yùn)行性能保證”）。這 阻止更新 CPU 型號(hào)以包含 CPU 漏洞緩解，使客人容易受到攻擊 默認(rèn)配置。

CPU 型號(hào)可運(yùn)行性保證將不再適用于 現(xiàn)有 CPU 型號(hào)。需要可運(yùn)行性的管理軟件 保證必須使用 QMP 返回的字段解析 CPU 型號(hào)別名 命令。alias-ofquery-cpu-definitions

保留這些保證的同時(shí)，返回值將具有現(xiàn)有的 CPU 型號(hào)別名 指向不會(huì)破壞可運(yùn)行性保證的版本 （具體而言，這些 CPU 型號(hào)的版本 1）。未來QEMU 版本，別名將指向較新的 CPU 型號(hào)版本 根據(jù)機(jī)器類型，因此管理軟件必須 在啟動(dòng)虛擬機(jī)之前解析 CPU 型號(hào)別名。query-cpu-definitions

QEMU 客座代理

--blacklist命令行選項(xiàng)（自 7.2 起）

--blacklist已被替換為（這是一個(gè)更好的 此選項(xiàng)的措辭）。短形式仍然保留 相同，因此是應(yīng)該運(yùn)行的腳本的首選方式 QEMU 的舊版本和未來版本。--block-rpcs-b

blacklist配置文件選項(xiàng)（自 7.2 起）

配置文件選項(xiàng)已重命名為 （與相應(yīng)命令行的重命名同步 選項(xiàng)）。blacklistblock-rpcs

遷移

skipped“遷移統(tǒng)計(jì)”字段（自 8.1 起）

skipped遷移統(tǒng)計(jì)信息中的字段已被棄用。它沒有 使用了10多年。