1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
|
===============
Boot interfaces
===============
The boot interface manages booting of both the deploy ramdisk and the user
instances on the bare metal node.
The `PXE boot`_ interface is generic and works with all hardware that supports
booting from network. Alternatively, several vendors provide *virtual media*
implementations of the boot interface. They work by pushing an ISO image to
the node's `management controller`_, and do not require either PXE or iPXE.
Check your driver documentation at :doc:`../drivers` for details.
.. _pxe-boot:
PXE boot
--------
The ``pxe`` boot interface uses PXE_ or iPXE_ to deliver the target
kernel/ramdisk pair. PXE uses relatively slow and unreliable TFTP protocol
for transfer, while iPXE uses HTTP. The downside of iPXE is that it's less
common, and usually requires bootstrapping using PXE first.
The ``pxe`` boot interface works by preparing a PXE/iPXE environment for a
node on the file system, then instructing the DHCP provider (for example,
the Networking service) to boot the node from it. See
ref:`direct-deploy-example` for a better understanding of the whole deployment
process.
.. note::
Both PXE and iPXE are configured differently, when UEFI boot is used
instead of conventional BIOS boot. This is particularly important for CPU
architectures that do not have BIOS support at all.
The ``pxe`` boot interface is used by default for many hardware types,
including ``ipmi``. Some hardware types, notably ``ilo`` and ``irmc`` have their
specific implementations of the PXE boot interface.
Additional configuration is required for this boot interface - see
:doc:`/install/configure-pxe` for details.
Common options
--------------
Enable persistent boot device for deploy/clean operation
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For (i)PXE booting, Ironic uses non-persistent boot order changes for
clean/deploy by default. For some drivers, persistent changes are far
more costly than non-persisent ones, so this approach can bring a
performance benefit.
In order to control this behavior, however, Ironic provides the
``force_persistent_boot_device`` flag in the node's ``driver_info``.
It allows the values ``Default`` (make all changes but the last one
upon deployment non-persistent), ``Always`` (make all changes persistent),
and ``Never`` (make all boot order changes non-persistent). For example
in order to have only persistent changes one would need to set something
like::
$ openstack baremetal node set --driver-info force_persistent_boot_device='Always' <node>
.. note::
It is recommended to check if the node's state has not changed as there
is no way of locking the node between these commands.
.. note::
The values 'True'/'False' for the option 'force_persistent_boot_device'
in the node's driver info for the (i)PXE drivers are deprecated and
support for them may be removed in a future release. The former default
value 'False' is replaced by the new value 'Default', the value 'True'
is replaced by 'Always'.
.. _PXE: https://en.wikipedia.org/wiki/Preboot_Execution_Environment
.. _iPXE: https://en.wikipedia.org/wiki/IPXE
.. _management controller: https://en.wikipedia.org/wiki/Out-of-band_management
|
