Advanced features¶

Local boot with partition images¶

The Bare Metal service supports local boot with partition images, meaning that after the deployment the node’s subsequent reboots won’t happen via PXE or Virtual Media. Instead, it will boot from a local boot loader installed on the disk.

It’s important to note that in order for this to work the image being deployed with Bare Metal service must contain grub2 installed within it.

Enabling the local boot is different when Bare Metal service is used with Compute service and without it. The following sections will describe both methods.

openstack baremetal node set <node-uuid> --property capabilities="boot_option:local"

nova flavor-key baremetal set capabilities:boot_option="local"

openstack baremetal node set <node-uuid> --instance-info capabilities='{"boot_option": "local"}'

Specifying the disk for deployment (root device hints)¶

The Bare Metal service supports passing hints to the deploy ramdisk about which disk it should pick for the deployment. The list of supported hints is:

• model (STRING): device identifier

• vendor (STRING): device vendor

• serial (STRING): disk serial number

• size (INT): size of the device in GiB

  Note

  A node’s ‘local_gb’ property is often set to a value 1 GiB less than the actual disk size to account for partitioning (this is how DevStack, TripleO and Ironic Inspector work, to name a few). However, in this case size should be the actual size. For example, for a 128 GiB disk local_gb will be 127, but size hint will be 128.

• wwn (STRING): unique storage identifier

• wwn_with_extension (STRING): unique storage identifier with the vendor extension appended

• wwn_vendor_extension (STRING): unique vendor storage identifier

• rotational (BOOLEAN): whether it’s a rotational device or not. This hint makes it easier to distinguish HDDs (rotational) and SSDs (not rotational) when choosing which disk Ironic should deploy the image onto.

• hctl (STRING): the SCSI address (Host, Channel, Target and Lun), e.g ‘1:0:0:0’

• name (STRING): the device name, e.g /dev/md0

  Warning

  The root device hint name should only be used for devices with constant names (e.g RAID volumes). For SATA, SCSI and IDE disk controllers this hint is not recommended because the order in which the device nodes are added in Linux is arbitrary, resulting in devices like /dev/sda and /dev/sdb switching around at boot time.

To associate one or more hints with a node, update the node’s properties with a root_device key, for example:

openstack baremetal node set <node-uuid> --property root_device='{"wwn": "0x4000cca77fc4dba1"}'

That will guarantee that Bare Metal service will pick the disk device that has the wwn equal to the specified wwn value, or fail the deployment if it can not be found.

The hints can have an operator at the beginning of the value string. If no operator is specified the default is == (for numerical values) and s== (for string values). The supported operators are:

• For numerical values:
  • = equal to or greater than. This is equivalent to >= and is supported for legacy reasons
  • == equal to
  • != not equal to
  • >= greater than or equal to
  • > greater than
  • <= less than or equal to
  • < less than
• For strings (as python comparisons):
  • s== equal to
  • s!= not equal to
  • s>= greater than or equal to
  • s> greater than
  • s<= less than or equal to
  • s< less than
  • <in> substring
• For collections:
  • <all-in> all elements contained in collection
  • <or> find one of these

Examples are:

• Finding a disk larger or equal to 60 GiB and non-rotational (SSD):

  openstack baremetal node set <node-uuid> --property root_device='{"size": ">= 60", "rotational": false}'
  

• Finding a disk whose vendor is samsung or winsys:

  openstack baremetal node set <node-uuid> --property root_device='{"vendor": "<or> samsung <or> winsys"}'
  

Appending kernel parameters to boot instances¶

The Bare Metal service supports passing custom kernel parameters to boot instances to fit users’ requirements. The way to append the kernel parameters is depending on how to boot instances.

#!/usr/bin/env python
import os

# Default grub2 config file in Ubuntu
grub_file = '/etc/default/grub'
# Add parameters here to pass to instance.
kernel_parameters = ['quiet', 'splash']
grub_cmd = 'GRUB_CMDLINE_LINUX'
old_grub_file = grub_file+'~'
os.rename(grub_file, old_grub_file)
cmdline_existed = False
with open(grub_file, 'w') as writer, \
       open(old_grub_file, 'r') as reader:
       for line in reader:
           key = line.split('=')[0]
           if key == grub_cmd:
               #If there is already some value:
               if line.strip()[-1] == '"':
                   line = line.strip()[:-1] + ' ' + ' '.join(kernel_parameters) + '"'
               cmdline_existed = True
           writer.write(line)
       if not cmdline_existed:
           line = grub_cmd + '=' + '"' + ' '.join(kernel_parameters) + '"'
           writer.write(line)

os.remove(old_grub_file)
os.system('update-grub')
os.system('reboot')

Boot mode support¶

Some of the bare metal hardware types (namely, redfish, ilo and generic ipmi) support setting boot mode (Legacy BIOS or UEFI).

The following rules apply in order when ironic manages node boot mode:

• If the hardware type (or bare metal node) does not implement reading current boot mode of the bare metal node, then ironic assumes that boot mode is not set on the bare metal node
• If boot mode is not set on ironic node and bare metal node boot mode is unknown (not set, can’t be read etc.), ironic node boot mode is set to the value of the [deploy]/default_boot_mode option
• If boot mode is set on a bare metal node, but is not set on ironic node, bare metal node boot mode is set on ironic node
• If boot mode is set on ironic node, but is not set on the bare metal node, ironic node boot mode is attempted to be set on the bare metal node (failure to set boot mode on the bare metal node will not fail ironic node deployment)
• If different boot modes appear on to be set ironic node and on the bare metal node, ironic node boot mode is attempted to be set on the bare metal node (failure to set boot mode on the bare metal node will fail ironic node deployment)

