Bug 2044687

Summary:	HP e910 fails to boot off virtual media
Product:	OpenShift Container Platform	Reporter:	Jacob Anders <janders>
Component:	Bare Metal Hardware Provisioning	Assignee:	Jacob Anders <janders>
Bare Metal Hardware Provisioning sub component:	ironic	QA Contact:	Amit Ugol <augol>
Status:	CLOSED NOTABUG	Docs Contact:
Severity:	medium
Priority:	unspecified	Keywords:	Triaged
Version:	4.10
Target Milestone:	---
Target Release:	4.10.0
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:	2022-01-25 10:25:39 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Jacob Anders 2022-01-25 01:53:27 UTC

Description of problem:

A particular sample of HP e910 server refuses to boot off virtual media image. Other samples of the same type seem okay. This BZ is to investigate the issue in-depth and make sure it is not more widespread as this is a strategically important hardware model.


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

4.10 nightly however is expected to happen on any OS or OS version as it is likely hardware related


How reproducible:


Steps to Reproduce:
1. Attach a vMedia image to this particular HP e910 with a Redfish request
2. Request boot off vMedia with a Redfish request (or set the BIOS boot sequence to permanent vMedia boot)
3. Request reboot

Actual results:

Server boots off the existing OS image on disk or fails to boot at all, it never boots off vMedia


Expected results:

Server boots off vMedia image.


Additional info:

The vMedia image source has been validated on another server and works well.

All requests are reporting success, just not taking effect.

Comment 2 Jacob Anders 2022-01-25 10:25:39 UTC

I've done extensive testing of this issue today and I was able to get one-off vMedia boot working on the problem e910 as well as another sample.

The original issue was likely to do with iLO being in suspected corrupt state. vMedia boot didn't work and the server was generally slow and unresponsive. iLO reset fixed that.

After the iLO reset I attempted further testing using RedFish queries and purpose-made vMedia image source. It turns out that the vMedia URL had a trailing whitespace which was breaking vMedia attachment.

In my investigation I found that on HP e910, upon setting vMedia URL, the BMC reports "Inserted": true in vMedia properties which may lead to a conclusion that the vMedia is attached correctly while in fact it may or may not be. If the URL specified is invalid, "Inserted" will be set to true but vMedia WILL NOT be connected. This was the issue in this particular case.

There may be a benefit in raising this with HP to see if vMedia state reporting could be improved so that the Inserted:true property is set when the vMedia is actually inserted (as opposed to only URL set).

Meanwhile, there is nothing left to be done in this BZ - I was able to attach vMedia image to the problem machine in the end. Given this had nothing to do with software and was a mix of misconfiguration and hardware behaviour, marking this NOTABUG.

Comment 3 Jacob Anders 2022-01-25 10:52:29 UTC

Upon a discussion with a colleague from HP I opened an upstream bug for their tracking: https://bugs.launchpad.net/proliantutils/+bug/1958976