Bug 895959 - [Tracker] provide RHEL-specific machine types in QEMU
[Tracker] provide RHEL-specific machine types in QEMU
Status: CLOSED CURRENTRELEASE
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: qemu-kvm (Show other bugs)
7.0
Unspecified Unspecified
medium Severity medium
: rc
: ---
Assigned To: Markus Armbruster
Virtualization Bugs
: FutureFeature, Tracking
Depends On: 918907 953304 954195 963280 974910 977864 980840 983991 983993 991698 994490 1004025 1004026 1004299 1005039 1011623 1011626 1015081 1015111
Blocks: 819968 841379 987757
  Show dependency treegraph
 
Reported: 2013-01-16 06:19 EST by Daniel Berrange
Modified: 2014-08-11 09:37 EDT (History)
11 users (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
: 918907 977864 983991 983993 983997 984008 984010 RHEL-MachineTypes (view as bug list)
Environment:
Last Closed: 2014-08-11 09:37:57 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Daniel Berrange 2013-01-16 06:19:30 EST
Description of problem:
Upstream QEMU currently uses machine type names like this on x86:

$ qemu-kvm  -M ?
Supported machines are:
none                 empty machine
pc                   Standard PC (alias of pc-1.2)
pc-1.2               Standard PC (default)
pc-1.1               Standard PC
pc-1.0               Standard PC
pc-0.15              Standard PC
pc-0.14              Standard PC
pc-0.13              Standard PC
pc-0.12              Standard PC
pc-0.11              Standard PC, qemu 0.11
pc-0.10              Standard PC, qemu 0.10
isapc                ISA-only PC


This is basically a machine type prefix plus a version suffix.

With recent patch from Gerd, upstream machine type name prefixes are changing to directly reflect the hardware names:

> Starting with release 1.4 we have a fully functional q35 machine type,
> i.e. "qemu -M q35" JustWorks[tm].  Update machine type names to reflect
> that:
>
>  * pc-1.4 becomes pc-i440fx-1.4
>  * q35-next becomes pc-q35-1.4
>
> The pc-1.3 (+older) names are maintained for compatibility reasons.
> For the same reason the "pc" and "q35" aliases are kept.  pc-piix-1.4
> continues to be the default machine type, again for compatibility
> reasons.
>
> Also updated the description (shown by "qemu -M ?") with host bridge
> name, south bridge name and chipset release year.

RHEL-5/6 meanwhile have historically changed both the machine type prefix and the version string:

# qemu-system-x86_64 -M ?
Supported machines are:
pc         RHEL 6.2.0 PC (alias of rhel6.2.0)
rhel6.2.0  RHEL 6.2.0 PC (default)
rhel6.1.0  RHEL 6.1.0 PC
rhel6.0.0  RHEL 6.0.0 PC
rhel5.5.0  RHEL 5.5.0 PC
rhel5.4.4  RHEL 5.4.4 PC
rhel5.4.0  RHEL 5.4.0 PC

This was always unpleasant, but it becomes much worse when we consider the possibility of having two machine types - piix and q35.

RHEL needs to have custom versions to deal with backports, but there is no reason why it should be changing the base name prefix, nor does it need to change the descriptions.

Thus for RHEL-7 we should adjust our policy so that we only change the version suffix. So come rhel-7.3 we would have ended up with something like:

 # qemu-system-x86_64 -M ?
 Supported machines are:
 pc                   Standard PC (Q35 + ICH9, 2009) (alias of  pc-q35-rhel7.3.0)
 pc-i440fx-rhel7.0.0  Standard PC (i440FX + PIIX, 1996)
 pc-i440fx-rhel7.1.0  Standard PC (i440FX + PIIX, 1996)
 pc-i440fx-rhel7.2.0  Standard PC (i440FX + PIIX, 1996)
 pc-i440fx-rhel7.3.0  Standard PC (i440FX + PIIX, 1996)
 pc-q35-rhel7.0.0     Standard PC (Q35 + ICH9, 2009)
 pc-q35-rhel7.1.0     Standard PC (Q35 + ICH9, 2009)
 pc-q35-rhel7.2.0     Standard PC (Q35 + ICH9, 2009)
 pc-q35-rhel7.3.0     Standard PC (Q35 + ICH9, 2009) (default)

Obviously the existing machine types from RHEL-5/6 will need to keep their names for sake of backwards compatibility.

This will make it mean that RHEL machine types once again clearly show what hardware they are associated with. This is also important to libvirt since it needs to look at the name prefix to figure out the default PCI bus topology. This also reduces divergence from upstream, which is always a good thing

Version-Release number of selected component (if applicable):
1.3.0-3
Comment 1 Paolo Bonzini 2013-05-24 09:52:16 EDT
The actual set of machine types would be more like this:

 pc                   Standard PC (Q35 + ICH9, 2009)
                                (alias of  pc-i440fx-rhel7.3.0)
 pc-i440fx-rhel7.0.0  Standard PC (i440FX + PIIX, 1996)
 pc-i440fx-rhel7.1.0  Standard PC (i440FX + PIIX, 1996)
 pc-i440fx-rhel7.2.0  Standard PC (i440FX + PIIX, 1996)
 pc-i440fx-rhel7.3.0  Standard PC (i440FX + PIIX, 1996) (default)
 q35                  Standard PC (Q35 + ICH9, 2009)
                                (alias of  pc-q35-rhel7.3.0)
 pc-q35-rhel7.0.0     Standard PC (Q35 + ICH9, 2009)
 pc-q35-rhel7.1.0     Standard PC (Q35 + ICH9, 2009)
 pc-q35-rhel7.2.0     Standard PC (Q35 + ICH9, 2009)
 pc-q35-rhel7.3.0     Standard PC (Q35 + ICH9, 2009)
Comment 2 Paolo Bonzini 2013-05-24 09:52:36 EDT
The actual set of machine types would be more like this:

 pc                   Standard PC (i440FX + PIIX, 1996)
                                (alias of  pc-i440fx-rhel7.3.0)
 pc-i440fx-rhel7.0.0  Standard PC (i440FX + PIIX, 1996)
 pc-i440fx-rhel7.1.0  Standard PC (i440FX + PIIX, 1996)
 pc-i440fx-rhel7.2.0  Standard PC (i440FX + PIIX, 1996)
 pc-i440fx-rhel7.3.0  Standard PC (i440FX + PIIX, 1996) (default)
 q35                  Standard PC (Q35 + ICH9, 2009)
                                (alias of  pc-q35-rhel7.3.0)
 pc-q35-rhel7.0.0     Standard PC (Q35 + ICH9, 2009)
 pc-q35-rhel7.1.0     Standard PC (Q35 + ICH9, 2009)
 pc-q35-rhel7.2.0     Standard PC (Q35 + ICH9, 2009)
 pc-q35-rhel7.3.0     Standard PC (Q35 + ICH9, 2009)
Comment 3 Markus Armbruster 2013-06-05 10:24:50 EDT
Re comment#2: plus all the machine types we have in RHEL-6, correct?

pc         RHEL 6.5.0 PC (alias of rhel6.5.0)
rhel6.5.0  RHEL 6.5.0 PC (default)
rhel6.4.0  RHEL 6.4.0 PC
rhel6.3.0  RHEL 6.3.0 PC
rhel6.2.0  RHEL 6.2.0 PC
rhel6.1.0  RHEL 6.1.0 PC
rhel6.0.0  RHEL 6.0.0 PC
rhel5.5.0  RHEL 5.5.0 PC
rhel5.4.4  RHEL 5.4.4 PC
rhel5.4.0  RHEL 5.4.0 PC
Comment 5 Paolo Bonzini 2013-06-20 09:11:10 EDT
For device properties, the basic plan would be to make a list of properties from 0.12 to 1.5, minus those that were changed between 0.12 and 6.0 (the hardest part).  You can then use it to create a version of hw/i386/pc.c that has the 6.0 and 7.0 machine.  Then forward-port the 6.1-6.5 machines from RHEL6, without caring for the moment of the special init functions.

CPU properties, and special init functions, could be added on top of this work.
Comment 6 Markus Armbruster 2013-07-12 08:13:19 EDT
Let's use this bug to track the complete RHEL-specific machine type task, and create new one(s) for device backward compatibility not already covered by other bugs.

Note You need to log in before you can comment on or make changes to this bug.