Install Kubernetes Platform on All-in-One Simplex

Overview

The All-in-one Simplex (AIO-SX) deployment option provides all three cloud functions (controller, worker, and storage) on a single server.

For more information, see Supported Deployment Models.

For information on getting started quickly using an automated virtual installation, see Automated Virtual Installation.

AIO-SX Installation Workflow

The following table shows the high-level installation flow for AIO-SX:

Step	Section	Description
1	Prepare and Plan	Gather prerequisites, prepare servers, and obtain the ISO image.
2	Install Software on Controller-0	Install the platform OS on the first server.
3	Bootstrap System on Controller-0	Run the Ansible bootstrap playbook to initialize services.
4	Configure Controller-0	Set up OAM interface, NTP, and optional SR-IOV/Ceph storage.
4a	Configure PCI-SRIOV Interfaces (Optional)	Enable SR-IOV-capable interfaces for container network attachments.
5	Unlock controller-0	Unlock and bring controller-0 into service.
5a	Optional - Initialize a Ceph Persistent Storage Backend	Configure a host-based Ceph or Rook-Ceph storage backend after unlock.

Minimum hardware requirements

Bare MetalVirtual

The recommended minimum hardware requirements for bare metal servers for various host types are:

Minimum Requirements	All-in-one Controller Node
Number of servers	1
Minimum processor class	Dual-CPU Intel® Xeon® E5 26xx family (SandyBridge) 8 cores/socket or Single-CPU Intel® Xeon® D-15xx family, 8 cores (low-power/low-cost option) Note Platform: 1 physical core with HT enabled or 2 physical cores with HT disabled, (by default, configurable) The use of single physical core for platform function is only suitable for Intel® 4th Generation Xeon® Scalable Processors or above and should not be configured for previous Intel® Xeon® CPU families. For All-In-One systems with older generation processors, two physical cores (or more) must be configured. Application: Remaining cores
Minimum memory	64 GB Platform: Socket 0: 10GB (by default, configurable) Socket 1: 1GB (by default, configurable) Application: Socket 0: Remaining memory Socket 1: Remaining memory
Primary disk	500 GB SSD or NVMe (see NVME Configuration)
Additional disks	1 or more 500 GB (min. 10K RPM) for Ceph OSD Recommended, but not required: 1 or more SSDs or NVMe drives for Ceph journals (min. 1024 MiB per OSD journal) Recommended, but not required: 1 or more 500G HDs (min. 10K RPM), SSDs or NVMe drives for Container ephemeral disk storage. For StarlingX OpenStack, we recommend 1 or more 500 GB (min. 10K RPM) for VM local ephemeral storage
Minimum network ports	MGMT: 1x1GE ( Recommended: MGMT 2x10GE LAG ) Only required if subcloud is in Distributed Cloud. OAM: 1x1GE (Recommended: OAM: 2x1GE LAG) Data: 1 or more x 10GE (Recommended: Data: 2x10GE LAG)
USB	1 (Only required if used for initial installation of controller-0).
Power profile	C-states (up to C6) may be configured for some use cases where application workloads can tolerate additional scheduling/timer latency. Note C-states may be enabled depending on application requirements.
Boot order	HD, PXE, USB
BIOS mode	BIOS or UEFI Note UEFI Secure Boot and UEFI PXE boot over IPv6 are not supported. On systems with an IPv6 management network, you can use a separate IPv4 network for PXE boot. For more information, see PXE Boot Controller-0.
BIOS settings	Hyper-Threading technology enabled Virtualization technology enabled VT for directed I/O enabled CPU power and performance policy set to performance Minimum Processor Idle Power; CPU C state control disabled Plug & play BMC detection disabled Note The system will not override the recommended BIOS settings.

Prepare and Plan

Complete the following prerequisites before starting the StarlingX installation.

Note

By default, StarlingX uses IPv4. To use StarlingX with IPv6:

• The entire infrastructure and cluster configuration must be IPv6, with the exception of the PXE boot network.

• Not all external servers are reachable via IPv6 addresses (for example Docker registries). Depending on your infrastructure, it may be necessary to deploy a NAT64/DNS64 gateway to translate the IPv4 addresses to IPv6.

• Refer to StarlingX IPv6 Deployment for details on how to deploy a NAT64/DNS64 gateway to use StarlingX with IPv6.

Bare MetalVirtual

Preparing servers is the first step of the StarlingX installation procedure.

Prior to starting the StarlingX installation, ensure that the bare metal servers are in the following state:

• Physically installed.

• Cabled for power.

• Cabled for networking.

  Far-end switch ports should be properly configured to realize the networking shown in the diagram earlier in this topic.

• All disks are wiped.

  This ensures that servers will boot from either the network or USB storage, if present.

• BIOS configured with Intel Virtualization (VTD, VTX)

  • Disabled for controller-only servers and storage servers.

  • Enabled for controller+worker (All-in-one) servers and worker servers.

• The servers are powered off.

After the servers are ready, download the ISO and prepare the boot mechanism. For more information, see Prepare the ISO and Boot Method.

Install Software on Controller-0

Install the StarlingX software on the first server in the deployment.

This step performs a non-interactive installation of the StarlingX operating system and RPMs on the server’s first disk. After installation, the system reboots into the newly installed OS.

The initial server becomes controller-0 for the deployment.

Bare MetalVirtual

Note

The disks and disk partitions need to be wiped before the install. Installing a Debian ISO may fail with a message that the system is in emergency mode if the disks and disk partitions are not completely wiped before the install, especially if the server was previously running a CentOS ISO.

1. Insert the bootable USB into a bootable USB port on the host you are configuring as controller-0. Do one of the following:

   • Create a bootable USB drive with the StarlingX host installer ISO. See Create Bootable USB for instructions on how to create a bootable USB with the StarlingX ISO.

   • Set up a PXE boot server hosting the installer ISO on the same network as the server that will be used as the initial controller-0. See PXE Boot Controller-0 for details on how to setup a PXEBOOT Server and pxe-boot the StarlingX load on controller-0.

2. Power on the host.

3. Attach to a console, ensure the host boots from the USB, and wait for the StarlingX Installer Menus.

4. Wait for the Install menu to appear. When prompted, make the following selections in the installer:

   Note

   If you configured the default menu options into the ISO with the update-iso.sh script (with the -d option) as described in Installation Prerequisites, the Install menu will not appear.

   1. Select the deployment option.

      Choose Debian All-in-one Install (required for an AIO Simplex or Duplex configuration). When prompted during the installation workflow, ensure that you select the Duplex deployment mode.

   2. Select console type.

      Choose one of the following based on your access method:

      • Graphical Console

      • Serial Console

   Wait for the non-interactive software installation to complete and for the server to reboot. This can take 5-10 minutes, depending on the performance of the server.

Bootstrap System on Controller-0

Use the following procedure to initialize, or bootstrap, the StarlingX software on controller-0. Provide a minimal set of system configuration parameters in the Ansible override file to complete the bootstrap process.

After the bootstrap process completes:

• The system runs the core StarlingX services on controller-0.

• You can access all APIs and CLIs locally.

• The services are not yet providing operational workloads.

Note

If a manual or unexpected reboot occurs before the bootstrap phase completes (specifically before you unlock controller-0), you must reinstall the system starting from the software installation step. Back up any updated bootstrap or deployment configuration files before reinstalling.

Before You Begin

Note

Before running the Ansible bootstrap playbook, it is important that you ensure that controller-0 server time is synchronized correctly. Run the following command:

# check the current server time
$ date

# if the current server time is not correct, update the NTP Servers configuration.
For more information, see :ref:`Configure NTP Servers <configuring-ntp-servers-and-services-using-the-cli>`.

Procedure

1. Log in to controller-0 as sysadmin / sysadmin and change the password when prompted. This is required only for the first login.

   Login: sysadmin
   Password:
   Changing password for sysadmin.
   (current) UNIX Password: sysadmin
   New Password:
   (repeat) New Password:
   

2. Verify and/or configure IP connectivity.

   Bare MetalVirtual

   External connectivity is required to run the Ansible bootstrap playbook. The StarlingX boot image will DHCP out all interfaces so the server may have obtained an IP address and have external IP connectivity if a DHCP server is present in your environment. Verify this using the ip addr and ping 8.8.8.8 commands.

   Otherwise, manually configure an IP address and default IP route. Use the PORT, IP-ADDRESS/SUBNET-LENGTH and GATEWAY-IP-ADDRESS applicable to your deployment environment.

   sudo ip address add <IP-ADDRESS>/<SUBNET-LENGTH> dev <PORT>
   sudo ip link set up dev <PORT>
   sudo ip route add default via <GATEWAY-IP-ADDRESS> dev <PORT>
   ping 8.8.8
   

3. Specify user configuration overrides for the Ansible bootstrap playbook. Create the override file in the system administrator’s home directory (for example, $HOME/localhost.yml). Ansible automatically detects and applies this file during the bootstrap process.

   Using a bootstrap override file, you can customize the Ansible bootstrap process during installation. This file lets you override the default settings defined in default.yml by specifying deployment-specific parameters, such as networking and system configuration.

   Refer to Ansible Bootstrap Configurations for instructions on creating the override file and for details on advanced Ansible bootstrap configuration scenarios.

   Ansible is used to bootstrap StarlingX on controller-0. Key files for Ansible configuration are:

   /etc/ansible/hosts

   The default Ansible inventory file. Contains a single host: localhost.

   /usr/share/ansible/stx-ansible/playbooks/bootstrap.yml

   The Ansible bootstrap playbook.

   /usr/share/ansible/stx-ansible/playbooks/host_vars/bootstrap/default.yml

   The default configuration values for the bootstrap playbook.

   sysadmin home directory ($HOME)

   The default location where Ansible looks for and imports user configuration override files for hosts. For example: $HOME/<hostname>.yml.

   Important

   Some Ansible bootstrap parameters cannot be changed or are very difficult to change after installation is complete.

   Review the set of install-time-only parameters before installation and confirm that your values for these parameters are correct for the desired installation.

   Refer to Ansible install-time-only parameters for details.

   Specify the user configuration override file for the Ansible bootstrap playbook using one of the following methods:

   Note

   This Ansible Overrides file for the Bootstrap Playbook ($HOME/localhost.yml) contains security sensitive information, use the ansible-vault create $HOME/localhost.yml command to create it. You will be prompted for a password to protect/encrypt the file. Use the ansible-vault edit $HOME/localhost.yml command if the file needs to be edited after it is created.

   1. Use a copy of the default.yml file listed above to provide your overrides.

      The default.yml file lists all available parameters for bootstrap configuration with a brief description for each parameter in the file comments.

      To use this method, run the ansible-vault create $HOME/localhost.yml command and copy the contents of the default.yml file into the ansible-vault editor, and edit the configurable values as required.

   2. Create a minimal user configuration override file.

      To use this method, create your override file with the ansible-vault create $HOME/localhost.yml command and provide the minimum required parameters for the deployment configuration as shown in the example below. Use the OAM IP SUBNET and IP addressing applicable to your deployment environment.

      Note

      During system bootstrap, the platform does not support the use of quotation characters in the keystone user password.

      cd ~
      
      cat <<EOF > localhost.yml
      
      system_mode: simplex
      
      dns_servers:
        - 8.8.8.8
        - 8.8.4.4
      
      external_oam_subnet: <OAM-IP-SUBNET>/<OAM-IP-SUBNET-LENGTH>
      external_oam_gateway_address: <OAM-GATEWAY-IP-ADDRESS>
      external_oam_floating_address: <OAM-FLOATING-IP-ADDRESS>
      
      admin_username: admin
      admin_password: <admin-password>
      ansible_become_pass: <sysadmin-password>
      
      EOF
      

      In either of the above options, the bootstrap playbook’s default values will pull all container images required for the StarlingX Platform from Docker hub.

      If you have setup a private Docker registry to use for bootstrapping then you will need to add the following lines in $HOME/localhost.yml:

      docker_registries:
        quay.io:
          url: myprivateregistry.abc.com:9001/quay.io
        docker.elastic.co:
          url: myprivateregistry.abc.com:9001/docker.elastic.co
        gcr.io:
          url: myprivateregistry.abc.com:9001/gcr.io
        ghcr.io:
          url: myprivateregistry.abc.com:9001/ghcr.io
        k8s.gcr.io:
          url: myprivateregistry.abc.com:9001/k8s.gcr.io
        docker.io:
          url: myprivateregistry.abc.com:9001/docker.io
        registry.k8s.io:
          url: myprivateregistry.abc.com:9001/registry.k8s.io
        icr.io:
          url: myprivateregistry.abc.com:9001/icr.io
        defaults:
          type: docker
          username: <your_myprivateregistry.abc.com_username>
          password: <your_myprivateregistry.abc.com_password>
      
      # Add the CA Certificate that signed myprivateregistry.abc.com’s
      # certificate as a Trusted CA
      ssl_ca_cert: /home/sysadmin/myprivateregistry.abc.com-ca-cert.pem
      

      See Use a Private Docker Registry for more information.

      If a firewall is blocking access to Docker hub or your private registry from your StarlingX deployment, you will need to add the following lines in $HOME/localhost.yml (see Docker Proxy Configuration for more details about Docker proxy settings):

      # Add these lines to configure Docker to use a proxy server
      docker_http_proxy: http://my.proxy.com:1080
      docker_https_proxy: https://my.proxy.com:1443
      docker_no_proxy:
         - 1.2.3.4
      

      Configure system_local_ca_cert, system_local_ca_key and system_root_ca_cert to setup a local intermediate CA (signed by an external Root CA) for managing / signing all of the StarlingX Certificates. See Platform Issuer (system-local-ca) for more details.

      Note

      The data provided through system_local_ca_key should contain an ECDSA (P-384 or P-521) or RSA (4096 bits or longer) private key, in unencrypted PEM format.

      Refer to Ansible Bootstrap Configurations for information on additional Ansible bootstrap configurations for advanced Ansible bootstrap scenarios.

Warning

The cluster-host and cluster-pod subnets cannot be changed after deployment is complete.

If any container workload on this system needs to connect to endpoints outside the cluster, then the cluster-host and cluster-pod networks must be:

• Globally routable and reachable from those external endpoints, so that return traffic can reach the workload; and

• Assigned a unique subnet that is not used by any other system on the same transport network.

See Cluster Host Network and Network Addressing Requirements. Correcting this later requires either a separate routable platform interface on every node that may host the workload, or a redeployment.

1. Run the Ansible bootstrap playbook:

   Note

   Before running the Ansible bootstrap playbook, it is important that you ensure that controller-0 server time is synchronized correctly. Run the following command:

   # check the current server time
   $ date
   
   # if the current server time is not correct, update the NTP Servers configuration.
   For more information, see :ref:`Configure NTP Servers <configuring-ntp-servers-and-services-using-the-cli>`.
   

   ansible-playbook --ask-vault-pass /usr/share/ansible/stx-ansible/playbooks/bootstrap.yml
   

   Wait for Ansible bootstrap playbook to complete. This can take 5-10 minutes, depending on the performance of the host machine.

Configure Controller-0

Controller-0 configuration includes setting up administrative access, configuring interfaces, and configuring network time synchronization.

1. Retrieve admin credentials:

   source /etc/platform/openrc
   

2. Configure the OAM interface of controller-0 and specify the attached network as “oam”.

   Bare MetalVirtual

   The following example configures the OAM interface on a physical untagged ethernet port, use OAM port name that is applicable to your deployment environment, for example eth0:

   ~(keystone_admin)$ OAM_IF=<OAM-PORT>
   ~(keystone_admin)$ system host-if-modify controller-0 $OAM_IF -c platform
   ~(keystone_admin)$ system interface-network-assign controller-0 $OAM_IF oam
   

   To configure a VLAN or aggregated ethernet interface, see Node Interfaces.

3. Configure NTP servers for network time synchronization:

   Bare MetalVirtual

   ~(keystone_admin)$ system ntp-modify ntpservers=0.pool.ntp.org,1.pool.ntp.org
   

   To configure PTP instead of NTP, see PTP Server Configuration.

OpenStack-specific host configuration

Important

These steps are required only if the StarlingX OpenStack application (stx-openstack) will be installed.

1. For OpenStack only: Assign OpenStack host labels to controller-0 in support of installing the stx-openstack manifest and helm-charts later.

   ~(keystone_admin)$ system host-label-assign controller-0 openstack-control-plane=enabled
   ~(keystone_admin)$ system host-label-assign controller-0 openstack-compute-node=enabled
   ~(keystone_admin)$ system host-label-assign controller-0 openvswitch=enabled

   Note

   If you have a NIC that supports SR-IOV, then you can enable it by using the following:

   ~(keystone_admin)$ system host-label-assign controller-0 sriov=enabled
   

2. For OpenStack only: Due to the additional OpenStack services running on the AIO controller platform cores, additional platform cores may be required.

   Bare MetalVirtual

   A minimum of 4 platform cores are required, 6 platform cores are recommended.

   Increase the number of platform cores with the following commands. This example assigns 6 cores on processor/numa-node 0 on controller-0 to platform.

   ~(keystone_admin)$ system host-cpu-modify -f platform -p0 6 controller-0
   

3. Due to the additional OpenStack services’ containers running on the controller host, the size of the Docker filesystem needs to be increased from the default size of 30G to 60G.

   # check existing size of docker fs
   system host-fs-list controller-0
   # check available space (Avail Size (GiB)) in cgts-vg LVG where docker fs is located
   system host-lvg-list controller-0
   # if existing docker fs size + cgts-vg available space is less than
   # 60G, you will need to add a new disk to cgts-vg.
   
      # Get device path of BOOT DISK
      system host-show controller-0 | fgrep rootfs
   
      # Get UUID of ROOT DISK by listing disks
      system host-disk-list controller-0
   
      # Add new disk to 'cgts-vg' local volume group
      system host-pv-add controller-0 cgts-vg <DISK_UUID>
      sleep 10    # wait for disk to be added
   
      # Confirm the available space and increased number of physical
      # volumes added to the cgts-vg volume group
      system host-lvg-list controller-0
   
   # Increase docker filesystem to 60G
   system host-fs-modify controller-0 docker=60
   

4. For OpenStack only: Configure the system setting for the vSwitch.

   Bare MetalVirtual

   StarlingX has OVS (kernel-based) vSwitch configured as default:

   • Runs in a container; defined within the helm charts of stx-openstack manifest.

   • Shares the core(s) assigned to the platform.

   If you require better performance, OVS-DPDK (OVS with the Data Plane Development Kit, which is supported only on bare metal hardware) should be used:

   • Runs directly on the host (it is not containerized). Requires that at least 1 core be assigned/dedicated to the vSwitch function.

   To deploy the default containerized OVS:

   ~(keystone_admin)$ system modify --vswitch_type none
   

   This does not run any vSwitch directly on the host, instead, it uses the containerized OVS defined in the helm charts of stx-openstack manifest.

   To deploy OVS-DPDK, run the following command:

   ~(keystone_admin)$ system modify --vswitch_type ovs-dpdk

   Default recommendation for an AIO-controller is to use a single core for OVS-DPDK vSwitch.

   # assign 1 core on processor/numa-node 0 on controller-0 to vswitch
   ~(keystone_admin)$ system host-cpu-modify -f vswitch -p0 1 controller-0
   

   When using OVS-DPDK, configure 1G of huge pages for vSwitch memory on each NUMA node on the host. It is recommended to configure 1x 1G huge page (-1G 1) for vSwitch memory on each NUMA node on the host.

   However, due to a limitation with Kubernetes, only a single huge page size is supported on any one host. If your application VMs require 2M huge pages, then configure 500x 2M huge pages (-2M 500) for vSwitch memory on each NUMA node on the host.

   # Assign 1x 1G huge page on processor/numa-node 0 on controller-0 to vswitch
   ~(keystone_admin)$ system host-memory-modify -f vswitch -1G 1 controller-0 0
   
   # Assign 1x 1G huge page on processor/numa-node 1 on controller-0 to vswitch
   ~(keystone_admin)$ system host-memory-modify -f vswitch -1G 1 controller-0 1
   

   Important

   VMs created in an OVS-DPDK environment must be configured to use huge pages to enable networking and must use a flavor with property: hw:mem_page_size=large Configure the huge pages for VMs in an OVS-DPDK environment on this host, the following commands are an example that assumes that 1G huge page size is being used on this host:

   # assign 1x 1G huge page on processor/numa-node 0 on controller-0 to applications
   ~(keystone_admin)$ system host-memory-modify -f application -1G 10 controller-0 0
   
   # assign 1x 1G huge page on processor/numa-node 1 on controller-0 to applications
   ~(keystone_admin)$ system host-memory-modify -f application -1G 10 controller-0 1
   

   Note

   After controller-0 is unlocked, changing vswitch_type requires locking and unlocking controller-0 to apply the change.

5. For OpenStack only: Add an instances filesystem or set up a disk based nova-local volume group, which is needed for stx-openstack nova ephemeral disks.

   Bare MetalVirtual

   Note

   Both cannot exist at the same time.

   Add an ‘instances’ filesystem

   ~(keystone_admin)$ export NODE=controller-0
   
   # Create ‘instances’ filesystem
   ~(keystone_admin)$ system host-fs-add ${NODE} instances=<size>
   

   Or add a ‘nova-local’ volume group:

   ~(keystone_admin)$ export NODE=controller-0
   
   # Create ‘nova-local’ local volume group
   ~(keystone_admin)$ system host-lvg-add ${NODE} nova-local
   
   # Get UUID of an unused DISK to to be added to the ‘nova-local’ volume
   # group. CEPH OSD Disks can NOT be used
   # List host’s disks and take note of UUID of disk to be used
   ~(keystone_admin)$ system host-disk-list ${NODE}
   
   # Add the unused disk to the ‘nova-local’ volume group
   ~(keystone_admin)$ system host-pv-add ${NODE} nova-local <DISK_UUID>
   

