RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 2052050 - Mark all RHEL-8 and earlier machine types as deprecated
Summary: Mark all RHEL-8 and earlier machine types as deprecated
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 9
Classification: Red Hat
Component: qemu-kvm
Version: 9.0
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: 9.0
Assignee: Cornelia Huck
QA Contact: jingzhao
URL:
Whiteboard:
Depends On:
Blocks: 2062813
TreeView+ depends on / blocked
 
Reported: 2022-02-08 15:26 UTC by Daniel Berrangé
Modified: 2022-05-17 12:32 UTC (History)
18 users (show)

Fixed In Version: qemu-kvm-6.2.0-11.el9_0.1
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
: 2062813 (view as bug list)
Environment:
Last Closed: 2022-05-17 12:25:28 UTC
Type: Bug
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Gitlab redhat/rhel/src/qemu-kvm qemu-kvm merge_requests 119 0 None None None 2022-03-03 13:40:44 UTC
Red Hat Issue Tracker RHELPLAN-111483 0 None None None 2022-02-08 15:29:28 UTC
Red Hat Product Errata RHBA-2022:2307 0 None None None 2022-05-17 12:26:07 UTC

Description Daniel Berrangé 2022-02-08 15:26:37 UTC 
Description of problem:

In RHEL-9 we provide the various pc-q35-rhel8* and pc-{q35,i440fx}-rhel7.6.0 machine types, in order to allow incoming live migration of existing VMs from previous RHEL-8 releases.  These machine types are intended to be deleted in RHEL-10 and should not be used for provisioning new VMs.  Any VMs that were incoming migrated from RHEL-8 will continue to work normally, but are considered to have a sub-optimal configuration that needs to be updated before RHEL-10. 

QEMU has support for marking machine types as deprecated. The intent of this support is to give users warning that the machine type is targetted to be deleted in a future release. We already use deprecations to warn users of other parts of QEMU that we intend to delete such as devices and CPU models and high level features like SPICE. Not all of these can be expressed at the code level, so some are only docs, but machine type deprecations can be expressed in the code.

We should be marking all the legacy rhel7/8 machine types as deprecated.

Only the rhel9.x machine types are recommended for ongoing usage, with expectation of being able to support migration to RHEL-10.

When QEMU marks a machine type as deprecated, this is exposed in libvirt in several ways

- virsh capabilities   - shows a 'deprecated' flag against each machine type

  For example:

  <guest>
    <os_type>hvm</os_type>
    <arch name='x86_64'>
      <wordsize>64</wordsize>
      <emulator>/usr/bin/qemu-system-x86_64</emulator>
      <machine maxCpus='255'>pc-i440fx-7.0</machine>
      <machine canonical='pc-i440fx-7.0' maxCpus='255'>pc</machine>
      <machine maxCpus='288'>pc-q35-5.2</machine>
      <machine maxCpus='255' deprecated='yes'>pc-i440fx-2.12</machine>
      <machine maxCpus='255' deprecated='yes'>pc-i440fx-2.0</machine>
      <machine maxCpus='1'>xenpv</machine>
      <machine maxCpus='255'>pc-i440fx-6.2</machine>
    </arch>
  </guest>


- virsh dominfo  $VM    - shows a warning that the machine is deprecated and VM is tainted

$ virsh dominfo demo
Id:             1
Name:           demo
UUID:           eadf8ef0-bf14-4c5f-9708-4a19bacf9e81
OS Type:        hvm
State:          running
CPU(s):         2
CPU time:       3.1s
Max memory:     1536000 KiB
Used memory:    1536000 KiB
Persistent:     yes
Autostart:      disable
Managed save:   no
Security model: selinux
Security DOI:   0
Security label: unconfined_u:unconfined_r:svirt_t:s0:c774,c871 (permissive)
Messages:       tainted: use of deprecated configuration settings
                deprecated configuration: machine type 'pc-q35-2.10'


- /var/log/libvirt/qemu/$VM.log  - shows a warning that the machine is deprecated

2022-02-08 15:23:49.448+0000: Domain id=1 is tainted: deprecated-config (machine type 'pc-q35-2.10')


Version-Release number of selected component (if applicable):
6.2.0-7

How reproducible:
Always

Steps to Reproduce:
1. Run 'virsh capabilities'
1. Start a VM using a rhel8.x.x machine type
2. Run 'virsh dominfo $VM'
3.

Expected results:
The capabilities should reported deprecated=yes  for rhel7/rhel8 machine types, but NOT for rhel9 machine types

