Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 1839598

Summary:	Cluster CPU Type "Secure AMD EPYC" results in unbootable VM OS
Product:	[oVirt] ovirt-engine	Reporter:	Stephen Panicho <s.panicho>
Component:	General	Assignee:	bugs <bugs>
Status:	CLOSED CURRENTRELEASE	QA Contact:	Lucie Leistnerova <lleistne>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	4.4.0.3	CC:	bugs, godas, michal.skrivanek, sgratch, s.panicho
Target Milestone:	---	Keywords:	Triaged
Target Release:	---	Flags:	s.panicho: needinfo-
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2020-09-07 06:48:14 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	Gluster	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Stephen Panicho 2020-05-25 00:22:38 UTC

Description of problem:
My default cluster type was sutomatically selected as "Secure AMD EPYC". I started a VM with an attached CentOS 8 ISO and the install completed successfully. However, when rebooting after the install, I'm met with "error: invalid arch independent ELF magic" and then drop to the grub rescue shell.

A similar issue occurs (minus the complaint about ELF magic) if I try to boot a cloud image from the ovirt-image-repository storage domain.

To resolve this, I need to go into the VM's settings, then:
System -> Advanced Parameters -> Custom CPU
and change the value from "Secure AMD EPYC" to "EPYC,+ibpb,+virt-ssbd"

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

How reproducible:
Always

Steps to Reproduce:
1. Have a default Cluster CPU Type of "Secure AMD EPYC"
2. Start a VM and watch it not get past bios/grub
3. Override CPU Type to "EPYC,+ibpb,+virt-ssbd"
4. VM boots into OS as expected.

Additional info:
As far as I can tell, these are the same CPU types, just with different names.
https://github.com/oVirt/ovirt-engine/blob/ovirt-engine-4.4.0.3/packaging/dbscripts/upgrade/pre_upgrade/0000_config.sql#L430
https://github.com/oVirt/ovirt-engine/blob/ovirt-engine-4.4.0.3/packaging/dbscripts/upgrade/pre_upgrade/0000_config.sql#L460

Comment 1 Stephen Panicho 2020-05-25 17:17:28 UTC

Sorry, I believe I misdiagnosed the root cause of this issue. There's something going on with disk images on my HC Gluster domain (strangely the Hosted Engine isn't affected).

Rarely the VM will actually come up, sometimes it reports "not a bootable disk", sometimes "invalid arch independent ELF magic", sometimes "not a correct xfs inode". If I migrate the very same disk image to an NFS domain, it boots every time.

Comment 2 Michal Skrivanek 2020-06-08 12:06:47 UTC

ok. well, we will keep it open for a while in case you have some additional information, otherwise I don't see anything to do here, assuming the AMD thing mentioned in the original comment is not really a problem

Comment 3 RHEL Program Management 2020-06-08 12:06:54 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 4 Gobinda Das 2020-08-25 10:22:00 UTC

What version of gluster used and are you using centos based deployment or ovirt-ng-node?

Comment 5 Stephen Panicho 2020-09-04 02:25:47 UTC

(In reply to Gobinda Das from comment #4)
> What version of gluster used and are you using centos based deployment or
> ovirt-ng-node?

This was on a CentOS 8.1 machine running oVirt 4.4.0, which I believe uses Gluster 7. It's whatever was pulled in by vdsm-gluster at the time. Unfortunately, I have moved to a different setup since encountering this issue so I'm unable to provide further details.

Comment 6 Gobinda Das 2020-09-07 06:48:14 UTC

We had issue earlier and fixed in gluster-7.7 and greater.
Please upgrade gluster to 7.7 or higher and try.
Ref patch: https://github.com/gluster/glusterfs/issues/1243 
For now I am closing this bug, please feel free to reopen after upgrade if you hit any issue.