Description of problem: Trying to start the hosted engine VM shows the following error on the vdsm.log: ~~~ libvirt.libvirtError: XML error: The PCI controller with index='0' must be model='pci-root' for this machine type, but model='pcie-root' was found instead ~~~ Version-Release number of selected component (if applicable): 2.4.3 How reproducible: Always (in my environment at least :)) Steps to Reproduce: 1. Try to start the hosted engine by running 'hosted-engine --vm-start' Actual results: The Hosted engine does not start Expected results: The Hosted engine starts
offline conversation clarified there were manual changes to HE VM's machine type
Reopening as the manual changes were performed through the engine API to other VMs, not the "HostedEngine". Either way, the "HostedEngine" VM properties cannot be changed by using the API.
can you please share the logs from the failed deployment at /var/log/ovirt-hosted-engine-setup/
The deployment didn't fail, this installation comes from a 4.4.0 and was upgraded to 4.4.1.3. Then I stopped the environment, the HE VM and the hypervisors. This morning when I tried to start them again, I found the described problem.
Right, but we still need the logs from original install and upgrade
I was able to fix the issue by changing "BIOS Type" on the "HostedEngine" VM from "Cluster Default (bios_type=0)" to "Q35 Chipset with Legacy BIOS (bios_type=2)" in the database with the following SQL sentence: ~~~ engine=# update vm_static set bios_type=2 where vm_name='HostedEngine'; UPDATE 1 ~~~ Then I changed the CPU number and the amount of Memory of the "HostedEngine" VM in the Administration Portal to trigger the update of the OVF_STORE. It is worth to notice that the "Default" Cluster had "Q35 Chipset with Legacy BIOS (bios_type=2)" as the default "BIOS Type" before changing the "HostedEngine" VM so it looks like "Cluster Default" setting on a VM does not mean the '"BIOS Type" configured in the cluster where the VM is located'.
Created attachment 1697973 [details] oVirt logs
I don't think it's a bug in ovirt-hosted-engine-ha but rather in ovirt-engine that generates the OVF that the former tries to use. The VM was set with bios-type=CLUSTER_DEFAULT. In OvfManager#exportVm we try to figure out the emulated machine in case of hosted-engine - and we'll get an emulated machine that corresponds to i440fx because CLUSTER_DEFAULT.getChipsetType() returns null. With [1], we'll get a valid emulated machine rather than 'pc-i440fx-rhel8.1.0' but we actually need to get an emulated machine that corresponds to the cluster's chipset. So we end up adding the q35 devices from previous run with i440fx's emulated machine. [1] https://gerrit.ovirt.org/#/c/108979/
Works for me on latest Software Version:4.4.1.7-0.3.el8ev. ovirt-hosted-engine-ha-2.4.4-1.el8ev.noarch ovirt-hosted-engine-setup-2.4.5-1.el8ev.noarch Linux 4.18.0-193.12.1.el8_2.x86_64 #1 SMP Thu Jul 2 15:48:14 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux Red Hat Enterprise Linux release 8.2 (Ootpa) Reported issue no longer exists.'hosted-engine --vm-start' works just fine.
This bugzilla is included in oVirt 4.4.1 release, published on July 8th 2020. Since the problem described in this bug report should be resolved in oVirt 4.4.1 release, it has been closed with a resolution of CURRENT RELEASE. If the solution does not work for you, please open a new bug report.