Bug 1398317 - For the vms built by Satellite 6 using "Network Based" installation mode on VMWare, unable to change the boot sequence via BIOS
Summary: For the vms built by Satellite 6 using "Network Based" installation mode on V...
Keywords:
Status: POST
Alias: None
Product: Red Hat Satellite 6
Classification: Red Hat
Component: Compute Resources - VMWare
Version: 6.2.4
Hardware: x86_64
OS: Linux
high
medium with 2 votes vote
Target Milestone: 6.8.0
Assignee: Ondřej Ezr
QA Contact: Lukáš Hellebrandt
URL:
Whiteboard:
: 1382030 1570550 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-11-24 12:41 UTC by Ashish Humbe
Modified: 2020-03-30 14:14 UTC (History)
28 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed:
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Foreman Issue Tracker 26010 Normal Closed For the vms built using "Network Based" installation mode on VMWare, unable to change the boot sequence via BIOS 2020-03-26 20:55:08 UTC
Red Hat Knowledge Base (Solution) 2773751 None None None 2017-07-31 19:19:11 UTC
Red Hat Knowledge Base (Solution) 3421061 None None None 2018-05-01 15:00:39 UTC

Description Ashish Humbe 2016-11-24 12:41:24 UTC
Description of problem:
When we deploy a new vm on VMWare from Satellite v 6 with Network Based installation mode, then the vm always boot from the network. As the boot sequence set is network, disk. 

The customer do not have DHCP/PXE in the network so they are using host based iso to install a vm. Once the installation is completed after reboot every time the vm search for DHCP and it fails. This is causing delay in booting vm.  

This issue is not seen if we build a vm with "Image Based" provisioning option from satellite v 6. 


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

How reproducible:
Always 

Steps to Reproduce:
1. Build a system from satellite v 6 with Network Based installation mode.
2. Go to BIOS for the vm and try to change the boot sequence. 
3.

Actual results:
It is not allowed to change the boot sequence. 

Expected results:
As the customer is installing ISO to complete the installation there should be an option to change the boot order for the vms. 

Additional info:

