Bug 1398317
| Summary: | For the vms built by Satellite 6 using "Network Based" installation mode on VMWare, unable to change the boot sequence via BIOS | ||
|---|---|---|---|
| Product: | Red Hat Satellite | Reporter: | Ashish Humbe <ahumbe> |
| Component: | Compute Resources - VMWare | Assignee: | Ondřej Ezr <oezr> |
| Status: | CLOSED ERRATA | QA Contact: | Radek Mynar <rmynar> |
| Severity: | medium | Docs Contact: | |
| Priority: | high | ||
| Version: | 6.2.4 | CC: | ahumbe, akarimi, bkearney, chris.snell, chrobert, cmarinea, dconsoli, dyuen, egolov, ehelms, emil.sylvio.golinelli, fperalta, jcallaha, kdixon, klaas, kmcdowell, ktordeur, kurathod, lhellebr, mhulan, mlele, oezr, ohadlevy, pmutha, rmynar, satellite6-bugs, serge.savard, smutkule, yferszt, zhunting |
| Target Milestone: | 6.8.0 | Keywords: | PrioBumpGSS, PrioBumpPM, PrioBumpQA, Triaged |
| Target Release: | Unused | ||
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | foreman-2.0.0 | Doc Type: | If docs needed, set a value |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2020-10-27 12:57:17 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
Ashish Humbe
2016-11-24 12:41:24 UTC
does this workaround apply? https://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2011654 (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. Any update on this? cu seems to be in haste.. Upstream bug assigned to chrobert Upstream bug assigned to chrobert *** Bug 1382030 has been marked as a duplicate of this bug. *** *** Bug 1385387 has been marked as a duplicate of this bug. *** Moving this bug to POST for triage into Satellite 6 since the upstream issue http://projects.theforeman.org/issues/14160 has been resolved. Moving this bug to POST for triage into Satellite 6 since the upstream issue http://projects.theforeman.org/issues/14160 has been resolved. Upstream bug assigned to chrobert Moving this bug to POST for triage into Satellite 6 since the upstream issue http://projects.theforeman.org/issues/14160 has been resolved. *** Bug 1570550 has been marked as a duplicate of this bug. *** Any updates on this? 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. (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. 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. Created redmine issue https://projects.theforeman.org/issues/26010 from this bug (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. 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 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. (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! Upstream bug assigned to oezr 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. 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. Moving this bug to POST for triage into Satellite 6 since the upstream issue https://projects.theforeman.org/issues/26010 has been resolved. VERIFIED with Satellite 6.8 SNAP 7.0 and vSphere 6.7.0 As discussed in previous comments the goal of this issue was to add and option to change boot order. The option is present and the boot order is correctly applied on created hosts. Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory (Important: Satellite 6.8 release), and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHSA-2020:4366 |