Foreman, fog-vsphere, vCenter 6.0 how to avoid locking boot order

Hi,

this is a rather scattered issue with creating VMware virtual machiens
via Foreman and fog-vsphere.

The problem is that any VM that has been created from Foreman has its
Boot Order locked which in turn cannot be changed from the VMs BIOS
afterwards. The process of reversing this on the VMware side is rather
clunky and involves shutting down affected VMs, unregistering them
from vCenter and manually editing the .vmx file before reversing all
those steps.

The VMware people on site tell me that this is caused by the fact that
"foreman" (they mean the system foreman runs on) tells their vSphere
system to add the values bios.hddOrder = "scsi0:0, scsi0:1" and
bios.bootOrder = "cdrom,hdd" to the vmx file. VMware then locks the
boot order to what is in the VMX file.

Since the toolchain from Foreman goes via the foreman-vmware provider
which in turn uses fog-vsphere which in turn talks to the vCenter
server is rather long, I would like to ask whether anyone knows
whether one has a possibility to influence this process. Additionally,
is it possible in VMware to set the initial boot order of a VM created
via API without locking the VM to this boot order for all eternity.

Any thoughts, ideas or experiences about this?

Greetings
Marc

··· -- ----------------------------------------------------------------------------- Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany | lose things." Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421

It is a known "issue" and i state "issue" as this is an expected behavior,
If you provision a VM from Foreman it means you wish to control the whole
life cycle of this VM, It acts the same as physical server.
The boot order is set to first boot from network (PXE/etc…) after it
finishes the installation it goes through the same steps as if it were a
physical servers (set the pxelinux to boot from disk by default, etc…).

I do think perhaps it will be better to revert back the boot options to
default (e.g. first hdd, etc…) and when rebuilding the VM set the network
as the first boot device.

··· On Thursday, October 6, 2016 at 8:52:53 AM UTC+3, Marc Haber wrote: > > Hi, > > this is a rather scattered issue with creating VMware virtual machiens > via Foreman and fog-vsphere. > > The problem is that any VM that has been created from Foreman has its > Boot Order locked which in turn cannot be changed from the VMs BIOS > afterwards. The process of reversing this on the VMware side is rather > clunky and involves shutting down affected VMs, unregistering them > from vCenter and manually editing the .vmx file before reversing all > those steps. > > The VMware people on site tell me that this is caused by the fact that > "foreman" (they mean the system foreman runs on) tells their vSphere > system to add the values bios.hddOrder = "scsi0:0, scsi0:1" and > bios.bootOrder = "cdrom,hdd" to the vmx file. VMware then locks the > boot order to what is in the VMX file. > > Since the toolchain from Foreman goes via the foreman-vmware provider > which in turn uses fog-vsphere which in turn talks to the vCenter > server is rather long, I would like to ask whether anyone knows > whether one has a possibility to influence this process. Additionally, > is it possible in VMware to set the initial boot order of a VM created > via API without locking the VM to this boot order for all eternity. > > Any thoughts, ideas or experiences about this? > > Greetings > Marc > > -- > ----------------------------------------------------------------------------- > > Marc Haber | "I don't trust Computers. They | Mailadresse im > Header > Leimen, Germany | lose things." Winona Ryder | Fon: *49 6224 > 1600402 > Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 > 1600421 >

Hi,

> It is a known "issue" and i state "issue" as this is an expected behavior,
> If you provision a VM from Foreman it means you wish to control the whole
> life cycle of this VM, It acts the same as physical server.

I disagree here.

With a physical server, Foreman does not lock my boot order down to
whatever foreman found helpful during provisioning. How would I tell a
Vm to "now please boot this rescue system from this CD image" from
Foreman?

> The boot order is set to first boot from network (PXE/etc…) after it
> finishes the installation it goes through the same steps as if it were a
> physical servers (set the pxelinux to boot from disk by default, etc…).
>
> I do think perhaps it will be better to revert back the boot options to
> default (e.g. first hdd, etc…) and when rebuilding the VM set the network
> as the first boot device.

Everything is fine for me as long as I have the freedom to change
these settings after the system was installed. Not being able to boot
the VM into a rescue system is a severe nuisance and confuses the
colleagues who are not this deep into the technical stuff.

Greetings
Marc

··· On Wed, Oct 05, 2016 at 11:20:24PM -0700, Erez Zarum wrote:

Marc Haber | “I don’t trust Computers. They | Mailadresse im Header
Leimen, Germany | lose things.” Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421

I know it’s an old thread but this is very annoying when we need to involve IT Systems to change the vmx file of each VM.