6. For OpenStack only: Configure data interfaces for controller-0. Data class interfaces are vSwitch interfaces used by vSwitch to provide VM virtio vNIC connectivity to OpenStack Neutron Tenant Networks on the underlying assigned Data Network.

   Important

   A compute-labeled AIO-controller host MUST have at least one Data class interface.

   • Configure the data interfaces for controller-0.

     Bare MetalVirtual

     ~(keystone_admin)$  NODE=controller-0
     
     # List inventoried host’s ports and identify ports to be used as ‘data’ interfaces,
     # based on displayed linux port name, pci address and device type.
     ~(keystone_admin)$ system host-port-list ${NODE}
     
     # List host’s auto-configured ‘ethernet’ interfaces,
     # find the interfaces corresponding to the ports identified in previous step, and
     # take note of their UUID
     ~(keystone_admin)$ system host-if-list -a ${NODE}
     
     # Modify configuration for these interfaces
     # Configuring them as ‘data’ class interfaces, MTU of 1500 and named data#
     ~(keystone_admin)$ system host-if-modify -m 1500 -n data0 -c data ${NODE} <data0-if-uuid>
     ~(keystone_admin)$ system host-if-modify -m 1500 -n data1 -c data ${NODE} <data1-if-uuid>
     
     # Create Data Networks that vswitch 'data' interfaces will be connected to
     ~(keystone_admin)$ DATANET0='datanet0'
     ~(keystone_admin)$ DATANET1='datanet1'
     ~(keystone_admin)$ system datanetwork-add ${DATANET0} vlan
     ~(keystone_admin)$ system datanetwork-add ${DATANET1} vlan
     
     # Assign Data Networks to Data Interfaces
     ~(keystone_admin)$ system interface-datanetwork-assign ${NODE} <data0-if-uuid> ${DATANET0}
     ~(keystone_admin)$ system interface-datanetwork-assign ${NODE} <data1-if-uuid> ${DATANET1}
     

Configure PCI-SRIOV Interfaces (Optional)

The optional SR-IOV configuration step in the installation workflow allows you to enable and prepare SR-IOV-capable interfaces on the system during initial deployment. This step ensures that the platform recognizes SR-IOV hardware and makes those interfaces available for subsequent configuration, but it does not fully provision or configure them for workloads. You can complete the detailed configuration, such as assigning virtual functions (VFs) and enabling SR-IOV for containers or applications, later using the PCI-SRIOV interface support section in Node Management.

1. Configure PCI-SRIOV interfaces for controller-0.

   This step applies when using SR-IOV network attachments in Kubernetes-hosted application containers or SR-IOV vNICs in OpenStack-hosted VMs. You can assign the same data networks to PCI-SRIOV interfaces as you would to vSwitch data interfaces.

   1. Configure the PCI-SRIOV interfaces for controller-0.

      ~(keystone_admin)$ export NODE=controller-0
      
      # List inventoried host’s ports and identify ports to be used as ‘pci-sriov’ interfaces,
      # based on displayed linux port name, pci address and device type.
      ~(keystone_admin)$ system host-port-list ${NODE}
      
      # List host’s auto-configured ‘ethernet’ interfaces,
      # find the interfaces corresponding to the ports identified in previous step, and
      # take note of their UUID
      ~(keystone_admin)$ system host-if-list -a ${NODE}
      
      # Modify configuration for these interfaces
      # Configuring them as ‘pci-sriov’ class interfaces, MTU of 1500 and named sriov#
      ~(keystone_admin)$ system host-if-modify -m 1500 -n sriov0 -c pci-sriov ${NODE} <sriov0-if-uuid> -N <num_vfs>
      ~(keystone_admin)$ system host-if-modify -m 1500 -n sriov1 -c pci-sriov ${NODE} <sriov1-if-uuid> -N <num_vfs>
      
      # If not already created, create Data Networks that the 'pci-sriov' interfaces will
      # be connected to
      ~(keystone_admin)$ DATANET0='datanet0'
      ~(keystone_admin)$ DATANET1='datanet1'
      ~(keystone_admin)$ system datanetwork-add ${DATANET0} vlan
      ~(keystone_admin)$ system datanetwork-add ${DATANET1} vlan
      
      # Assign Data Networks to PCI-SRIOV Interfaces
      ~(keystone_admin)$ system interface-datanetwork-assign ${NODE} <sriov0-if-uuid> ${DATANET0}
      ~(keystone_admin)$ system interface-datanetwork-assign ${NODE} <sriov1-if-uuid> ${DATANET1}
      

   2. To enable SR-IOV network attachments for the above interfaces in Kubernetes-hosted application containers:

      Bare MetalVirtual

      1. Configure the Kubernetes SR-IOV device plugin.

         ~(keystone_admin)$ system host-label-assign controller-0 sriovdp=enabled
         

      2. Optional step: If you are planning on running DPDK in Kubernetes hosted application containers on this host, configure the number of 1G Huge pages required on both NUMA nodes.

         # assign 10x 1G huge page on processor/numa-node 0 on controller-0 to applications
         ~(keystone_admin)$ system host-memory-modify -f application controller-0 0 -1G 10
         
         # assign 10x 1G huge page on processor/numa-node 1 on controller-0 to applications
         ~(keystone_admin)$ system host-memory-modify -f application controller-0 1 -1G
         

