View File supported.x86.txt of Package qemu (Project home:lucidd:branches:Virtualization)
[qemu-x86 package document]
SLES 15 QEMU/KVM RELATED SUPPORT STATEMENTS
The QEMU based packages included with SLES 15 provide a large variety of
features, from the very latest customer requests to features of questionable
quality or value. The linux kernel includes components which contribute KVM
virtualization features as well. This document was created to assist the user
in deciding which features can be relied upon to build enterprise class
virtualization solutions. KVM based virtualization for x86 (Intel 64/AMD64),
for IBM System z (s390x), for Power8 Systems (ppc64le) and for the ARM64
architecture (AArch64) are offered at the L3 (full support) level. The bulk
of this document deals with L3 supported features and is primarily x86
centric. This document should be considered a companion to the standard
virtualization documentation delivered with the product.
KVM is implemented in linux kernel modules which enable the linux kernel to
function as an integral part of the KVM hypervisor. The hypervisor-guest
interaction is managed by QEMU through the /dev/kvm ioctl interface. The linux
host assists in the virtualization of storage, networking and display
resources as well as allowing direct hardware passthrough of PCI and USB
devices. Linux memory and cpu management features are used by QEMU/KVM to
enable guests to share those host resources as efficiently as possible.
QEMU is a primary component of KVM based virtualization. The legacy qemu-kvm
program is available for continuity with pre SLES 12 usage, including in
libvirt domain xml references. The QEMU emulator binaries qemu-system-x86_64
and qemu-system-i386 (x86 host) are now the primary programs to use to access
KVM virtualization. When using these programs, the -machine option accel=kvm
(or its alias -enable-kvm) must be specified for KVM acceleration to be
used by the guest. Although Xen uses QEMU for virtualization as well, this
document does not identify Xen supported features.
Libvirt is the preferred means of accessing QEMU/KVM functionality and is
documented elsewhere. This document focuses on the features and direct usage
of QEMU/KVM as provided by the QEMU based packages.
Major QEMU/KVM Supported Features
- KVM virtualization is accomplished by using the QEMU program in KVM
acceleration mode. KVM acceleration requires that both guest and host have
the same fundamental architecture.
- Guest images created under previous QEMU versions are supported by machine
version compatibilities built into more recent QEMU versions.
- For ease of use, the QEMU program has defaults which represent traditional
- Guest virtual machine characteristics are specified by a combination of
internal defaults, options provided on the QEMU program command-line, runtime
configurations set via the monitor interfaces and optional config files. The
runtime control of a VM is effected either through the Human Monitor
"Protocol" (HMP), or the JSON based programmatical QEMU Monitor Protocol (QMP)
interface. For QMP details, see qemu-qmp-ref man page.
Since a KVM guest runs in the context of a normal linux process, some types
of execution controls are managed with linux tools.
- Various standard vCPU types are available, along with the ability to specify
individual CPU features visible to the guest.
- QEMU incorporates a SEABIOS based system BIOS and iPXE based PXE ROMs, which
allow boot options common to physical systems, along with other features
tailored to virtualization. Various VGABIOS ROMs, also from the SEABIOS
project, are also included. A UEFI based guest boot environment is also
now possible by using the firmware provided by the qemu-ovmf-x86_64 package.
- Some QEMU messages have been localized to various languages. This is provided
by the optional qemu-lang package. Keyboard mappings for various nationalities
is also provided.
- Virtual machine lifecycle controls include startup through the system BIOS or
kernel boot, ACPI or legacy based shutdown, execution pausing, the saving and
restoring of machine state or disk state, VM migration to another host, and
miscellaneous controls available through the "monitors" mentioned above.
- Guest execution state may be "moved" in both time (save/restore) and space
(static and live migration). These migrations or save/restore operations can
take place either from certain prior SLES versioned hosts to a SLES 15 host
or between hosts of the same version. Certain other restrictions also apply.
- Security considerations include seccomp2 based sandboxing, vTPM, privileged
helpers and a security model which allows running guests as a non-root user.
- QEMU/KVM supports a wide range of operating systems within the VMs. See the
online SUSE documentation for supported OS's. Windows guests can optionally be
accelerated with QEMU/KVM provided Hyper-V hypercalls, or with paravirtual
drivers from the SUSE Virtual Machine Driver Pack. Linux includes a number of
paravirtual drivers as well.
- QEMU provides best effort reuse of existing disk images, including those with
systems installed, through geometry probing. Also disk images produced by
other popular virtualization technologies may be imported into QEMU supported
storage formats. These QEMU formats include features which exploit the
benefits of virtualization.
- Memory, cpu and disk space overcommit are possible and can be beneficial when
done responsibly. Additional management of these resources comes in the form
of memory ballooning or hotplug, host KSM, vcpu hot-add, online disk resizing,
trim, discard and hole punching.
- Guest performance is enhanced through the use of virtio devices, various disk
caching modes, network acceleration via the vhost-net kernel module, multi-
queue network transmit capabilities, host transparent huge pages (THP) and
direct hugetlb usage. Physical PCI and USB devices may also be passed through
to the guest, including SR-IOV VF's.
- The guest UI is accessable via GTK, VNC, Spice, and serial (including curses
- Guest timekeeping is supported in a variety of ways, including a paravirtual
clocksource, and options for the various guest clocks for how to handle the
timeslicing of the guest's execution on the host.
- Guest OS's interact with virtualized hardware including a choice of either
older or more recent x86 system chipsets, system devices and buses, and a
variety of common storage and networking emulated devices. SMBIOS and ACPI
table details can be customized.
- In addition to the para-virtualized devices already mentioned, other devices
and infrastructure designed to avoid virtualization "problem areas" are
available such as SPICE graphics, vmmouse emulation, tablet style pointer
interfaces and virtio based UI interfaces.
- A built-in user-mode network (SLIRP) stack is available.
- Portions of the host file system may be shared with a guest by using virtFS.
- A guest "agent" is available for SLES 15 KVM guests via the qemu-guest-agent
package. This allows some introspection and control of the guest OS
environment from the host.
QEMU/KVM Technology Previews
- Specifying and placing PCI devices on a PCI bridge allows for a greater number
- Nested VMX and SVM virtualization is possible.
- All features indicated as not being supported in this document fall under the
Technology Preview definition contained in the main product's release notes.
Noteworthy QEMU/KVM Unsupported Features
- Note that some features are unsupported simply due to lack of validation. If
an existing feature is desired, but not marked supported, let SUSE know about
- The TCG "acceleration" mode may be helpful for problem isolation, but
otherwise presents insufficient benefit and stability.
- Use of -cpu host is not supported in all host/guest configurations.
- GlusterFS integration is not enabled.
Deprecated, Superseded, Modified and Dropped Features
This website tracks feature deprecation and removal at the upstream
development level. Our qemu package inherits this community direction, but be
aware that we can and will deviate as needed. Those deviations and additional
information can be found in this section.
- When no video adapter is specified, the default used is stdvga. This differs
from the default of prior releases which was cirrus. The cirrus adapter was
considered too outdated to continue to use as the default.
- The deprecated windows drivers (win-virtio-drivers.iso) are no longer provided.
The Virtual Machine Driver Pack is the supported way to get virtio drivers for
- The use of ",boot=on" for virtio disks is no longer needed since the bios used
supports the virtio block interface directly. In fact, its usage may cause
problems, and is now considered deprecated.
- The use of "?" as a parameter to "-cpu", "-soundhw", "-device", "-M",
"-machine", "-d", and "-clock" is now considered deprecated. Use "help"
- The use of "if=scsi" as a parameter to "-drive" does not work anymore with PC
machine types, as it created an obsolete SCSI controller model.
- Passthrough of a host floppy device is now considered deprecated.
- Use of aio=native without direct cache mode also being specified (cache=none,
cache=directsync, or cache.direct=on) is no longer allowed.
- The use of image encryption in qcow and qcow2 formats is now considered
Analysis has shown it to be weak encryption, in addition to suffering from
poor design. Images can easily be converted to a non-encrypted format.
- Use of acpi, boot-opts, and smp-opts in a -readconfig config file are now
considered deprecated. In the future those names will be standardized to
acpitable, boot, and smp respectively.
- When only a partial SMP topology is provided (ie only some of sockets, cores,
threads) the derived guest ABI is not guaranteed to be equivalent in future
- These previously supported command line options are now considered deprecated:
-device ivshmem (use ivshmem-doorbell or ivshmem-plain instead)
-nodefconfig (use -no-user-config instead)
- These previously supported command line options are no longer supported:
<previously mentioned items have been moved to another category>
- These previously supported command line options are no longer recognized:
-device pc-sysfw (no longer needed)
-device pci-assign, -device kvm-pci-assign (use -device vfio-pci instead)
- Specifying a cpu feature with both "+feature/-feature" and "feature=on/off"
will now cause a warning. The current behavior for this combination where
"+feature/-feature" wins over "feature=on/off", will be changed going forward
so that "+feature" and "-feature" will be synonyms for "feature=on" and
- The previously supported blkdev-add QMP command has been flagged as lacking
and could possibly change syntax in the future.
- These previously unsupported command line options are now deprecated:
-no-kvm-irqchip (use -machine kernel_irqchip=off instead)
- The case of specified sockets, cores, and threads not matching the vcpu count
is no longer silently ignored. QEMU now requires that the topology match the
- These previously unsupported command line options are no longer recognized:
-device testdev (use -device pc-testdev instead)
-kvm-shadow-memory (use -machine kvm_shadow_mem= instead)
-pcidevice (use -device vfio-pci instead)
- These previously supported monitor commands are no longer recognized:
pci_add (use device_add instead)
pci_del (use device_del instead)
- This previously unsupported QMP command is now supported under a new name:
x-input-send-event (use input-send-event instead)
- Due to the lack of migration support (mainly due to ahci interface issues)
and other unstable interface issues, earlier versions of the q35 machine type
are not supported in this release. The current q35 machine type is however now
- Due to upstream's decision to no longer fully support the qed storage format
going forward (since it really provides no benefit over qcow2 and is now no
longer actively maintained upstream), creating qed storage images is no longer
supported and it is highly discouraged to continue using existing qed images.
They should instead be converted to another supported format.
QEMU Command-Line and Monitor Syntax and Support
- The QEMU program command-line syntax is as follows:
qemu-system-i386 [options] [disk_image]
qemu-system-x86_64 [options] [disk_image]
Where 'options' are taken from the options listed below, and 'disk_image' is
the file system reference to the x86 guest's primary IDE based hard disk
image. This image as well as those used with -drive or -cdrom, may be in the
raw (no format) or qcow2 storage formats, and may be located in files within
the host filesystem, logical volumes, host physical disks, or network based
storage. Read only media may also be accessed via URL style protocol
Note that as a general rule, as new command line options are added which serve
to replace an older option or interface, you are strongly encouraged to adapt
your usage to the new option. The new option is being introduced to provide
better functionality and usability going forward. In some cases existing
problems or even bugs in older interfaces cannot be fixed due to functional
expectations, but are resolved in the newer interface or option.
This advice includes moving to the most recent machine type (eg pc-i440fx-2.11
instead of pc-i440fx-2.9) if possible.
- The following command line options are supported:
-cpu ... (all except host)
(the following are aliases of these supported devices: ahci|
-dfilter range, ...
-drive ... (if specified if=[floppy|ide|virtio] and format=[qcow2|raw] and
-net [bridge|l2tpv3|nic|none|tap|user] ... (for model= only e1000, rtl8139,
and virtio are supported)
-netdev [bridge|tap|user] ...
-numa cpu ...
-numa dist ...
-tpmdev passthrough ...
- The following monitor commands are supported:
- The following QMP commands are supported:
- The following command line options are unsupported:
(the following are aliases of these unsupported devices: lsi|
(note that some of these device names represent supported devices and
are used internally, but are not specifyable via -device even though
they appear in the list of devices)
-drive ,if=[scsi|mtd|pflash], snapshot=on, format=[anything besides qcow2 or
-net [dump|socket|vde] ...
-netdev [dump|hubport|l2tpv3|socket|vde] ...
-numa node ...
-tpmdev emulator ...
- The following monitor commands are unsupported:
nbd server_start ...
- The following QMP commands are unsupported: