iLO drivers¶

Hardware Interfaces¶

The ilo hardware type supports following hardware interfaces:

• boot

  Supports ilo-virtual-media and ilo-pxe. The default is ilo-virtual-media. They can be enabled by using the [DEFAULT]enabled_boot_interfaces option in ironic.conf as given below:

  [DEFAULT]
  enabled_hardware_types = ilo
  enabled_boot_interfaces = ilo-virtual-media,ilo-pxe
  

• console

  Supports ilo and no-console. The default is ilo. They can be enabled by using the [DEFAULT]enabled_console_interfaces option in ironic.conf as given below:

  [DEFAULT]
  enabled_hardware_types = ilo
  enabled_console_interfaces = ilo,no-console
  

• inspect

  Supports ilo and inspector. The default is ilo. They can be enabled by using the [DEFAULT]enabled_inspect_interfaces option in ironic.conf as given below:

  [DEFAULT]
  enabled_hardware_types = ilo
  enabled_inspect_interfaces = ilo,inspector
  

  Note

  Ironic Inspector needs to be configured to use inspector as the inspect interface.

• management

  Supports only ilo. It can be enabled by using the [DEFAULT]enabled_management_interfaces option in ironic.conf as given below:

  [DEFAULT]
  enabled_hardware_types = ilo
  enabled_management_interfaces = ilo
  

• power

  Supports only ilo. It can be enabled by using the [DEFAULT]enabled_power_interfaces option in ironic.conf as given below:

  [DEFAULT]
  enabled_hardware_types = ilo
  enabled_power_interfaces = ilo
  

• raid

  Supports agent and no-raid. The default is no-raid. They can be enabled by using the [DEFAULT]enabled_raid_interfaces option in ironic.conf as given below:

  [DEFAULT]
  enabled_hardware_types = ilo
  enabled_raid_interfaces = agent,no-raid
  

• storage

  Supports cinder and noop. The default is noop. They can be enabled by using the [DEFAULT]enabled_storage_interfaces option in ironic.conf as given below:

  [DEFAULT]
  enabled_hardware_types = ilo
  enabled_storage_interfaces = cinder,noop
  

  Note

  The storage interface cinder is supported only when corresponding boot interface of the ilo hardware type based node is ilo-pxe. Please refer to Boot From Volume for configuring cinder as a storage interface.

ilo hardware type supports all standard deploy and network interface implementations, see Enabling hardware interfaces for details.

The following command can be used to enroll a ProLiant node with ilo hardware type:

openstack baremetal node create --os-baremetal-api-version=1.31 \
    --driver ilo \
    --deploy-interface direct \
    --raid-interface agent \
    --driver-info ilo_address=<ilo-ip-address> \
    --driver-info ilo_username=<ilo-username> \
    --driver-info ilo_password=<ilo-password> \
    --driver-info ilo_deploy_iso=<glance-uuid-of-deploy-iso>

Please refer to Enabling drivers and hardware types for detailed explanation of hardware type.

To enable the same feature set as provided by all iLO classic drivers, apply the following configuration:

[DEFAULT]
enabled_hardware_types = ilo
enabled_boot_interfaces = ilo-virtual-media,ilo-pxe
enabled_power_interfaces = ilo
enabled_console_interfaces = ilo
enabled_raid_interfaces = agent
enabled_management_interfaces = ilo
enabled_inspect_interfaces = ilo

The following commands can be used to enroll a node with the same feature set as one of the classic drivers, but using the ilo hardware type:

• iscsi_ilo:

  openstack baremetal node create --os-baremetal-api-version=1.31 \
      --driver ilo \
      --deploy-interface iscsi \
      --boot-interface ilo-virtual-media \
      --driver-info ilo_address=<ilo-ip-address> \
      --driver-info ilo_username=<ilo-username> \
      --driver-info ilo_password=<ilo-password> \
      --driver-info ilo_deploy_iso=<glance-uuid-of-deploy-iso>
  

• pxe_ilo:

  openstack baremetal node create --os-baremetal-api-version=1.31 \
      --driver ilo \
      --deploy-interface iscsi \
      --boot-interface ilo-pxe \
      --driver-info ilo_address=<ilo-ip-address> \
      --driver-info ilo_username=<ilo-username> \
      --driver-info ilo_password=<ilo-password> \
      --driver-info deploy_kernel=<glance-uuid-of-pxe-deploy-kernel> \
      --driver-info deploy_ramdisk=<glance-uuid-of-deploy-ramdisk>
  

