Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
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.
DescriptionDaniel 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
(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?
(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
(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.
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.
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
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