For information about supported hardware for multipathing, see Book “Planning an Installation with Cloud Lifecycle Manager”, Chapter 2 “Hardware and Software Support Matrix”, Section 2.2 “Supported Hardware Configurations”.

Important

When exporting a LUN to a node for boot from SAN, you should ensure that LUN 0 is assigned to the LUN and configure any setup dialog that is necessary in the firmware to consume this LUN 0 for OS boot.

Important

Any hosts that are connected to 3PAR storage must have a host persona of 2-generic-alua set on the 3PAR. Refer to the 3PAR documentation for the steps necessary to check this and change if necessary.

iSCSI boot from SAN is not supported. For more information on the use of Cinder with multipath, see Section 23.1.3, “Multipath Support”.

To allow HPE Helion OpenStack 8 to use volumes from a SAN, you have to specify configuration options for both the installation and the OS configuration phase. In all cases, the devices that are utilized are devices for which multipath is configured.

For FC connected nodes and for FCoE nodes where the network processor used is from the Emulex family such as for the 650FLB, the following changes need to be made.

Instead of using Cobbler, you need to provision a baremetal node manually using the following procedure.

If you are using network cards such as Qlogic Flex Fabric 536 and 630 series, there are additional OS configuration steps to support the importation of LUNs as well as some restrictions on supported configurations.

The restrictions are:

In addition to the configuration options above, you also need to specify the FCoE interfaces for install and for os configuration. There are 3 places where you need to add additional configuration options for fcoe-support:

Since NIC mapping is not used to guarantee order of the networks across the system the installer will remap the network interfaces in a deterministic fashion as part of the install. As part of the installer dialogue, if DHCP is not configured for the interface, it is necessary to confirm that the appropriate interface is assigned the ip address. The network interfaces may not be at the names expected when installing via an ISO. When you are asked to apply an IP address to an interface, press Alt–F2 and in the console window, run the command ip a to examine the interfaces and their associated MAC addresses. Make a note of the interface name with the expected MAC address and use this in the subsequent dialog. Press Alt–F1 to return to the installation screen. You should note that the names of the interfaces may have changed after the installation completes. These names are used consistently in any subsequent operations.

Therefore, even if FCoE is not used for boot from SAN (for example for cinder), then it is recommended that fcoe-interfaces be specified as part of install (without the multipath or disk detect options). Alternatively, you need to run osconfig-fcoe-reorder.yml before site.yml or osconfig-run.yml is invoked to reorder the networks in a similar manner to the installer. In this case, the nodes will need to be manually rebooted for the network reorder to take effect. Run osconfig-fcoe-reorder.yml in the following scenarios:

To run the command:

cd ~/scratch/ansible/next/ardana/ansible
ansible-playbook -i hosts/verb_hosts osconfig-fcoe-reorder.yml

If you do not run osconfig-fcoe-reorder.yml, you will encounter a failure in osconfig-run.yml.

If you are booting from a local disk, the LUNs that will be imported over FCoE will not be visible before site.yml or osconfig-run.yml has been run. However, if you need to import the LUNs before this, for instance, in scenarios where you need to run wipe_disks.yml (run this only after first running bm-reimage.yml), then you can run the fcoe-enable playbook across the nodes in question. This will configure FCoE and import the LUNs presented to the nodes.

cd ~/openstack/ardana/ansible
ansible-playbook -i hosts/verb_hosts fcoe-enable.yml

When installing a Red Hat compute host, the names of the network interfaces will have names like ens1f2 rather than eth2 therefore a separate role and associated network-interfaces and fcoe-interfaces descriptions will have to be provided in the input model for the Red Hat compute hosts. Here are some excerpts highlighting the changes required:

net_interfaces.yml

    - name: RHEL-COMPUTE-INTERFACES
      fcoe-interfaces:
        - name: fcoe
          devices:
             - ens1f2
             - ens1f3
      network-interfaces:
        - name: ens1f0
          device:
              name: ens1f0
          network-groups:
            - EXTERNAL-VM
            - GUEST
            - MANAGEMENT

control_plane.yml

        - name: rhel-compute
          resource-prefix: rhcomp
          server-role: RHEL-COMPUTE-ROLE
          allocation-policy: any
          min-count: 0
          service-components:
            - ntp-client
            - nova-compute
            - nova-compute-kvm
            - neutron-l3-agent
            - neutron-metadata-agent
            - neutron-openvswitch-agent
            - neutron-lbaasv2-agent

server_roles.yml

    - name: RHEL-COMPUTE-ROLE
      interface-model: RHEL-COMPUTE-INTERFACES
      disk-model: COMPUTE-DISKS

servers.yml

    - id: QlogicFCoE-Cmp2
      ip-addr: 10.245.224.204
      role: RHEL-COMPUTE-ROLE
      server-group: RACK2
      mac-addr: "6c:c2:17:33:4c:a0"
      ilo-ip: 10.1.66.26
      ilo-password: linuxbox123
      ilo-user: linuxbox
      boot-from-san: True
      fcoe-interfaces:
         - 6c:c2:17:33:4c:a1
         - 6c:c2:17:33:4c:a9