The 'virsh dominfo' should report tainted config and deprecation
Comment 1 Cornelia Huck 2022-02-08 16:39:22 UTC 
(In reply to Daniel Berrangé from comment #0)
> Description of problem:
> 
> In RHEL-9 we provide the various pc-q35-rhel8* and pc-{q35,i440fx}-rhel7.6.0
> machine types, in order to allow incoming live migration of existing VMs
> from previous RHEL-8 releases.  These machine types are intended to be
> deleted in RHEL-10 and should not be used for provisioning new VMs.  Any VMs
> that were incoming migrated from RHEL-8 will continue to work normally, but
> are considered to have a sub-optimal configuration that needs to be updated
> before RHEL-10. 

Same should be done for the s390-ccw-virtio-rhel{7,8}* machine types. I don't think we have any old types for aarch64.

> - virsh dominfo  $VM    - shows a warning that the machine is deprecated and
> VM is tainted
> 
> $ virsh dominfo demo
> Id:             1
> Name:           demo
> UUID:           eadf8ef0-bf14-4c5f-9708-4a19bacf9e81
> OS Type:        hvm
> State:          running
> CPU(s):         2
> CPU time:       3.1s
> Max memory:     1536000 KiB
> Used memory:    1536000 KiB
> Persistent:     yes
> Autostart:      disable
> Managed save:   no
> Security model: selinux
> Security DOI:   0
> Security label: unconfined_u:unconfined_r:svirt_t:s0:c774,c871 (permissive)
> Messages:       tainted: use of deprecated configuration settings
>                 deprecated configuration: machine type 'pc-q35-2.10'

Does the 'tainting' have any further consequences?
Comment 2 Daniel Berrangé 2022-02-08 17:34:27 UTC 
(In reply to Cornelia Huck from comment #1)
> (In reply to Daniel Berrangé from comment #0)

> > $ virsh dominfo demo
> > Id:             1
> > Name:           demo
> > UUID:           eadf8ef0-bf14-4c5f-9708-4a19bacf9e81
> > OS Type:        hvm
> > State:          running
> > CPU(s):         2
> > CPU time:       3.1s
> > Max memory:     1536000 KiB
> > Used memory:    1536000 KiB
> > Persistent:     yes
> > Autostart:      disable
> > Managed save:   no
> > Security model: selinux
> > Security DOI:   0
> > Security label: unconfined_u:unconfined_r:svirt_t:s0:c774,c871 (permissive)
> > Messages:       tainted: use of deprecated configuration settings
> >                 deprecated configuration: machine type 'pc-q35-2.10'
> 
> Does the 'tainting' have any further consequences?

It is purely informational. There are two intended usages

- An app might display an alert against a VM to indicate to the admin that it is doing something sub-optimal
- A vendor support person receiving a ticket can see that the VM has some sub-optimal config
Comment 3 Cornelia Huck 2022-02-08 18:37:31 UTC 
(In reply to Daniel Berrangé from comment #2)
> (In reply to Cornelia Huck from comment #1)
> > (In reply to Daniel Berrangé from comment #0)
> 
> > > $ virsh dominfo demo
> > > Id:             1
> > > Name:           demo
> > > UUID:           eadf8ef0-bf14-4c5f-9708-4a19bacf9e81
> > > OS Type:        hvm
> > > State:          running
> > > CPU(s):         2
> > > CPU time:       3.1s
> > > Max memory:     1536000 KiB
> > > Used memory:    1536000 KiB
> > > Persistent:     yes
> > > Autostart:      disable
> > > Managed save:   no
> > > Security model: selinux
> > > Security DOI:   0
> > > Security label: unconfined_u:unconfined_r:svirt_t:s0:c774,c871 (permissive)
> > > Messages:       tainted: use of deprecated configuration settings
> > >                 deprecated configuration: machine type 'pc-q35-2.10'
> > 
> > Does the 'tainting' have any further consequences?
> 
> It is purely informational. There are two intended usages
> 
> - An app might display an alert against a VM to indicate to the admin that
> it is doing something sub-optimal
> - A vendor support person receiving a ticket can see that the VM has some
> sub-optimal config

Ah good, that looks like what we want here. I think this change is a good idea.
Comment 4 John Ferlan 2022-02-23 21:13:54 UTC 
Amnon - not sure who on your team ends up owning this. 

I believe it was Eduardo, but I see mst owns pc_piix.c where these are found. Whether this would need a clone for s390 is up to coordination between maintainers I guess.
Comment 5 Cornelia Huck 2022-03-03 08:52:27 UTC 
I'll give that one a go. I don't think we want an extra clone for s390x, it would only complicate things if we split that up.
Comment 11 Yanan Fu 2022-03-17 03:26:29 UTC 
QE bot(pre verify): Set 'Verified:Tested,SanityOnly' as gating/tier1 test pass.
Comment 20 errata-xmlrpc 2022-05-17 12:25:28 UTC 
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (new packages: qemu-kvm), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2022:2307
Note You need to log in before you can comment on or make changes to this bug.