Project

General

Profile

Actions
Copy link

Bug #5510

closed

Set network as first boot device for VMs in VMware compute resources

Added by Marco De Vitis over 10 years ago. Updated over 6 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Timo Goebel
Category:
Compute resources - VMware
Target version:
1.11.0
Difficulty:
Triaged:
Bugzilla link:
Pull request:
https://github.com/theforeman/foreman/pull/2900
Fixed in Releases:
Found in Releases:
Red Hat JIRA:

Description

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.

This would also partly satisfy this feature request: http://projects.theforeman.org/issues/4317

Related issues 4 (0 open — 4 closed)

Related to Foreman - Feature #4317: Build button - Vmware provisioning - single click rebuildResolved02/11/2014Actions
Related to Foreman - Bug #14160: VMware image-based provisioning: 'configSpec.bootOptions.bootOrder' parameter incorrectClosedChris Roberts03/11/2016Actions
Related to Foreman - Bug #26010: For the vms built using "Network Based" installation mode on VMWare, unable to change the boot sequence via BIOSClosedOndřej EzrActions
Blocked by Foreman - Refactor #12612: Update fog to 1.37.0ClosedTimo Goebel11/26/2015Actions
Actions
Copy link
 #1

Updated by Dominic Cleal over 10 years ago

  • Related to Feature #4317: Build button - Vmware provisioning - single click rebuild added
Actions
Copy link
 #2

Updated by Dominic Cleal about 10 years ago

  • Category changed from Compute resources to Compute resources - VMware
Actions
Copy link
 #3

Updated by Arnold Bechtoldt over 9 years ago

We see this issue in several of our projects. It would be great to have solution for this. A workaround would be to change the boot priority order after adding the host via hooks or sth. similar..

Actions
Copy link
 #4

Updated by The Foreman Bot about 9 years ago

  • Status changed from New to Ready For Testing
  • Assignee set to Timo Goebel
  • Pull request https://github.com/theforeman/foreman/pull/2900 added
Actions
Copy link
 #5

Updated by Timo Goebel about 9 years ago

  • Blocked by Feature #12479: Configure API revision for vSphere Compute Resource added
Actions
Copy link
 #6

Updated by Timo Goebel about 9 years ago

  • Blocked by deleted (Feature #12479: Configure API revision for vSphere Compute Resource)
Actions
Copy link
 #7

Updated by Timo Goebel about 9 years ago

Actions
Copy link
 #8

Updated by Dominic Cleal almost 9 years ago

  • Translation missing: en.field_release set to 71
Actions
Copy link
 #9

Updated by Anonymous almost 9 years ago

  • Status changed from Ready For Testing to Closed
  • % Done changed from 0 to 100
Actions
Copy link
 #10

Updated by Dominic Cleal almost 9 years ago

  • Related to Bug #14160: VMware image-based provisioning: 'configSpec.bootOptions.bootOrder' parameter incorrect added
Actions
Copy link
 #11

Updated by Marek Hulán almost 6 years ago

  • Related to Bug #26010: For the vms built using "Network Based" installation mode on VMWare, unable to change the boot sequence via BIOS added
Actions
Copy link

Also available in: Atom PDF