Comment 5 Ashish Humbe 2016-11-28 07:45:53 UTC
(In reply to Ohad Levy from comment #4)
> does this workaround apply?
> https://kb.vmware.com/selfservice/microsites/search.
> do?language=en_US&cmd=displayKC&externalId=2011654

Tried this workaround but that did not help.

Comment 15 hprakash 2017-03-29 11:23:37 UTC
Any update on this? cu seems to be in haste..

Comment 16 pm-sat@redhat.com 2017-04-05 08:08:02 UTC
Upstream bug assigned to chrobert@redhat.com

Comment 17 pm-sat@redhat.com 2017-04-05 08:08:07 UTC
Upstream bug assigned to chrobert@redhat.com

Comment 19 Chris Roberts 2017-05-16 22:00:08 UTC
*** Bug 1382030 has been marked as a duplicate of this bug. ***

Comment 23 Chris Roberts 2017-07-31 19:19:12 UTC
*** Bug 1385387 has been marked as a duplicate of this bug. ***

Comment 25 pm-sat@redhat.com 2017-08-07 16:07:56 UTC
Moving this bug to POST for triage into Satellite 6 since the upstream issue http://projects.theforeman.org/issues/14160 has been resolved.

Comment 29 pm-sat@redhat.com 2017-09-13 02:08:15 UTC
Moving this bug to POST for triage into Satellite 6 since the upstream issue http://projects.theforeman.org/issues/14160 has been resolved.

Comment 31 pm-sat@redhat.com 2017-09-21 22:08:19 UTC
Upstream bug assigned to chrobert@redhat.com

Comment 32 pm-sat@redhat.com 2017-09-21 22:08:26 UTC
Moving this bug to POST for triage into Satellite 6 since the upstream issue http://projects.theforeman.org/issues/14160 has been resolved.

Comment 35 Brad Buckingham 2018-05-01 15:00:39 UTC
*** Bug 1570550 has been marked as a duplicate of this bug. ***

Comment 36 sandeep mutkule 2018-05-22 06:37:54 UTC
Any updates on this?

Comment 39 Klaas Demter 2018-08-17 23:16:28 UTC
If I recall correctly at the heart of this issue is a VMware bug/feature, not actually a problem in foreman. Once you set bootorder you can not delete disks/network interfaces anymore or modify the bootorder in BIOS.

Comment 43 Emil 2018-11-07 11:42:39 UTC
(In reply to Klaas Demter from comment #39)
> If I recall correctly at the heart of this issue is a VMware bug/feature,
> not actually a problem in foreman. Once you set bootorder you can not delete
> disks/network interfaces anymore or modify the bootorder in BIOS.

It is a problem in Foreman because you cannot change this by setting. You have to edit the vmware.rb file for this to work correctly for customers using "Network Based" installation mode on VMWare.

Comment 46 Marek Hulan 2019-02-07 13:19:13 UTC
So could someone confirm, that allowing change of boot order during host provisioning would solve the issue? IIUC once the bootorder is set, it can't be changed later in BIOS. But my understanding of the request is, customer needs to be able to disable network boot entirely.

Comment 47 Marek Hulan 2019-02-07 13:20:26 UTC
Created redmine issue https://projects.theforeman.org/issues/26010 from this bug

Comment 48 Serge Savard 2019-02-07 13:28:06 UTC
(In reply to Marek Hulan from comment #46)
> So could someone confirm, that allowing change of boot order during host
> provisioning would solve the issue? IIUC once the bootorder is set, it can't
> be changed later in BIOS. But my understanding of the request is, customer
> needs to be able to disable network boot entirely.

Hello Marek,

I can confirm that the following workaround does work :

https://access.redhat.com/solutions/3106901

It might prevent someone from rebuilding the host from Satellite. A foreman option to set the boot order would probably be a good solution.

Comment 49 Marek Hulan 2019-02-11 15:20:21 UTC
Removing the line means we don't set bootorder, that unlock editing but also causes different problem (which is why we introduced it in the first place). But if we make it configurable, people could choose disk to be the first and if my understanding is correct, that would resolve this BZ. Ashish, could you also confirm? Thanks!

Comment 50 Chris 2019-02-11 16:23:34 UTC
Comment from a customer perspective here.  There are multiple ways to set boot order in VMware (https://www.top-password.com/blog/2-methods-to-change-boot-order-of-guest-vm-in-vmware-esxi/).  The current method sets it in the vmx file which then makes it unchangeable from any other perspective.  If it could be set through the Configuration Parameters somehow, that would allow it to be changed again if needed.

Comment 52 Ashish Humbe 2019-03-12 04:15:34 UTC
(In reply to Marek Hulan from comment #49)
> Removing the line means we don't set bootorder, that unlock editing but also
> causes different problem (which is why we introduced it in the first place).
> But if we make it configurable, people could choose disk to be the first and
> if my understanding is correct, that would resolve this BZ. Ashish, could
> you also confirm? Thanks!

Hi Marek,

Yeah,  if we can make boot options configurable that would be easy and will resolve this bz. 

Thank you!

Comment 53 Bryan Kearney 2019-05-16 14:04:31 UTC
Upstream bug assigned to oezr@redhat.com

Comment 54 Francisco Peralta 2019-10-01 07:48:32 UTC
Hello,
 how is the status of this issue? Also my customer is long waiting for it and we believe an option for the boot order would be a great solution.

Thanks for letting us know,
 Cisco.

Comment 55 Ondřej Ezr 2019-10-04 13:12:56 UTC
Hi,

the solution is taking more time than expected. There are discussions in upstream to solve ordering the selections.
We are currently not able to promis any timeline.

FYI - the PR that needs to get in and is blocking this is https://github.com/theforeman/foreman/pull/6762.

Comment 57 Bryan Kearney 2020-01-15 13:04:35 UTC
Moving this bug to POST for triage into Satellite 6 since the upstream issue https://projects.theforeman.org/issues/26010 has been resolved.


Note You need to log in before you can comment on or make changes to this bug.