• agent_ilo:

  openstack baremetal node create --os-baremetal-api-version=1.31 \
      --driver ilo \
      --deploy-interface direct \
      --boot-interface ilo-virtual-media \
      --driver-info ilo_address=<ilo-ip-address> \
      --driver-info ilo_username=<ilo-username> \
      --driver-info ilo_password=<ilo-password> \
      --driver-info ilo_deploy_iso=<glance-uuid-of-deploy-iso>
  

Glance Configuration¶

1. Configure Glance image service with its storage backend as Swift.

2. Set a temp-url key for Glance user in Swift. For example, if you have configured Glance with user glance-swift and tenant as service, then run the below command:

   swift --os-username=service:glance-swift post -m temp-url-key:mysecretkeyforglance
   

3. Fill the required parameters in the [glance] section in /etc/ironic/ironic.conf. Normally you would be required to fill in the following details:

   [glance]
   swift_temp_url_key=mysecretkeyforglance
   swift_endpoint_url=https://10.10.1.10:8080
   swift_api_version=v1
   swift_account=AUTH_51ea2fb400c34c9eb005ca945c0dc9e1
   swift_container=glance
   

   The details can be retrieved by running the below command:

   $ swift --os-username=service:glance-swift stat -v | grep -i url
   
   StorageURL:     http://10.10.1.10:8080/v1/AUTH_51ea2fb400c34c9eb005ca945c0dc9e1
   Meta Temp-Url-Key: mysecretkeyforglance
   

4. Swift must be accessible with the same admin credentials configured in Ironic. For example, if Ironic is configured with the below credentials in /etc/ironic/ironic.conf:

   [keystone_authtoken]
   admin_password = password
   admin_user = ironic
   admin_tenant_name = service
   

   Ensure auth_version in keystone_authtoken to 2.

   Then, the below command should work.:

   $ swift --os-username ironic --os-password password --os-tenant-name service --auth-version 2 stat
   
                        Account: AUTH_22af34365a104e4689c46400297f00cb
                     Containers: 2
                        Objects: 18
                          Bytes: 1728346241
   Objects in policy "policy-0": 18
     Bytes in policy "policy-0": 1728346241
              Meta Temp-Url-Key: mysecretkeyforglance
                    X-Timestamp: 1409763763.84427
                     X-Trans-Id: tx51de96a28f27401eb2833-005433924b
                   Content-Type: text/plain; charset=utf-8
                  Accept-Ranges: bytes
   

5. Restart the Ironic conductor service:

   $ service ironic-conductor restart
   

Web server configuration on conductor¶

• The HTTP(S) web server can be configured in many ways. For apache web server on Ubuntu, refer here

• Following config variables need to be set in /etc/ironic/ironic.conf:

  • use_web_server_for_images in [ilo] section:

    [ilo]
    use_web_server_for_images = True
    

  • http_url and http_root in [deploy] section:

    [deploy]
    # Ironic compute node's http root path. (string value)
    http_root=/httpboot
    
    # Ironic compute node's HTTP server URL. Example:
    # http://192.1.2.3:8080 (string value)
    http_url=http://192.168.0.2:8080
    

use_web_server_for_images: If the variable is set to false, iscsi_ilo and agent_ilo uses swift containers to host the intermediate floppy image and the boot ISO. If the variable is set to true, these drivers use the local web server for hosting the intermediate files. The default value for use_web_server_for_images is False.

http_url: The value for this variable is prefixed with the generated intermediate files to generate a URL which is attached in the virtual media.

http_root: It is the directory location to which ironic conductor copies the intermediate floppy image and the boot ISO.

iscsi_ilo driver¶

openstack baremetal node create --driver iscsi_ilo \
    --driver-info ilo_address=<ilo-ip-address> \
    --driver-info ilo_username=<ilo-username> \
    --driver-info ilo_password=<ilo-password> \
    --driver-info ilo_deploy_iso=<glance-uuid-of-deploy-iso>

agent_ilo driver¶

openstack baremetal node create --driver agent_ilo \
    --driver-info ilo_address=<ilo-ip-address> \
    --driver-info ilo_username=<ilo-username> \
    --driver-info ilo_password=<ilo-password> \
    --driver-info ilo_deploy_iso=<glance-uuid-of-deploy-iso>

pxe_ilo driver¶

