Description of problem:
The setting which hardcodes PXE (network) boot as first choise, is problematic for us for several reasons
1. the only way to change it, is to edit the VMs vmx-file while the server is powered off (it is not even possible to change it in the virtual bois of the vm)
2. we use use image bases installations due to not having dhcp available on the client subnets, and we never use PXE
3. when we get PXE first on all new hosts, we get a delay in the boot process while the PXE boot times out
4. if for some reason a server on the subnet should start to answer PXE requests, we might have one or more servers reinstalled unintentionally

We would like to have the boot order configurable, and also be able to have a blank/null value which uses the default from VMWare.

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

How reproducible:
100%

Steps to Reproduce:
1. Create a new host with VMware compute resource
2.
3.

Actual results:
Network is in first boot order

Expected results:
Be able to choose which boot order will be used

Additional info:
I think this is caused by the following code:

/usr/share/foreman/app/models/compute_resources/foreman/model/vmware.rb
~~~
...
   def vm_instance_defaults
      super.merge(
        :memory_mb  => 768,
        :interfaces => [new_interface],
        :volumes    => [new_volume],
        :scsi_controller => { :type => scsi_controller_default_type },
        :datacenter => datacenter,
        :boot_order => ['network', 'disk'],
~~~


Reason why there is network as primary for boot_order is for rebuilding:

When creating a virtual machine via Foreman on a VMware compute resource (ESX), the boot order of the VM has the hard disk as first boot device and network as last boot device.
This works for the first VM build because there's nothing on the VM HDD, but when you try to rebuild the VM the PXE image is never loaded from the network because the installed OS is booted first from HDD.
Somehow the default boot order should have network set as the first boot device, just like it happens for other compute resource types, e.g. libvirt/KVM.

So in your case you could modify the boot_order if you are not rebuilding the machines this would be valid.
If we would do something as a one time only network for primary boot_order we would have the same issue when trying to rebuild the VM.