Unlock controller-0

Unlock controller-0 to bring it into service:

~(keystone_admin)$ system host-unlock controller-0

Controller-0 will reboot in order to apply configuration changes and come into service. This can take 5-10 minutes, depending on the performance of the host machine.

For Rook-Ceph:

1. List all the disks.

   $ system host-disk-list controller-0
   +--------------------------------------+-------------+------------+-------------+----------+---------------+--------------+---------------------+--------------------------------------------+
   | uuid                                 | device_node | device_num | device_type | size_gib | available_gib | rpm          | serial_id           | device_path                                |
   +--------------------------------------+-------------+------------+-------------+----------+---------------+--------------+---------------------+--------------------------------------------+
   | 17408af3-e211-4e2b-8cf1-d2b6687476d5 | /dev/sda    | 2048       | HDD         | 292.968  | 0.0           | Undetermined | VBba52ec56-f68a9f2d | /dev/disk/by-path/pci-0000:00:0d.0-ata-1.0 |
   | cee99187-dac4-4a7b-8e58-f2d5bd48dcaf | /dev/sdb    | 2064       | HDD         | 9.765    | 0.0           | Undetermined | VBf96fa322-597194da | /dev/disk/by-path/pci-0000:00:0d.0-ata-2.0 |
   | 0c6435af-805a-4a62-ad8e-403bf916f5cf | /dev/sdc    | 2080       | HDD         | 9.765    | 9.761         | Undetermined | VBeefed5ad-b4815f0d | /dev/disk/by-path/pci-0000:00:0d.0-ata-3.0 |
   +--------------------------------------+-------------+------------+-------------+----------+---------------+--------------+---------------------+--------------------------------------------+
   

2. Choose empty disks and provide hostname and uuid to finish OSD configuration:

   $ system host-stor-add controller-0 osd cee99187-dac4-4a7b-8e58-f2d5bd48dcaf
   

3. Wait for OSDs pod to be ready.

   $ kubectl get pods -n rook-ceph
   NAME                                                     READY   STATUS      RESTARTS      AGE
   ceph-mgr-provision-78xjk                                0/1     Completed   0          4m31s
   csi-cephfsplugin-572jc                                  2/2     Running     0          5m32s
   csi-cephfsplugin-provisioner-5467c6c4f-t8x8d            5/5     Running     0          5m28s
   csi-rbdplugin-2npb6                                     2/2     Running     0          5m32s
   csi-rbdplugin-provisioner-fd84899c-k8wcw                5/5     Running     0          5m32s
   rook-ceph-crashcollector-controller-0-589f5f774-d8sjz   1/1     Running     0          3m24s
   rook-ceph-exporter-controller-0-5fd477bb8-c7nxh         1/1     Running     0          3m21s
   rook-ceph-mds-kube-cephfs-a-cc647757-6p9j5              2/2     Running     0          3m25s
   rook-ceph-mds-kube-cephfs-b-5b5845ff59-xprbb            2/2     Running     0          3m19s
   rook-ceph-mgr-a-746fc4dd54-t8bcw                        2/2     Running     0          4m40s
   rook-ceph-mon-a-b6c95db97-f5fqq                         2/2     Running     0          4m56s
   rook-ceph-operator-69b5674578-27bn4                     1/1     Running     0          6m26s
   rook-ceph-osd-0-7f5cd957b8-ppb99                        2/2     Running     0          3m52s
   rook-ceph-osd-prepare-controller-0-vzq2d                0/1     Completed   0          4m18s
   rook-ceph-provision-zcs89                               0/1     Completed   0          101s
   rook-ceph-tools-7dc9678ccb-v2gps                        1/1     Running     0          6m2s
   stx-ceph-manager-664f8585d8-wzr4v                       1/1     Running     0          4m31s
   