openstack baremetal node create --driver pxe_ilo \
    --driver-info ilo_address=<ilo-ip-address> \
    --driver-info ilo_username=<ilo-username> \
    --driver-info ilo_password=<ilo-password> \
    --driver-info deploy_kernel=<glance-uuid-of-pxe-deploy-kernel> \
    --driver-info deploy_ramdisk=<glance-uuid-of-deploy-ramdisk>

Boot mode support¶

The hardware type ilo and iLO-based classic drivers support automatic detection and setting of boot mode (Legacy BIOS or UEFI).

• When boot mode capability is not configured:

  • If config variable default_boot_mode in [ilo] section of ironic configuration file is set to either ‘bios’ or ‘uefi’, then iLO drivers use that boot mode for provisioning the baremetal ProLiant servers.
  • If the pending boot mode is set on the node then iLO drivers use that boot mode for provisioning the baremetal ProLiant servers.
  • If the pending boot mode is not set on the node then iLO drivers use ‘uefi’ boot mode for UEFI capable servers and “bios” when UEFI is not supported.

• When boot mode capability is configured, the driver sets the pending boot mode to the configured value.

• 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 ironic 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 nova 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 ironic 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 nova 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 then nova scheduler will not consider boot mode as a placement criteria, hence user may get either a BIOS or UEFI machine that matches with user specified flavors.

The automatic boot ISO creation for UEFI boot mode has been enabled in Kilo. The manual creation of boot ISO for UEFI boot mode is also supported. For the latter, the boot ISO for the deploy image needs to be built separately and the deploy image’s boot_iso property in glance should contain the glance UUID of the boot ISO. For building boot ISO, add iso element to the diskimage-builder command to build the image. For example:

disk-image-create ubuntu baremetal iso

UEFI Secure Boot Support¶

The hardware type ilo and iLO-based classic drivers support secure boot deploy.

The UEFI secure boot can be configured in ironic by adding secure_boot parameter in the capabilities parameter within properties field of an ironic node.

secure_boot is a boolean parameter and takes value as true or false.

To enable secure_boot on a node add it to capabilities as below:

openstack baremetal node set <node-uuid> --property capabilities='secure_boot:true'

Alternatively see Hardware Inspection Support to know how to automatically populate the secure boot capability.

Nodes having secure_boot set to true may be requested by adding an extra_spec to the nova flavor:

nova flavor-key ironic-test-3 set capabilities:secure_boot="true"
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 ironic nodes which have the secure_boot set appropriately in properties/capabilities. It will filter out rest of the nodes.

The above facility for matching in nova can be used in heterogeneous environments where there is a mix of machines supporting and not supporting UEFI secure boot, and operator wants to provide a choice to the user regarding secure boot. If the flavor doesn’t contain secure_boot then nova scheduler will not consider secure boot mode as a placement criteria, hence user may get a secure boot capable machine that matches with user specified flavors but deployment would not use its secure boot capability. Secure boot deploy would happen only when it is explicitly specified through flavor.

Use element ubuntu-signed or fedora to build signed deploy iso and user images from diskimage-builder. Please refer to Building or downloading a deploy ramdisk image for more information on building deploy ramdisk.

The below command creates files named cloud-image-boot.iso, cloud-image.initrd, cloud-image.vmlinuz and cloud-image.qcow2 in the current working directory:

cd <path-to-diskimage-builder>
./bin/disk-image-create -o cloud-image ubuntu-signed baremetal iso

Ensure the public key of the signed image is loaded into bare metal to deploy signed images. For HPE ProLiant Gen9 servers, one can enroll public key using iLO System Utilities UI. Please refer to section Accessing Secure Boot options in HP UEFI System Utilities User Guide. One can also refer to white paper on Secure Boot for Linux on HP ProLiant servers for additional details.

For more up-to-date information, refer iLO driver wiki page

Node Cleaning Support¶

The hardware type ilo and iLO-based classic drivers support node cleaning.

For more information on node cleaning, see Node cleaning

Hardware Inspection Support¶

The hardware type ilo and iLO-based classic drivers support hardware inspection.

The inspection process will discover the following essential properties (properties required for scheduling deployment):

• memory_mb: memory size
• cpus: number of cpus
• cpu_arch: cpu architecture
• local_gb: disk size

Inspection can also discover the following extra capabilities for iLO drivers:

• ilo_firmware_version: iLO firmware version

• rom_firmware_version: ROM firmware version

• secure_boot: secure boot is supported or not. The possible values are ‘true’ or ‘false’. The value is returned as ‘true’ if secure boot is supported by the server.