The boot modes can be configured in the Bare Metal service in the following way:

• Only one boot mode (either uefi or bios) can be configured for the node.

• If the operator wants a node to boot always in uefi mode or bios mode, then they may use capabilities parameter within properties field of an bare metal node. The operator must manually set the appropriate boot mode on the bare metal node.

  To configure a node in uefi mode, then set capabilities as below:

  openstack baremetal node set <node-uuid> --property capabilities='boot_mode:uefi'
  

  Nodes having boot_mode set to uefi may be requested by adding an extra_spec to the Compute service flavor:

  nova flavor-key ironic-test-3 set capabilities:boot_mode="uefi"
  nova boot --flavor ironic-test-3 --image test-image instance-1
  

  If capabilities is used in extra_spec as above, nova scheduler (ComputeCapabilitiesFilter) will match only bare metal nodes which have the boot_mode set appropriately in properties/capabilities. It will filter out rest of the nodes.

  The above facility for matching in the Compute service can be used in heterogeneous environments where there is a mix of uefi and bios machines, and operator wants to provide a choice to the user regarding boot modes. If the flavor doesn’t contain boot_mode and boot_mode is configured for bare metal nodes, then nova scheduler will consider all nodes and user may get either bios or uefi machine.

Choosing the disk label¶

Ironic allows operators to choose which disk label they want their bare metal node to be deployed with when Ironic is responsible for partitioning the disk; therefore choosing the disk label does not apply when the image being deployed is a whole disk image.

There are some edge cases where someone may want to choose a specific disk label for the images being deployed, including but not limited to:

• For machines in bios boot mode with disks larger than 2 terabytes it’s recommended to use a gpt disk label. That’s because a capacity beyond 2 terabytes is not addressable by using the MBR partitioning type. But, although GPT claims to be backward compatible with legacy BIOS systems that’s not always the case.
• Operators may want to force the partitioning to be always MBR (even if the machine is deployed with boot mode uefi) to avoid breakage of applications and tools running on those instances.

The disk label can be configured in two ways; when Ironic is used with the Compute service or in standalone mode. The following bullet points and sections will describe both methods:

• When no disk label is provided Ironic will configure it according to the boot mode (see Boot mode support); bios boot mode will use msdos and uefi boot mode will use gpt.
• Only one disk label - either msdos or gpt - can be configured for the node.

openstack baremetal node set <node-uuid> --property capabilities='disk_label:gpt'

nova flavor-key baremetal set capabilities:disk_label="gpt"

openstack baremetal node set <node-uuid> --instance-info capabilities='{"disk_label": "gpt"}'

Trusted boot with partition image¶

The Bare metal service supports trusted boot with partition images. This means at the end of the deployment process, when the node is rebooted with the new user image, trusted boot will be performed. It will measure the node’s BIOS, boot loader, Option ROM and the Kernel/Ramdisk, to determine whether a bare metal node deployed by Ironic should be trusted.

It’s important to note that in order for this to work the node being deployed must have Intel TXT hardware support. The image being deployed with Ironic must have oat-client installed within it.

The following will describe how to enable trusted boot and boot with PXE and Nova:

1. Create a customized user image with oat-client installed:

   disk-image-create -u fedora baremetal oat-client -o $TRUST_IMG
   

   For more information on creating customized images, see Create and add images to the Image service.

2. Enable VT-x, VT-d, TXT and TPM on the node. This can be done manually through the BIOS. Depending on the platform, several reboots may be needed.

3. Enroll the node and update the node capability value:

   openstack baremetal node create --driver ipmi
   
   openstack baremetal node set $NODE_UUID --property capabilities={'trusted_boot':true}
   

4. Create a special flavor:

   nova flavor-key $TRUST_FLAVOR_UUID set 'capabilities:trusted_boot'=true
   

5. Prepare tboot and mboot.c32 and put them into tftp_root or http_root directory on all nodes with the ironic-conductor processes:

   Ubuntu:
       cp /usr/lib/syslinux/mboot.c32 /tftpboot/
   
   Fedora:
       cp /usr/share/syslinux/mboot.c32 /tftpboot/
   

   Note: The actual location of mboot.c32 varies among different distribution versions.

   tboot can be downloaded from https://sourceforge.net/projects/tboot/files/latest/download

6. Install an OAT Server. An OAT Server should be running and configured correctly.

7. Boot an instance with Nova:

   nova boot --flavor $TRUST_FLAVOR_UUID --image $TRUST_IMG --user-data $TRUST_SCRIPT trusted_instance
   

   Note that the node will be measured during trusted boot and the hash values saved into TPM. An example of TRUST_SCRIPT can be found in trust script example.

8. Verify the result via OAT Server.

   This is outside the scope of Ironic. At the moment, users can manually verify the result by following the manual verify steps.

Notifications¶

The Bare Metal service supports the emission of notifications, which are messages sent on a message broker (like RabbitMQ or anything else supported by the oslo messaging library) that indicate various events which occur, such as when a node changes power states. These can be consumed by an external service reading from the message bus. For example, Searchlight is an OpenStack service that uses notifications to index (and make searchable) resources from the Bare Metal service.

Notifications are disabled by default. For a complete list of available notifications and instructions for how to enable them, see the Notifications.

Configuring node web console¶

See Configuring Web or Serial Console.