Bug 2023919

Summary: Hosted-engine deploy failure with 4.4.9 and centos 8 stream
Product: [oVirt] ovirt-hosted-engine-setup Reporter: Darrell <budic>
Component: GeneralAssignee: Asaf Rachmani <arachman>
Status: CLOSED DUPLICATE QA Contact: meital avital <mavital>
Severity: high Docs Contact:
Priority: unspecified    
Version: 2.5.4CC: bugs, didi, stirabos
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2021-11-22 10:57:19 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: Integration RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
engine install logs
none
log of Q35-bios VM from libvirt none

Description Darrell 2021-11-16 19:03:37 UTC 
Created attachment 1842148 [details]
engine install logs

Description of problem: A hosted-engine --deploy from the shell runs through through the whole installation process, with or without --restore-from-file for a  backup, but the new engine VM failed to start after being copied into the new hosted storage (iscsi in this case). The file appears to be a valid VM. It's strange in that the VM just won't start, no errors, QEMU-kvm appears to be running, but the console just says "the vm has not initialized the display" (may not be verbatim, from memory). I've tried this like 8 times in the last week, same thing every time.


Version-Release number of selected component (if applicable):


How reproducible:
100%

Steps to Reproduce:
1. Install new Centos 8 Stream system from web (~November 7th-16)
2. Follow https://www.ovirt.org/documentation/installing_ovirt_as_a_self-hosted_engine_using_the_command_line/index.html to install/update an existing system.


Actual results:
After completing the copy of the engine vm to new Hosted Engine storage, it attempts to start it. QEMU starts running a VM, but it never boots and console gives message about uninitialized display.

Expected results:
New Engine VM boots and is accessible, install completes.

Additional info:
Everything works fine up until that last copy. Will attach logs.
Comment 1 Sandro Bonazzola 2021-11-17 07:34:17 UTC 
Can you please provide a sos report from the host? `sosreport --all-logs`
If it's too big for attaching to bugzilla you can upload in some file sharing service like dropbox.
Comment 2 RHEL Program Management 2021-11-17 07:34:24 UTC 
The documentation text flag should only be set after 'doc text' field is provided. Please provide the documentation text and set the flag to '?' again.
Comment 3 Darrell 2021-11-17 16:43:55 UTC 
Unfortunately I had to reformat the system and just use a stand alone engine due to some timelines here. It's no longer in the same state as the failed installs. Is the sosreport still useful? It is still running centos 8 stream if it's environmental data you're looking for.
Comment 4 Darrell 2021-11-18 20:49:59 UTC 
This may be more general than the upgrade case. After installing a stand alone engine and restoring my old 4.3 backup to it, I completed the upgrades and moved the cluster to compatibility 4.6. All my old VMs continue to run and have converted to the new compatibility mode as expected. New VMs created with type "Q35 Chipset with BIOS", however, fail to boot and do the same sort of 'hang' with the console displaying a failure to initialize the display. If I switch the VM to "Q35 Chipset with UEFI", it boots as expected. I440FX Chipset boots normally as well.

Did something from my upgrade screwup the VM config for the BIOS type and where would I look for info on it?

Attaching a log of a VM that attempts to boot but never goes anywhere. Terminated by power off at the end of the log.
Comment 5 Darrell 2021-11-18 20:50:52 UTC 
Created attachment 1842637 [details]
log of Q35-bios VM from libvirt
Comment 6 Darrell 2021-11-19 19:40:57 UTC 
I see this is probably caused by https://bugzilla.redhat.com/show_bug.cgi?id=2024605
Comment 7 Yedidyah Bar David 2021-11-22 10:57:19 UTC 
(In reply to Darrell from comment #6)
> I see this is probably caused by
> https://bugzilla.redhat.com/show_bug.cgi?id=2024605

Seems so, closing as duplicate. Thanks for the report!

*** This bug has been marked as a duplicate of bug 2024605 ***