• server_model: server model

• pci_gpu_devices: number of gpu devices connected to the bare metal.

• nic_capacity: the max speed of the embedded NIC adapter.

• sriov_enabled: true, if server has the SRIOV supporting NIC.

• has_rotational: true, if server has HDD disk.

• has_ssd: true, if server has SSD disk.

• has_nvme_ssd: true, if server has NVME SSD disk.

• cpu_vt: true, if server supports cpu virtualization.

• hardware_supports_raid: true, if RAID can be configured on the server using RAID controller.

• nvdimm_n: true, if server has NVDIMM_N type of persistent memory.

• persistent_memory: true, if server has persistent memory.

• logical_nvdimm_n: true, if server has logical NVDIMM_N configured.

• rotational_drive_<speed>_rpm: The capabilities rotational_drive_4800_rpm, rotational_drive_5400_rpm, rotational_drive_7200_rpm, rotational_drive_10000_rpm and rotational_drive_15000_rpm are set to true if the server has HDD drives with speed of 4800, 5400, 7200, 10000 and 15000 rpm respectively.

• logical_raid_level_<raid_level>: The capabilities logical_raid_level_0, logical_raid_level_1, logical_raid_level_2, logical_raid_level_5, logical_raid_level_6, logical_raid_level_10, logical_raid_level_50 and logical_raid_level_60 are set to true if any of the raid levels among 0, 1, 2, 5, 6, 10, 50 and 60 are configured on the system.

  Note

  • The capability nic_capacity can only be discovered if ipmitool version >= 1.8.15 is used on the conductor. The latest version can be downloaded from here.
  • The iLO firmware version needs to be 2.10 or above for nic_capacity to be discovered.

The operator can specify these capabilities in nova flavor for node to be selected for scheduling:

nova flavor-key my-baremetal-flavor set capabilities:server_model="<in> Gen8"

nova flavor-key my-baremetal-flavor set capabilities:nic_capacity="10Gb"

nova flavor-key my-baremetal-flavor set capabilities:ilo_firmware_version="<in> 2.10"

nova flavor-key my-baremetal-flavor set capabilities:has_ssd="true"

See Capabilities discovery for more details and examples.

Swiftless deploy for intermediate images¶

The hardware type ilo with ilo-virtual-media as boot interface and virtual media based classical drivers (iscsi_ilo and agent_ilo) can deploy and boot the server with and without swift being used for hosting the intermediate temporary floppy image (holding metadata for deploy kernel and ramdisk) and the boot ISO. A local HTTP(S) web server on each conductor node needs to be configured. Please refer to Web server configuration on conductor for more information. The HTTPS web server needs to be enabled (instead of HTTP web server) in order to send management information and images in encrypted channel over HTTPS.

HTTP(S) Based Deploy Support¶

The user input for the images given in driver_info like ilo_deploy_iso, deploy_kernel and deploy_ramdisk and in instance_info like image_source, kernel, ramdisk and ilo_boot_iso may also be given as HTTP(S) URLs.

The HTTP(S) web server can be configured in many ways. For the Apache web server on Ubuntu, refer here. The web server may reside on a different system than the conductor nodes, but its URL must be reachable by the conductor and the bare metal nodes.

Support for iLO drivers with Standalone Ironic¶

It is possible to use ironic as standalone services without other OpenStack services. The ilo hardware type and the iLO-based classic drivers can be used in standalone ironic. This feature is referred to as iLO drivers with standalone ironic in this document.

Netboot with glance and swift¶

Localboot with glance and swift for partition images¶

Localboot with glance and swift¶

Netboot in swiftless deploy for intermediate images¶

Localboot in swiftless deploy for intermediate images¶

Netboot with HTTP(S) based deploy¶

Localboot with HTTP(S) based deploy¶

Netboot in standalone ironic¶

Localboot in standalone ironic¶

Activating iLO Advanced license as manual clean step¶

iLO drivers can activate the iLO Advanced license key as a manual cleaning step. Any manual cleaning step can only be initiated when a node is in the manageable state. Once the manual cleaning is finished, the node will be put in the manageable state again. User can follow steps from Manual cleaning to initiate manual cleaning operation on a node.

An example of a manual clean step with activate_license as the only clean step could be:

"clean_steps": [{
    "interface": "management",
    "step": "activate_license",
    "args": {
        "ilo_license_key": "ABC12-XXXXX-XXXXX-XXXXX-YZ345"
    }
}]

