Bug 1581417 - [RFE] Use Q35 as the default machine type
Summary: [RFE] Use Q35 as the default machine type
Alias: None
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: vdsm
Version: unspecified
Hardware: Unspecified
OS: Unspecified
Target Milestone: ovirt-4.4.1
: 4.4.0
Assignee: Shmuel Melamud
QA Contact: Nisim Simsolo
Depends On: 1602889 1614127
Blocks: 1517362 1527843
TreeView+ depends on / blocked
Reported: 2018-05-22 17:32 UTC by Eduardo Habkost
Modified: 2020-08-04 13:27 UTC (History)
13 users (show)

Fixed In Version: rhv-4.4.0-30
Doc Type: Enhancement
Doc Text:
All new clusters with x86 architecture and compatibility version 4.4 or higher now set the BIOS Type to the Q35 Chipset by default, instead of the i440FX chipset.
Clone Of:
Last Closed: 2020-08-04 13:26:06 UTC
oVirt Team: Virt
Target Upstream Version:
lsvaty: testing_plan_complete-

Attachments (Terms of Use)

System ID Private Priority Status Summary Last Updated
Red Hat Knowledge Base (Solution) 4204531 0 Learn more None How q35 machine type is supported in RHV 2019-06-12 22:24:26 UTC
Red Hat Product Errata RHEA-2020:3246 0 None None None 2020-08-04 13:27:05 UTC
oVirt gerrit 104887 0 master MERGED update 4.4 machine types to Q35 2021-01-27 19:26:07 UTC

Description Eduardo Habkost 2018-05-22 17:32:54 UTC
We plan to change the default machine-type to "q35" in qemu-kvm-rhev, but we want to ensure no management system will break when we do that.  To do this, we need to ensure there's no code in RHV that assumes an omitted machine-type means libvirt+QEMU will always default to "pc".

If you believe RHV won't break when we change the default machine-type to "q35", please mark this bug as TestOnly.

I am filing this to the "vdsm" component because I'm not sure what's the right component for this BZ, please feel free to move it to a more appropriate component.

Comment 1 Michal Skrivanek 2018-05-23 07:24:57 UTC
We rarely assume/use a default from qemu. For machine types we use ClusterEmulatedMachines variable in vdc options, that pins the types to specific ones even on Fedora (e.g. pc-i440fx-2.6)

Comment 4 Eduardo Habkost 2018-07-18 18:18:48 UTC
I have opened bug 1602889 against libosinfo, and I'm adding it as a dependency of this bug.

If you plan to address this bug without libosinfo help first, I recommend opening a separate BZ against this component to ensure the component will eventually use libosinfo to choose the machine-type.  Please let me know if a separate BZ will be needed.

Comment 5 Michal Skrivanek 2018-07-18 20:34:48 UTC
It doesn’t use libosinfo now, and we do not have plans to use it directly in foreseeable future. We may eventually use a different library/helper to get optimal defaults hopefully in cooperation with libvirt, but still it’s unlikely we would ever change the concept of us explicitely requesting a certain machine type corresponding to our cluster level compatibility. 
It’s really just a TestOnly for us to verify it doesn’t break, but it is not directly relevant for oVirt

Comment 7 Eduardo Habkost 2018-08-03 20:33:41 UTC
Important update: I have just noticed that even when using q35, the default NIC and sound card model in libvirt are legacy PCI devices that end up requiring a legacy PCI bridge to be added to the VM: rtl8139 and ich6-hda-intel.

New action items for libosinfo and all libvirt users:
* libosinfo also needs to provide a recommendation of sound hardware
* In addition to prefer Q35 when possible, management software should prefer the 'ich9-hda-intel' sound card and 'e1000e' NIC when using Q35.

In other words, the recommendations are:

- If there's no user input about machine-type:
-- If guest OS is known, use libosinfo
-- If guest OS is unknown, prefer Q35

- If using Q35:
-- If there's no user input about NIC model:
--- If guest OS is known, use libosinfo
--- If guest OS is unknown, prefer e1000e
-- If there's no user input about sound card model:
--- If guest OS is known, use libosinfo
--- If guest OS is unknown or libosinfo has no sound card recommendation, prefer ich9

Comment 8 Eduardo Habkost 2018-08-09 03:15:39 UTC
We have one additional issue with RHEL-6 guests: they don't have drivers for virtio-1, so they need virtio devices to run in legacy mode.  So I'm extending the scope of this BZ (and related ones) again.

Full list of action items, for reference:
On libosinfo:
* libosinfo should provide a recommendation of machine-type
* libosinfo should provide a recommendation of sound hardware
* libosinfo should tell if the guest OS supports only legacy virtio and/or modern virtio

On management software:
* Management software should use libosinfo to pick default machine-type, and prefer Q35 when possible
* Management software should prefer the 'ich9-hda-intel' sound card and 'e1000e' NIC when using Q35.
* Management software should do what's necessary if guest supports only legacy virtio. Options to ensure that:
** Use "pc" machine type
** Use a libvirt flag that will force the virtio device to be in legacy mode (not available yet, I will open a BZ for this)
** Manually plug the virtio device to a legacy PCI bus (probably not feasible as it would require duplicating the libvirt PCI address allocation logic)

I'm not opening separate BZs for each item above because it's up to the maintainer of each component to decide how to track these tasks.

Comment 9 Eduardo Habkost 2018-08-15 18:20:03 UTC
I'm reviewing the Q35-related BZs to decide if they should have the FutureFeature keyword.  I'm not adding FutureFeature to this BZ because pc/pc-i440fx-* is going to be deprecated in RHEL8 and it will be a bug to use it by default.  I'm rewording the bug description to more accurately summarize what needs to change.

Comment 10 Ryan Barry 2019-01-21 14:53:43 UTC
Re-targeting to 4.3.1 since it is missing a patch, an acked blocker flag, or both

Comment 12 Ryan Barry 2019-01-23 23:35:47 UTC
Q35 is slated to be a tech preview in 4.3 GA. Settin as a default is inappropriate. Moving out...

Comment 16 Michal Skrivanek 2020-04-09 10:14:43 UTC
finally completed everywhere
A new 4.4 Cluster shall be set as Q35 with seabios

Comment 18 Nisim Simsolo 2020-07-11 07:57:37 UTC

Verification scenario:
Polarion test plan added to external trackers

Comment 23 errata-xmlrpc 2020-08-04 13:26:06 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 (RHV RHEL Host (ovirt-host) 4.4), and where to find the updated
files, follow the link below.

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


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