4. Check ceph cluster health.

   $ ceph -s
      cluster:
         id:     75c8f017-e7b8-4120-a9c1-06f38e1d1aa3
         health: HEALTH_OK
   
      services:
         mon: 1 daemons, quorum a (age 32m)
         mgr: a(active, since 30m)
         mds: 1/1 daemons up, 1 hot standby
         osd: 1 osds: 1 up (since 30m), 1 in (since 31m)
   
      data:
         volumes: 1/1 healthy
         pools:   4 pools, 113 pgs
         objects: 22 objects, 595 KiB
         usage:   27 MiB used, 9.7 GiB / 9.8 GiB avail
         pgs:     113 active+clean
   
      io:
         client:   852 B/s rd, 1 op/s rd, 0 op/s wr
   

Optional - Initialize a Ceph Persistent Storage Backend

Your application requires a persistent storage backend if it uses PVCs.

There are two options for persistent storage backend: the host-based Ceph solution and the Rook container-based Ceph solution.

Host-based Ceph will be deprecated and removed in an upcoming release. Adoption of Rook-Ceph is recommended for new deployments.

For host-based Ceph:

1. Add host-based Ceph backend:

   ~(keystone_admin)$ system storage-backend-add ceph --confirmed
   

2. Add an OSD on controller-0 for host-based Ceph:

   # List host’s disks and identify disks you want to use for CEPH OSDs, taking note of their UUID
   # By default, /dev/sda is used as the system disk and cannot be used for OSD.
   ~(keystone_admin)$ system host-disk-list controller-0
   
   # Add disk as an OSD storage
   ~(keystone_admin)$ system host-stor-add controller-0 osd <disk-uuid>
   
   # List OSD storage devices
   ~(keystone_admin)$ system host-stor-list controller-0
   

For Rook-Ceph:

Note

Each deployment model enforces a different structure for the Rook Ceph cluster and its integration with the platform.

For more details see StarlingX Storage Configuration and Management: Install Rook Ceph.

1. Check if the rook-ceph app is uploaded.

   $ source /etc/platform/openrc
   $ system application-list
   

2. Add Storage-Backend with Deployment Model.

   There are three deployment models: Controller, Dedicated, and Open.

   For the simplex and duplex environments you can use the Controller and Open configuration.

   Controller (default)

   OSDs must only be added to host with controller personality set.

   Replication factor is limited to a maximum of 2.

   Dedicated

   OSDs must be added only to hosts with the worker personality.

   The replication factor is limited to a maximum of 3.

   This model aligns with existing Bare-metal Ceph use of dedicated storage hosts in groups of 2 or 3.

   Open

   OSDs can be added to any host without limitations.

   Replication factor has no limitations.

   Application Strategies for deployment model controller.

   Simplex

   OSDs: Added to controller nodes.

   Replication Factor: Default 1, maximum 2.

   MON, MGR, MDS: Configured based on the number of hosts where the host-fs ceph is available.

   $ system storage-backend-add ceph-rook --deployment controller --confirmed
   $ system storage-backend-list
   +--------------------------------------+-----------------+-----------+----------------------+----------+------------+-------------------------------------------+
   | uuid                                 | name            | backend   | state                | task     | services   | capabilities                              |
   +--------------------------------------+-----------------+-----------+----------------------+----------+------------+-------------------------------------------+
   | a2452e47-4b2b-4a3a-a8f0-fb749d92d9cd | ceph-rook-store | ceph-rook | configuring-with-app | uploaded | block,     | deployment_model: controller replication: |
   |                                      |                 |           |                      |          | filesystem | 1 min_replication: 1                      |
   +--------------------------------------+-----------------+-----------+----------------------+----------+------------+-------------------------------------------+
   

3. Set up a host-fs ceph filesystem.

   $ system host-fs-add controller-0 ceph=20
   

Additional Optional Configurations

If you need to install the StarlingX OpenStack application (stx-openstack), see OpenStack-Specific Host Configuration.

Post-Installation Tasks

After completing the installation, perform the following post-installation tasks to fully configure and prepare the system for use. For more information, see Post-Installation Tasks.