The different attributes of activate_license clean step are as follows:

Initiating firmware update as manual clean step¶

iLO drivers can invoke secure firmware update as a manual cleaning step. Any manual cleaning step can only be initiated when a node is in the manageable state. Once the manual cleaning is finished, the node will be put in the manageable state again. A user can follow steps from Manual cleaning to initiate manual cleaning operation on a node.

An example of a manual clean step with update_firmware as the only clean step could be:

"clean_steps": [{
    "interface": "management",
    "step": "update_firmware",
    "args": {
        "firmware_update_mode": "ilo",
        "firmware_images":[
            {
                "url": "file:///firmware_images/ilo/1.5/CP024444.scexe",
                "checksum": "a94e683ea16d9ae44768f0a65942234d",
                "component": "ilo"
            },
            {
                "url": "swift://firmware_container/cpld2.3.rpm",
                "checksum": "<md5-checksum-of-this-file>",
                "component": "cpld"
            },
            {
                "url": "http://my_address:port/firmwares/bios_vLatest.scexe",
                "checksum": "<md5-checksum-of-this-file>",
                "component": "bios"
            },
            {
                "url": "https://my_secure_address_url/firmwares/chassis_vLatest.scexe",
                "checksum": "<md5-checksum-of-this-file>",
                "component": "chassis"
            },
            {
                "url": "file:///home/ubuntu/firmware_images/power_pic/pmc_v3.0.bin",
                "checksum": "<md5-checksum-of-this-file>",
                "component": "power_pic"
            }
        ]
    }
}]

The different attributes of update_firmware clean step are as follows:

Each firmware image block is represented by a dictionary (JSON), in the form:

{
  "url": "<url of firmware image file>",
  "checksum": "<md5 checksum of firmware image file to verify the image>",
  "component": "<device on which firmware image will be flashed>"
}

All the fields in the firmware image block are mandatory.

• The different types of firmware url schemes supported are: file, http, https and swift.

  Note

  This feature assumes that while using file url scheme the file path is on the conductor controlling the node.

  Note

  The swift url scheme assumes the swift account of the service project. The service project (tenant) is a special project created in the Keystone system designed for the use of the core OpenStack services. When Ironic makes use of Swift for storage purpose, the account is generally service and the container is generally ironic and ilo drivers use a container named ironic_ilo_container for their own purpose.

  Note

  While using firmware files with a .rpm extension, make sure the commands rpm2cpio and cpio are present on the conductor, as they are utilized to extract the firmware image from the package.

• The firmware components that can be updated are: ilo, cpld, power_pic, bios and chassis.

• The firmware images will be updated in the order given by the operator. If there is any error during processing of any of the given firmware images provided in the list, none of the firmware updates will occur. The processing error could happen during image download, image checksum verification or image extraction. The logic is to process each of the firmware files and update them on the devices only if all the files are processed successfully. If, during the update (uploading and flashing) process, an update fails, then the remaining updates, if any, in the list will be aborted. But it is recommended to triage and fix the failure and re-attempt the manual clean step update_firmware for the aborted firmware_images.

  The devices for which the firmwares have been updated successfully would start functioning using their newly updated firmware.

• As a troubleshooting guidance on the complete process, check Ironic conductor logs carefully to see if there are any firmware processing or update related errors which may help in root causing or gain an understanding of where things were left off or where things failed. You can then fix or work around and then try again. A common cause of update failure is HPE Secure Digital Signature check failure for the firmware image file.

• To compute md5 checksum for your image file, you can use the following command:

  $ md5sum image.rpm
  66cdb090c80b71daa21a67f06ecd3f33  image.rpm
  

Smart Update Manager (SUM) based firmware update¶

The firmware update based on SUM is an inband clean step supported by iLO drivers. The firmware update is performed on all or list of user specified firmware components on the node. Refer to SUM User Guide to get more information on SUM based firmware update.

update_firmware_sum clean step requires the agent ramdisk with Proliant Hardware Manager from the proliantutils version 2.5.0 or higher. See DIB support for Proliant Hardware Manager to create the agent ramdisk with Proliant Hardware Manager.

The attributes of update_firmware_sum clean step are as follows:

The keyword arguments used for the clean step are as follows:

