Closed eslutsky closed 4 years ago
@arachmani , can you also verify its solve your deployment issue
@arachmani , can you also verify its solve your deployment issue
@eslutsky, verified.
changing the bios_type value in DB is not very good solution (only as a temp workaround), there is merged PR to the ovirt-ansible-collection, adding bios_type support for ovirt_vm module: https://github.com/oVirt/ovirt-ansible-collection/pull/15 when will be able to consume it in HE deployments tasks? @sandrobonazzola @oVirt/ovirt-infra
Hi, because it is RFE it will not be added to Ansible 2.9 and in 2.10 there will be no oVirt module in Ansible core and everything moved to the collection. The collection is not yet integrated into any role nor engine.
But if you need the parameter ASAP you can create library.
library
in roleovirt_vm
module from latest 2.9 to the folder (recommend to rename it also to something like ovirt_vm210
)Example of the library in role https://github.com/oVirt/ovirt-ansible-vm-infra/tree/ovirt-ansible-vm-infra-1.1
we don't need this PR anymore, the issue being handled from the engine side: https://gerrit.ovirt.org/#/c/109825/
@eslutsky This may still be needed. I'm running the latest code with the fix on the engine side and it's still choosing pc-i440fx-rhel7.6.0 for the machine type because vm.getEffectiveBiosType() returns the default bios type which is still "pc" not "q35". searching the ovirt-hosted-engine-setup-ansible-create_target_vm log for bios_type shows that the value is "q35_sea_bios" but that isn't making it into the effective bios type. Other values from the logs which seem to indicate that something is slipping through the cracks are:
v_supported_emulated_machines=q35,pc-i440fx-rhel7.3.0,pc,pc-i440fx-rhel7.6.0,pc-q35-rhel8.2.0,pc-q35-rhel7.5.0,pc-i440fx-rhel7.4.0,pc-q35-rhel8.1.0,pc-q35-rhel8.0.0,pc-q35-rhel7.3.0,pc-i440fx-rhel7.0.0,pc-i440fx-rhel7.1.0,pc-i440fx-rhel7.5.0,pc-q35-rhel7.6.0,pc-i440fx-rhel7.2.0,pc-q35-rhel7.4.0
v_emulated_machine=pc-i440fx-rhel7.6.0;pc-q35-rhel8.1.0, v_cpu_name=Secure Intel IvyBridge Family
Yet, when the ovf:Envelope is sent, it contains:
<CustomEmulatedMachine>pc-i440fx-rhel7.6.0</CustomEmulatedMachine><CustomCpuName>IvyBridge,+pcid,+spec-ctrl,+ssbd,+md-clear</CustomCpuName>
and the <EngineXML>
value includes
<type arch="x86_64" machine="pc-i440fx-rhel7.6.0">hvm</type>
I've tried pausing the install script and connecting to the HostedEngineLocal VM and changing all the log levels in /usr/share/ovirt-engine/services/ovirt-engine/* from INFO to DEBUG, but it just looks like there isn't enough logging in the engine within this area to get the logs to show precisely what's happening.
FYI, this is running the ovirt-node-ng-installer-4.4.1-2020062707.el8.iso master snapshot and using the ovirt-engine-appliance-4.4-20200626174650.1.el8.x86_64 package.
I confirm that this works with the latest level, pc-q35-rhel8.1.0 is chosen instead of pc-i440fx-rhel7.6.0 and the hosted engine install worked without any other errors. That said, I also agree that it feels wrong to address the problem in this way of hard-wiring the bios_type to 2 in the DB. What stumped me is why this works but adding something like this to the setup script using --config-append didn't
[environment:default]
OVEHOSTED_VM/emulatedMachine=str:q35
Hi Glenn, thank you for testing it out. The problem was in the specific code (we have a lot of those from the past) of handling HE VM's OVF, in this case it was overwriting the configured BiosType (which is q35+seabios in 4.4) and writing the wrong one which was then picked up on followup restart where the OVF is used to launch the HE.
Change hostedEngine VM bios_type to q35
Bug-Url: https://bugzilla.redhat.com/show_bug.cgi?id=1847880
Signed-off-by: Evgeny Slutsky eslutsky@redhat.com