QEMU machine types and compatibility

05 Jan 2022

If you want to migrate a guest initially started on an older QEMU version to a newer version of QEMU, you need to make sure that the two machines are actually compatible with each other. Once you exclude things like devices that cannot be migrated at all and make sure both QEMU invocations actually create the same virtual hardware, this basically boils down to using compatible machines.

Versioned machine types

If you simply want to create a machine without any consideration regarding migration compatibility, you will usually do something like

qemu-system-ppc64 -machine pseries (...)

This will create a machine of the pseries type. But in this case, pseries is actually an alias to the latest version of this machine type; for 6.2, this would be pseries-6.2. You can find out which machine types are versioned (and which machine types actually exist for a given binary) via -machine ?:

$ qemu-system-ppc64 -machine ?
Supported machines are:
40p                  IBM RS/6000 7020 (40p)
bamboo               bamboo
g3beige              Heathrow based PowerMAC
mac99                Mac99 based PowerMAC
mpc8544ds            mpc8544ds
none                 empty machine
pegasos2             Genesi/bPlan Pegasos II
powernv10            IBM PowerNV (Non-Virtualized) POWER10
powernv8             IBM PowerNV (Non-Virtualized) POWER8
powernv              IBM PowerNV (Non-Virtualized) POWER9 (alias of powernv9)
powernv9             IBM PowerNV (Non-Virtualized) POWER9
ppce500              generic paravirt e500 platform
pseries-2.1          pSeries Logical Partition (PAPR compliant)
pseries-2.10         pSeries Logical Partition (PAPR compliant)
pseries-2.11         pSeries Logical Partition (PAPR compliant)
pseries-2.12         pSeries Logical Partition (PAPR compliant)
pseries-2.12-sxxm    pSeries Logical Partition (PAPR compliant)
pseries-2.2          pSeries Logical Partition (PAPR compliant)
pseries-2.3          pSeries Logical Partition (PAPR compliant)
pseries-2.4          pSeries Logical Partition (PAPR compliant)
pseries-2.5          pSeries Logical Partition (PAPR compliant)
pseries-2.6          pSeries Logical Partition (PAPR compliant)
pseries-2.7          pSeries Logical Partition (PAPR compliant)
pseries-2.8          pSeries Logical Partition (PAPR compliant)
pseries-2.9          pSeries Logical Partition (PAPR compliant)
pseries-3.0          pSeries Logical Partition (PAPR compliant)
pseries-3.1          pSeries Logical Partition (PAPR compliant)
pseries-4.0          pSeries Logical Partition (PAPR compliant)
pseries-4.1          pSeries Logical Partition (PAPR compliant)
pseries-4.2          pSeries Logical Partition (PAPR compliant)
pseries-5.0          pSeries Logical Partition (PAPR compliant)
pseries-5.1          pSeries Logical Partition (PAPR compliant)
pseries-5.2          pSeries Logical Partition (PAPR compliant)
pseries-6.0          pSeries Logical Partition (PAPR compliant)
pseries-6.1          pSeries Logical Partition (PAPR compliant)
pseries              pSeries Logical Partition (PAPR compliant) (alias of pseries-6.2)
pseries-6.2          pSeries Logical Partition (PAPR compliant) (default)
ref405ep             ref405ep
sam460ex             aCube Sam460ex
taihu                taihu
virtex-ml507         Xilinx Virtex ML507 reference design

As you can see, there are various pseries-x.y machine types for older versions; these are designed to present a configuration that is compatible with a default machine that was created with an older QEMU version. For example, if you wanted to migrate a guest running on a pseries machine that was created using QEMU 5.1, the receiving QEMU would need to be started with

qemu-system-ppc64 -machine pseries-5.1 (...)

Supported machine types

Note: the following applies to upstream QEMU. Distributions may support different versioned machine types in their builds.

This list is as of QEMU 6.2; new versioned machine types may be added in the future, and sometimes old ones deprecated and removed. The machine types for the next QEMU release are usually introduced early in the release cycle (at least, that is the goal…)

arm, aarch64

The virt machine type supports versions since 2.6.

m68k

The virt machine type supports versions since 6.0.

ppc64

The pseries machine type supports versions since 2.1.

s390x

The s390-ccw-virtio machine type supports versions since 2.4.

i386, x86_64

The pc-i440fx machine type supports versions since 1.4 (there used to be even older ones, but they have been removed), while the pc-q35 machine type supports versions since 2.4.

There’s an additional thing to consider here: the pc machine type alias points (as of QEMU 6.2) to the latest pc-i440fx machine type; if you want the latest pc-q35 machine type instead, you have to use q35.

How to use this

If you want to simply fire up a QEMU instance and shut it down again without wanting to migrate it anywhere, you can stick to the default machine type. However, if you might want to migrate the machine later, it is probably a good idea to specify a versioned machine type explicitly, so that you don’t have to remember which QEMU version you started it with.

Or just use management software like libvirt, which will do the machine type expansion to the latest version for you automatically, so you don’t have to worry about it later.

This concludes the usage part of compatible machine types; a follow-up post will look at how this is actually implemented.

Related Posts