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.
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)
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.
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
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
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.
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.
Re-targeting to 4.3.1 since it is missing a patch, an acked blocker flag, or both
Q35 is slated to be a tech preview in 4.3 GA. Settin as a default is inappropriate. Moving out...
finally completed everywhere A new 4.4 Cluster shall be set as Q35 with seabios
Verified: ovirt-engine-4.4.1.8-0.7.el8ev vdsm-4.40.22-1.el8ev.x86_64 libvirt-daemon-6.0.0-25.module+el8.2.1+7154+47ffd890.x86_64 qemu-kvm-4.2.0-29.module+el8.2.1+7297+a825794d.x86_64 Verification scenario: Polarion test plan added to external trackers
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. https://access.redhat.com/errata/RHEA-2020:3246