• url: URL of SPP (Service Pack for Proliant) ISO. It is mandatory. The URL schemes supported are http, https and swift.
• checksum: MD5 checksum of SPP ISO to verify the image. It is mandatory.
• components: List of filenames of the firmware components to be flashed. It is optional. If not provided, the firmware update is performed on all the firmware components.

The clean step performs an update on all or a list of firmware components and returns the SUM log files. The log files include hpsum_log.txt and hpsum_detail_log.txt which holds the information about firmware components, firmware version for each component and their update status. The log object will be named with the following pattern:

<node-uuid>[_<instance-uuid>]_update_firmware_sum_<timestamp yyyy-mm-dd-hh-mm-ss>.tar.gz

Refer to Retrieving logs from the deploy ramdisk for more information on enabling and viewing the logs returned from the ramdisk.

An example of update_firmware_sum clean step:

{
    "interface": "management",
    "step": "update_firmware_sum",
    "args":
        {
            "url": "http://my_address:port/SPP.iso",
            "checksum": "abcdefxyz",
            "components": ["CP024356.scexe", "CP008097.exe"]
        }
}

The clean step fails if there is any error in the processing of clean step arguments. The processing error could happen during validation of components’ file extension, image download, image checksum verification or image extraction. In case of a failure, check Ironic conductor logs carefully to see if there are any validation or firmware processing related errors which may help in root cause analysis or gaining an understanding of where things were left off or where things failed. You can then fix or work around and then try again.

RAID Support¶

The inband RAID functionality is supported by iLO drivers. See RAID Configuration for more information. Bare Metal service update node with following information after successful configuration of RAID:

• Node properties/local_gb is set to the size of root volume.

• Node properties/root_device is filled with wwn details of root volume. It is used by iLO drivers as root device hint during provisioning.

• The value of raid level of root volume is added as raid_level capability to the node’s capabilities parameter within properties field. The operator can specify the raid_level capability in nova flavor for node to be selected for scheduling:

  nova flavor-key ironic-test set capabilities:raid_level="1+0"
  nova boot --flavor ironic-test --image test-image instance-1
  

DIB support for Proliant Hardware Manager¶

To create an agent ramdisk with Proliant Hardware Manager, use the proliant-tools element in DIB:

disk-image-create -o proliant-agent-ramdisk ironic-agent fedora proliant-tools

Disk Erase Support¶

erase_devices is an inband clean step supported by iLO drives. It performs erase on all the disks including the disks visible to OS as well as the raw disks visible to the Smart Storage Administrator (SSA).

This inband clean step requires ssacli utility starting from version 2.60-19.0 to perform the erase on physical disks. See the ssacli documentation for more information on ssacli utility and different erase methods supported by SSA.

The disk erasure via shred is used to erase disks visible to the OS and its implementation is available in Ironic Python Agent. The raw disks connected to the Smart Storage Controller are erased using Sanitize erase which is a ssacli supported erase method. If Sanitize erase is not supported on the Smart Storage Controller the disks are erased using One-pass erase (overwrite with zeros).

This clean step is supported when the agent ramdisk contains the Proliant Hardware Manager from the proliantutils version 2.3.0 or higher. This clean step is performed as part of automated cleaning and it is disabled by default. See In-band vs out-of-band for more information on enabling/disabling a clean step.

To create an agent ramdisk with Proliant Hardware Manager, use the proliant-tools element in DIB:

disk-image-create -o proliant-agent-ramdisk ironic-agent fedora proliant-tools

See the proliant-tools for more information on creating agent ramdisk with proliant-tools element in DIB.

Firmware based UEFI iSCSI boot from volume support¶

With Gen9 (UEFI firmware version 1.40 or higher) and Gen10 HPE Proliant servers, the driver supports firmware based UEFI boot of an iSCSI cinder volume.

This feature requires the node to be configured to boot in UEFI boot mode, as well as user image should be UEFI bootable image, and PortFast needs to be enabled in switch configuration for immediate spanning tree forwarding state so it wouldn’t take much time setting the iSCSI target as persistent device.

The driver does not support this functionality when in bios boot mode. In case the node is configured with ilo-pxe boot interface and the boot mode configured on the bare metal is bios, the iscsi boot from volume is performed using ipxe. See Boot From Volume for more details.

To use this feature, configure the boot mode of the bare metal to uefi and configure the corresponding ironic node using the steps given in Boot From Volume. In a cloud environment with nodes configured to boot from bios and uefi boot modes, the virtual media driver only supports uefi boot mode, and that attempting to use iscsi boot at the same time with a bios volume will result in an error.