Contents

Dell Bare Metal Orchestrator 1.3 Software Command Line Interface User's Guide PDF

1 of 226
1 of 226

Summary of Content for Dell Bare Metal Orchestrator 1.3 Software Command Line Interface User's Guide PDF

Bare Metal Orchestrator 1.3 Command Line Interface User's Guide

Version 1.3

Abstract

This guide provides an overview of Bare Metal Orchestrator and describes how you can use the Bare Metal Orchestrator's command line interface to streamline deployments and comprehensively manage the infrastructure life cycle.

Dell Technologies Solutions

September 2022 Rev. 05

Notes, cautions, and warnings

NOTE: A NOTE indicates important information that helps you make better use of your product.

CAUTION: A CAUTION indicates either potential damage to hardware or loss of data and tells you how to avoid

the problem.

WARNING: A WARNING indicates a potential for property damage, personal injury, or death.

2021 - 2022 Dell Inc. or its subsidiaries. All rights reserved. Dell Technologies, Dell, and other trademarks are trademarks of Dell Inc. or its subsidiaries. Other trademarks may be trademarks of their respective owners.

Preface.........................................................................................................................................................................................8 Revision history..........................................................................................................................................................................9 Product support....................................................................................................................................................................... 10

Contacting Dell Support................................................................................................................................................... 10

Chapter 1: Bare Metal Orchestrator overview............................................................................... 11 Bare Metal Orchestrator introduction........................................................................................................................... 11 Bare Metal Orchestrator architecture.......................................................................................................................... 12

Bare Metal Orchestrator components.................................................................................................................... 14 Validated hardware components....................................................................................................................................15 Validated hypervisors and operating systems.............................................................................................................16 License and firmware requirements...............................................................................................................................17 Firewall port requirements............................................................................................................................................... 17 Bare Metal Orchestrator infrastructure management features and functions...................................................18 Access and accounts........................................................................................................................................................ 19 Logging into the command line interface.....................................................................................................................19 Using the CLI as a remote client................................................................................................................................... 20

Chapter 2: Role-based access control..........................................................................................22 RBAC overview..................................................................................................................................................................22 Create a user with a user-profile YAML file................................................................................................................23 Generate a Private Key and Certificate Signing Request manually...................................................................... 24 Create a user without a user-profile YAML file......................................................................................................... 24 Get users............................................................................................................................................................................. 25 Edit a user........................................................................................................................................................................... 26 Delete a user.......................................................................................................................................................................26 View roles............................................................................................................................................................................26 Describe roles..................................................................................................................................................................... 27

Chapter 3: Managing sites...........................................................................................................28 Sites overview....................................................................................................................................................................28 Site creation workflow..................................................................................................................................................... 28 Viewing nodes.................................................................................................................................................................... 29 Creating remote sites.......................................................................................................................................................29 Viewing sites.......................................................................................................................................................................30 Editing sites........................................................................................................................................................................ 30 Reinitializing sites............................................................................................................................................................... 31 Deleting sites.......................................................................................................................................................................31

Chapter 4: Multi-tenancy............................................................................................................ 33 Multi-tenancy overview................................................................................................................................................... 33 Creating tenants................................................................................................................................................................34 Editing tenants...................................................................................................................................................................34 Viewing tenants................................................................................................................................................................. 35 Describing a tenant...........................................................................................................................................................35

Contents

Contents 3

Reinitializing tenants.........................................................................................................................................................36 Deleting tenants................................................................................................................................................................ 36

Chapter 5: Discovering devices................................................................................................... 38 Managed device discovery overview............................................................................................................................38 Default credentials for device discovery..................................................................................................................... 39

Edit default credentials.............................................................................................................................................. 39 Manual bulk server discovery.........................................................................................................................................39 DHCP configuration and automatic discovery........................................................................................................... 40 DHCP configuration options...........................................................................................................................................40

Enabling DHCP in an iDRAC...................................................................................................................................... 41 Onboard devices using ipscan........................................................................................................................................42 Show auto-discovered devices list............................................................................................................................... 43 Delete ipscan settings for a site.................................................................................................................................... 43

Chapter 6: Managing servers.......................................................................................................45 Servers overview...............................................................................................................................................................45 Create a server or multiple servers and update configurations.............................................................................45 Edit server configuration................................................................................................................................................. 46 View servers and server status......................................................................................................................................47 View server inventory.......................................................................................................................................................47 Reinitialize servers.............................................................................................................................................................47 Delete servers.................................................................................................................................................................... 48 Decommission servers......................................................................................................................................................49 Decommission disks..........................................................................................................................................................50 Edit iDRAC default factory settings............................................................................................................................. 50

Chapter 7: Provisioning hardware................................................................................................52 Hardware profiles overview............................................................................................................................................52 Hardware profile targeting..............................................................................................................................................53 Create hardware profiles.................................................................................................................................................53 Preview server configuration status............................................................................................................................ 54 Apply a hardware profile configuration........................................................................................................................55 Edit hardware profile configuration.............................................................................................................................. 56 View hardware profiles.................................................................................................................................................... 56 View hardware profile details......................................................................................................................................... 57 Delete hardware profiles..................................................................................................................................................57

Chapter 8: Managing server configurations................................................................................. 58 Power state configuration - servers.............................................................................................................................58 BIOS configuration - servers..........................................................................................................................................58 BMC configuration - servers..........................................................................................................................................59 Operating system deployment....................................................................................................................................... 60

Operating system deployment workflow - servers............................................................................................. 60 Create a media object................................................................................................................................................ 62 Create a driver media object.................................................................................................................................... 64 Upload images and binary files to the web server.............................................................................................. 65 Confirm available free space on the node.............................................................................................................66 Operating system attributes.....................................................................................................................................66

4 Contents

Verify operating system deployment - servers.................................................................................................... 66 Delete images and binary files from the web server...........................................................................................67 Operating system installation using PXE boot......................................................................................................67

Operating system upgrade - servers............................................................................................................................68 Firmware update................................................................................................................................................................70

Create a firmware media object...............................................................................................................................70 RAID configuration............................................................................................................................................................ 72

Delete the RAID volumes........................................................................................................................................... 73 Telemetry enablement......................................................................................................................................................73

Enable telemetry for a server................................................................................................................................... 73 Enable telemetry for servers.....................................................................................................................................74

Chapter 9: Managing web server................................................................................................. 76 View files on web server..................................................................................................................................................76 Upload files to the web server....................................................................................................................................... 76 Download files from web server.................................................................................................................................... 77 Delete files from the web server................................................................................................................................... 77

Chapter 10: Managing switches................................................................................................... 78 Switch overview................................................................................................................................................................ 78 Create a switch and update configurations................................................................................................................ 78 Edit switch configuration.................................................................................................................................................79 View switches and switch status.................................................................................................................................. 80 View switch inventory......................................................................................................................................................80 Reinitialize a switch.......................................................................................................................................................... 80 Delete a switch................................................................................................................................................................... 81 Onboard a Cisco switch in Bare Metal Orchestrator............................................................................................... 82

Register an NSO instance in Bare Metal Orchestrator...................................................................................... 83

Chapter 11: Managing switch configurations................................................................................84 Operating system deployment - Dell switch...............................................................................................................84 Operating system deployment workflow - Dell switch............................................................................................ 84 Create a media object - Dell switch..............................................................................................................................85 Verify operating system deployment - Dell switch................................................................................................... 86 License deployment workflow - Dell switch............................................................................................................... 86 Create a license media object - Dell switch................................................................................................................ 87 Operating system upgrade - Dell switch..................................................................................................................... 88 Firmware update - Dell switch....................................................................................................................................... 88 Create a firmware media object - Dell switch............................................................................................................ 89 Layer 2 VLAN configuration - Cisco switch............................................................................................................... 90 Layer 3 VLAN configuration - Cisco switch............................................................................................................... 90 Ethernet interface configuration - Cisco switch........................................................................................................91

Change the Ethernet interface port mode - Cisco switch................................................................................92 Set the IP address for the Ethernet interface - Cisco switch......................................................................... 93

Chapter 12: VMware TCP Stack deployment................................................................................ 94 Introduction........................................................................................................................................................................ 94 Create configuration files................................................................................................................................................95 Deploying a stack.............................................................................................................................................................. 96

Contents 5

Reinitializing a stack..........................................................................................................................................................97 Grow a stack (new domain)........................................................................................................................................... 98 Grow a stack (existing domain).....................................................................................................................................98 Get stack.............................................................................................................................................................................99 Describe stack....................................................................................................................................................................99 Edit a stack configuration............................................................................................................................................... 99 Delete a stack instance....................................................................................................................................................99

Chapter 13: VMware TKG deployment......................................................................................... 101 Introduction....................................................................................................................................................................... 101 TKG deployment workflow............................................................................................................................................ 102 Create the configuration files for TKG deployment................................................................................................ 102 Create the templates for TKG deployment............................................................................................................... 103 Deploy TKG clusters....................................................................................................................................................... 104 Deploy TCP stack and TKG clusters...........................................................................................................................105 Delete TKG templates.................................................................................................................................................... 106 Delete TKG clusters........................................................................................................................................................ 106 Reinitialize a stack to redeploy TKG............................................................................................................................107

Chapter 14: Wind River Cloud Platform stack deployment.......................................................... 108 Wind River Cloud Platform introduction.................................................................................................................... 108 Wind River Cloud Platform deployment workflow...................................................................................................109 Create servers for Controller 1-n and Worker 0-n components.......................................................................... 109 Create the stack configuration files............................................................................................................................. 111 Deploy the Wind River Cloud Platform stack............................................................................................................. 111 Delete the Wind River Cloud Platform stack............................................................................................................. 113

Chapter 15: Backing up and restoring clusters............................................................................ 114 Backup and restore overview........................................................................................................................................ 114 Backup the cluster........................................................................................................................................................... 115 Restore a cluster from a backup file............................................................................................................................115 Schedule cluster backups...............................................................................................................................................116 Stop scheduled backups................................................................................................................................................. 117 Change the backup storage location........................................................................................................................... 117 Create backup storage location secret....................................................................................................................... 118

Chapter 16: Monitoring Bare Metal Orchestrator........................................................................120 Logging...............................................................................................................................................................................120 Adding a search index to OpenSearch dashboard....................................................................................................121 Metrics reports.................................................................................................................................................................124 Events.................................................................................................................................................................................125

Subscribe an event.................................................................................................................................................... 125

Appendix A: YAML schema......................................................................................................... 128 YAML objects and common fields............................................................................................................................... 128 Metadata............................................................................................................................................................................129 YAML field specifications...............................................................................................................................................129

Site field definitions...................................................................................................................................................129 DHCP fields................................................................................................................................................................. 130

6 Contents

Server and hardware profile field definitions...................................................................................................... 132 Telemetry field definitions........................................................................................................................................170 Switch field definitions.............................................................................................................................................. 171 Media field definitions............................................................................................................................................... 175 Driver media field definitions................................................................................................................................... 176 User field definitions..................................................................................................................................................176 Firmware media field definitions.............................................................................................................................176 Tenant field definitions............................................................................................................................................. 177 Event field definitions................................................................................................................................................177 Stack field definitions................................................................................................................................................178

YAML status fields........................................................................................................................................................... 181 Stack status fields........................................................................................................................................................... 182

Appendix B: Tenant profile YAML file sample............................................................................. 183 Sample tenant YAML file............................................................................................................................................... 183

Appendix C: Switch YAML file sample........................................................................................ 184 Sample switch YAML file............................................................................................................................................... 184

Appendix D: Server and hardware profile YAML file samples...................................................... 185 Server and hardware profile YAML file samples...................................................................................................... 185 Sample server YAML file................................................................................................................................................185 Sample hardware profile YAML file............................................................................................................................. 187 Sample operating system deployment YAML files - ESXi .....................................................................................188 Sample operating system deployment YAML files - openSUSE ......................................................................... 195 Sample operating system deployment YAML files - Red Hat Enterprise Linux............................................... 203 Sample operating system YAML files - Wind River Cloud Platform...................................................................208 Sample baseline profile YAML file................................................................................................................................210

Appendix E: Server and profile telemetry YAML file samples...................................................... 212 Sample server telemetry YAML file.............................................................................................................................212 Sample profile telemetry YAML file.............................................................................................................................216

Appendix F: Site Configuration YAML Examples......................................................................... 221 Sample DHCP configuration YAML file...................................................................................................................... 221

Appendix G: Stack deployment YAML example...........................................................................223 Sample VMWare TCP stack deployment YAML file............................................................................................... 223 Sample TKG deployment YAML file............................................................................................................................224 Sample Wind River Cloud Platform stack deployment YAML file....................................................................... 226

Contents 7

Preface

Purpose This guide describes how you can use the command line interface to comprehensively manage the infrastructure life cycle.

Audience This guide is primarily intended for administrators who are responsible for managing the entire life cycle of the hardware infrastructure in their data centers by using Bare Metal Orchestrator.

Disclaimer This guide may contain language that is not consistent with Dell Technologies current guidelines. Dell Technologies plans to update the guide over subsequent future releases to revise the language accordingly.

8 Preface

Revision history

This revision history lists major changes to this document.

Table 1. Revisions

Date Release Description

September 2022 1.3 Statistics collection in telemetry reports changed to metrics collection in metric reports Telemetry enablement and metrics collection supported Custom driver installation updated with validation provision The existing functions supported through global MinIO S3 is updated to web server DNS and NTP settings for ESXi added

July 2022 1.2 Switch support added and related structural changes made throughout the guide High availability updates with GlusterFS distributed storage support and more load

balancers PXE Boot support for operating system installation added Additional BIOS attributes added with support for HPE and Supermicro S150 RAID Controller support for virtual volumes added Bare Metal Orchestrator Events added ipscan feature for auto-discovery and on-boarding of devices on a particular subnet for

a site

OpenSUSE Leap 15.3 support

Web server support and related TCP stack deployment changes added iDRAC factory default settings configuration added Optimizing firmware installation and custom driver installation functions added for

operating system deployment for servers Minor changes across the guide, including updated YAML file samples and field definitions

in the Appendices

March 2022 1.1 Access and account topic added to the overview chapter and how to use CLI as a remote client

PowerEdge R740 rack server support added General updates to the role-based access control chapter High availability support with the Load Balancer URL login step added across the guide Server and hardware profile targeting changes and server status preview added iDRAC credentials for automatic server discovery added Instructions to upload binaries and images to Bare Metal Orchestrator added ESXi upgrade procedure added VMWare TKG stack deployment support Wind River Cloud Platform deployment support BOSS card support BMC updates to reset password and update users Minor changes across the guide, including updated YAML file samples and field definitions

in the appendices

November 2021 1.0 Inaugural release

Revision history 9

Product support Resources to help you to provision the infrastructure and fix problems.

Documentation You can find these Bare Metal Orchestrator documents on the Bare Metal Orchestrator Documentation site:

Bare Metal Orchestrator Release Notes Bare Metal Orchestrator Installation Guide Bare Metal Orchestrator Command Line Interface User's Guide Bare Metal Orchestrator Web User Interface Guide Bare Metal Orchestrator Command Line Interface Reference Guide Bare Metal Orchestrator Network Planning Guide Bare Metal Orchestrator API Guide

The Bare Metal Orchestrator API Guide is on the Dell Technologies Developer Portal site.

Bare Metal Orchestrator product support page Bare Metal Orchestrator Product Support Overview

Where to get help The Dell Technologies Support site (https://www.dell.com/support) contains important information about products and services including drivers, installation packages, product documentation, knowledge base articles, and advisories.

A valid support contract and account might be required to access all the available information about a specific Dell Technologies product or service.

Dell Technologies Support contact information Dell provides several online and telephone-based support and service options. Availability varies by country or region and product, and some services may not be available in your area.

NOTE: If you do not have an active Internet connection, you can find contact information from your purchase invoice,

packing slip, bill, or Dell product catalog.

Call 1-800-782-4362 or the support phone number for your country or region. Go to Dell Support to find the support phone number for your country or region. Tell the support person that you want to open a service request for Bare Metal Orchestrator. Give the support person your Product ID and a description of the problem.

You can also go to Dell Support and search for Bare Metal Orchestrator. The product support page requires you to sign in and enter your Product ID.

Contacting Dell Support How to contact your Dell account representative, Dell technical support, or Dell customer service.

Steps

1. Go to Dell Support and select a support category.

2. From the Choose a Country/Region list, verify your country or region. Then, select the appropriate service or support link.

10 Product support

Bare Metal Orchestrator overview

Topics:

Bare Metal Orchestrator introduction Bare Metal Orchestrator architecture Validated hardware components Validated hypervisors and operating systems License and firmware requirements Firewall port requirements Bare Metal Orchestrator infrastructure management features and functions Access and accounts Logging into the command line interface Using the CLI as a remote client

Bare Metal Orchestrator introduction Bare Metal Orchestrator is an infrastructure management solution that enables Communications Service Providers (CSPs) to rapidly provision, manage, and monitor their infrastructure.

Bare Metal Orchestrator provides different interfaces for end-to-end infrastructure management and monitoring. Bare Metal Orchestrator works with the Baseboard Management Controller (BMC) and supports the following features:

NOTE: The term device includes servers and switches unless otherwise stated.

Role-based access control

Manages users, their assigned roles, and Bare Metal Orchestrator access. You can provide users with specific access and privileges that are allocated to them according to their assigned roles.

Site management Manages sites and associated devices.

Multitenancy Creates and manages multiple tenants.

DHCP support Manages the DHCP configuration.

Discovering devices

Discovers servers and switches. Collects inventory. You can also discover devices by scanning IP addresses.

Server management

Manages servers. Monitors the health of on-boarded servers.

Switch management

Manages Dell and Cisco switches. You can deploy an operating system and perform firmware updates.

Provisioning hardware

Uses hardware profile templates to provision multiple servers. You can update firmware versions, and different attributes such as Basic Input Output System (BIOS), BMC, Redundant Arrays of Inexpensive Disks Controller (RAID), and so on.

Operating system deployment

Installs an operating system. BIOS and BMC attributes were added to support different operating systems.

Power control Performs various actions on servers such as powering them on or off.

Metrics collection

Provides metrics reports with BMC statistics for server health monitoring.

Telemetry enablement

Enables telemetry collection from Dell, HPE, and Supermicro servers. Configures telemetry attributes to collect telemetry data.

Events subscription

Generate events that help you to respond to state changes in the components such as Server controller, Hardware controller, Tenant controller and Site controller.

1

Bare Metal Orchestrator overview 11

VMware Telco Cloud Platform (TCP) stack

Deploys cloud-native and virtual network functions on 5G networks.

Wind River Cloud Platform deployment

Deploys the Wind River Cloud Platform stack and the server components of the cloud cluster that consist of the Central Cloud site.

Backup and restore

Schedules and performs manual backups of the cluster.

VMware Tanzu Kubernetes Grid (TKG) deployment

Deploys the management, shared services, and workload clusters on a TCP stack.

User management

Allows you to create and delete users.

Logging Gathers system logs that you can generate and view.

Factory reset Provides a way to restore a component to factory settings.

Media management

Specifies a switch or server media type for firmware, operating system, and license media.

Bare Metal Orchestrator architecture Bare Metal Orchestrator has a distributed architecture that is designed to manage large numbers of geographically distributed servers. Deploy the Bare Metal Orchestrator cluster as a single cluster or in a high availability (HA) configuration with two redundant HA nodes for enhanced reliability and performance.

The following figure illustrates the architecture of a single-node Bare Metal Orchestrator cluster:

Figure 1. Dell Technologies Bare Metal Orchestrator single-node cluster architecture

The Bare Metal Orchestrator architecture consists of:

User interfacesBare Metal Orchestrator provides a web-based User Interface (UI), a Command Line Interface (CLI) client, and an Application Programming Interface (API) to perform remote infrastructure management tasks. All requests and actions from these interfaces reach the Global Controller (GC).

12 Bare Metal Orchestrator overview

Global ControllerThe Global Controller is a fully contained management cluster that is deployed at the central office. The Global Controller can manage sites and servers that are associated with it. It constitutes core components and site components. For more information, see Bare Metal Orchestrator components.

Bare Metal Orchestrator high availability

Bare Metal Orchestrator supports high availability (HA) to meet the demands of continuous operation deployments. High availability assures peak performance during periods of compute-intensive operation and reduces the risk of downtime that can occur because of a single point of failure.

With high availability, the Bare Metal Orchestrator OVA is deployed on a five-node HA cluster by default. Global Controller services are deployed on the first node, which is a fully functional, scalable Bare Metal Orchestrator cluster to which two HA nodes are added. The two HA nodes function as a redundant pair for HA failover and must be reachable from the GC.

The Global Controller site data and services are fully replicated on the two HA nodes. A keepalive is used to monitor the availability of services on each node in the control plane. An automatic failover is triggered when a node failure is detected.

A redundant pair of Load Balancers provides highly reliable management access for the Bare Metal Orchestrator Web UI, CLI, and API using a virtual IP address (VIP). The VIP must be set to an available IP address on the same subnet as the two Load Balancers.

Each Load Balancer is considered a node in the five-node HA cluster and must be reachable from the GC. These servers must support NGINX.

Load Balancer key tasks:

Setting the virtual IP address (VIP) of the Load Balancers to an Available IP address in the same subnet as the two Load Balancers.

Directing front-end traffic to the three control plane nodes for HA redundancy Managing load distribution Managing control planes

The following figure shows the architecture of a five-node HA deployment with distributed storage. The five-node HA cluster consists of three control plane nodes and the redundant pair of Load Balancers. All nodes and the distributed storage volumes are active.

Figure 2. Five-node HA cluster with distributed storage

GlusterFS provides distributed file storage for the Global Controller and the two redundant HA nodes in the control plane cluster. The distributed storage volumes replicate the Bare Metal Orchestrator cluster data when using PersistentVolumeClaim (PVC).

Bare Metal Orchestrator overview 13

Distributed storage can be deployed locally in the three-node control plane cluster or externally. For external storage deployments, the VMs hosting the storage volumes must be reachable by the HA cluster. A minimum of three storage nodes are required.

NOTE: The remote site uses local-path as the storage class.

Observe the following:

You cannot upgrade a single-node Bare Metal Orchestrator deployment to a five-node HA deployment. When using a local copy of the CLI as a remote client, you must specify the VIP of the server that is hosting the Load

Balancers in the users configuration file. If any two control plane nodes in a high availability deployment fail simultaneously, you must reboot the Global Controller

node before high availability functionality can resume. Using the CLI, log in to the Global Controller as installer and enter reboot.

To learn more about high availability, see the Bare Metal Orchestrator Installation Guide.

For more information about using the CLI, see Logging into the command line interface.

Bare Metal Orchestrator components

Bare Metal Orchestrator consists of core components and the site components that communicate with the BMC for provisioning the remote infrastructure.

Core components

The core components of the Global Controller node are responsible for managing Bare Metal Orchestrator. The functions of the core components are described below:

API serverallows all components in the Bare Metal Orchestrator cluster to communicate with one another through the API server.

Cert-manager controllerissues and manages certificates in Bare Metal Orchestrator. CLIa CLI client to interact with the API server. ETCDa database that stores configuration details. Each component in the cluster uses these configurations. The database

is accessible only through the API server. Web serverstores the ISO image for operating system deployment and firmware upgrades. Site controllercreates and manages all sites. Web user interfacea browser-based application to manage Bare Metal Orchestrator.

Common site components

Site components are responsible for connecting to bare metal devices, discovering devices, fetching inventory, and managing devices. Site components that function on both the Global Controller and worker sites are described below:

Discovery managerautomatically discovers devices that are assigned DHCP IP addresses. DHCP relayforwards DHCP packets to an external DHCP server. DHCP serverassigns the Dynamic Host Configuration Protocol (DHCP) IP to the discovered devices. Event routerallows Bare Metal Orchestrator to publish events to subscribed consumer channel. ILO-sku-packallows Bare Metal Orchestrator to onboard HPE iLO servers. Web serverhosts the images for operating system deployment, operating system updates, and firmware updates. Nso-sku-packallows Bare Metal Orchestrator to communicate with NSO to onboard and manage Cisco switches. Redfish Stock Keeping Units (SKU) packis a Remote Procedure Call (RPC) based micro service that allows Bare Metal

Orchestrator to manage hardware from different vendors. SKU packs connect with bare metal servers using the Redfish protocol.

SDN controllercreates, views, and manages Cisco switches in the Network Services Orchestrator (NSO) mode. Server controllercreates, views, and manages servers. Stack-sku-packallows Bare Metal Orchestrator to deploy VMware TCP stack and TKG. Supermicro-sku-packallows Bare Metal Orchestrator to onboard Supermicro servers. Switch controllercreates, views, and manages Dell switches in both Open Network Install Environment (ONIE) and

Network Operating System (NOS) modes.

14 Bare Metal Orchestrator overview

Switch-sku-packallows Bare Metal Orchestrator to connect to the Dell switch using SSH. Windriver-sku-packallows Bare Metal Orchestrator to manage the Wind River Cloud Platform stack.

Global Controller site components

These site components only function on the Global Controller:

API proxya local API proxy that allows the Global Controller to communicate with Dell financial services for Utility Configuration Collector (UCC) licensing and billing purposes.

Hardware controllermanages the hardware profiles, searches for all servers that match the defined specifications, applies the settings to the servers, and updates the status to the API server. This provides a consistent method for provisioning and configuring servers.

local-registrylocal storage for Docker images. Load balancerdirects front-end traffic to the three control plane nodes for high availability (HA) redundancy. The load

balancer also provides management access for the Web UI, CLI, and API using a virtual IP address (VIP) when Bare Metal Orchestrator HA is configured.

OpenSearch dashboardinterface used to search site logs that are collected from each site in the Bare Metal Orchestrator cluster.

PXE-serviceallows operating system installation in Bare Metal Orchestrator. Stack deployerdeploys stacks such as VMware TCP and Wind River Cloud Platform to a cluster of selected servers. Tenant controllermanages tenants.

Validated hardware components Bare Metal Orchestrator is a multi-vendor platform. The following hardware components have been validated for this release of Bare Metal Orchestrator:

Table 2. Dell PowerEdge 15th generation servers

Validated model Supported BIOS version Supported iDRAC firmware version

Limitations

PowerEdge R6515 Rack Server

2.3.6 5.00.10.20 Only AMD MILAN CPUs are supported.

PowerEdge XE2420 Edge Server

2.12.3 None

PowerEdge R650 Rack Server

1.3.8

PowerEdge R750 Rack Server

PowerEdge XR11 Rack Server

Excluding HBA series controllers

PowerEdge XR12 Rack Server

Table 3. Dell PowerEdge 14th generation servers

Validated model Supported BIOS version Supported iDRAC firmware version

Limitations

PowerEdge R640 Rack Server

2.12.2 5.00.10.20 None

PowerEdge R740 Rack Server

PowerEdge R740xd Rack Server

Bare Metal Orchestrator overview 15

Table 4. Dell switches

Validated model Supported NOS version Supported firmware version Limitations

Dell PowerSwitch S5232F-ON 10.5.2.0-10.5.3.4 onie-firmware-x86_64- dellemc_s5200_c3538- r0.3.40.5.1-20

None

Dell PowerSwitch S5248F-ON

Dell PowerSwitch S5212F-ON

Dell PowerSwitch S5224F-ON

Table 5. Cisco switch

Validated model Supported version Limitations

Cisco Nexus 9396PX NX-OS 7.0(3)I5(2) None

Table 6. iDRAC

iDRAC model Limitations

Integrated Dell Remote Access Controller 9 (iDRAC9) None

Table 7. Supermicro

Supermicro model Limitations

SYS-1019P-FRN2T None

Table 8. HPE

HPE model Limitations

HPE Edgeline EL8000t None

Table 9. RAID types

RAID Controller Hardware Supported RAID types

Single PERC H730P RAID 0, 1, 5, and 10

Single PERC H740P

Single PERC H755

Single PERC H745 Front (Embedded)

Single PERC H750P

Validated hypervisors and operating systems

You can install these hypervisors and operating systems on servers that Bare Metal Orchestrator manages.

Table 10. Validated operating systems and hypervisors for servers

Hypervisor or operating system Versions

openSUSE Leap 15.3 (openSUSE-Leap-15.3-3-DVD-x86_64- Build38.1-Media.iso)

Red Hat Enterprise Linux 8.4 (rhel-8.4-x86_64-dvd.iso)

8.5 (rhel-8.5-x86_64-dvd.iso)

VMware ESXi (hypervisor) 6.7 u3, 7.0 u1, 7.0 u2, and 7.0 u3

Wind River Cloud Platform host operating system wind-river-cloud-platform-host- installer-21.05-b58.iso

16 Bare Metal Orchestrator overview

Table 11. Validated operating systems for switches

Operating system Versions

Dell OS10 10.5.2.0-10.5.3.4

Cisco NX-OS 7.0(3)I5(2)

You can install these operating systems on worker nodes that Bare Metal Orchestrator creates.

Table 12. Validated operating systems for worker nodes

Operating system Versions

Debian 11

Ubuntu Server 19.10, 20.04 LTS

License and firmware requirements The following table describes the required licenses and firmware versions for each BMC.

Table 13. Required licenses and firmware versions

Vendor License Firmware version

iDRAC Datacenter 5.00.00.00 or higher

Supermicro SFT-OOB-LIC SFT-DCMS-SINGLE

01.73.12 or higher

HPE iLO iLO Advanced 2.65

Table 14. Firmware updates for HPE iLO servers

Firmware Supported format

iLO 5 .bin

Chassis .bin

BIOS .signed.flash

Table 15. Firmware updates for Supermicro servers

Firmware Supported format

BMC .bin

BIOS

Firewall port requirements

Port requirements

If you are using a firewall, you must open all ports that are listed in the following table to ensure that Bare Metal Orchestrator functions correctly. The following table lists the ports that Bare Metal Orchestrator uses.

Table 16. Port requirements

Port Required on Description

22 Global Controller (GC) and remote sites

Used for SSH access to run Ansible playbooks and for GlusterFS distributed storage.

Bare Metal Orchestrator overview 17

Table 16. Port requirements (continued)

Port Required on Description

67 Global Controller (GC) and remote sites

Used by the TFTP server. Optionally open on the remote site if PXE is used.

69 Global Controller (GC) and remote sites

Used when DHCP is configured. Optionally open on the remote site if PXE is used.

123 Remote site Used for NTP synchronization.

441 GC site Used by the global NGINX to store operating systems and firmware images.

442 GC site Used by the internal NGINX.

443 (HTTPS) and 80 (HTTP)

GC site Used by the web user interface.

2379 (TCP) GC site Used by the ETCD client for data access and management.

2380 (TCP) GC site Used by the ETCD peer for data access and management.

5047 GC site Used by localregistry.io as a docker container repository.

6443 (TCP) GC site Used for communicating with remote sites and the application programming interface (API).

8081 GC site Used for setting up remote sites.

8082 GC site Heketi CLI port.

8472 (UDP) GC and remote sites Used for Flannel VXLAN.

9345 (TCP) GC site Used for API communications.

10250 GC and remote sites Used by the kubelet node agent to register the node and manage containers.

30500 GC site Used by the global MinIO S3 to store the backups.

32569 GC site Used for Heketi pod to communicate with server.

Bare Metal Orchestrator infrastructure management features and functions This section lists the common infrastructure management functions that are available in Bare Metal Orchestrator.

Table 17. Infrastructure management features and functions

Feature Function

Automatic discovery Automatically discovers servers or switches using DHCP and collects inventory.

Backup and restore Schedule and perform manual backups of the cluster.

DHCP support Manage DHCP configuration.

Events Generate events that help you respond to state changes in the components such as Server controller, Hardware controller, Tenant controller, and Site controller.

Logs View collected logs in OpenSearch.

Manual discovery Create servers to add servers that are already deployed in your environment and collect their inventory.

Media management Manage firmware, operating system, or license media.

18 Bare Metal Orchestrator overview

Table 17. Infrastructure management features and functions (continued)

Feature Function

Multitenancy Create and manage tenants. You can also add or remove users and request or release servers or switches from or to the tenant.

Operating system deployment Deploy an operating system.

Power control Perform various actions on servers such as power on or off.

Provisioning hardware Provision multiple servers with hardware profile templates. You can update firmware versions and different attributes such as BIOS, BMC, RAID settings, and so on.

RBAC Manage users, their assigned roles, and provide Bare Metal Orchestrator access. You can grant users with specific access and privileges that are allocated to them according to their assigned role.

Server management Create, view, update and delete servers, and auto-discovery.

Switch management Create, view, update and delete switches, and auto-discovery.

Site management Create and manage sites.

TCP stack deployment Deploy TCP cloud stack software.

TKG deployment Deploy TKG clusters to run application workloads.

Wind River Cloud Platform deployment Deploy Wind River Cloud Platform stack and cloud component clusters.

Metric collection Collect a snapshot of selected BMC statistics in metric reports for server health monitoring.

User management Create or delete users.

View inventory View inventory of on-boarded devices.

Access and accounts After Bare Metal Orchestrator is initially deployed, you need to create role-based accounts for your users to access, view, or configure the system using the Bare Metal Orchestrator web UI or the CLI.

For initial system deployments, you can create a Global Admin account using the Command Line Interface (CLI) on the Bare Metal Orchestrator VM with the default dell user account. To access the CLI, see Logging into the command line interface.

We recommend creating a Global Admin account as soon as possible and using that to configure Bare Metal Orchestrator instead of the default dell user account. A copy of the Private Key and Certificate Signed Request (CSR) user config YAML file is required to access the web UI and to use the CLI client remotely. The Private Key and CSR are generated when your user account is created. For information about user roles, creating user accounts, and your user config file, see RBAC overview.

Logging into the command line interface

Prerequisites

An Ethernet connection to the Bare Metal Orchestrator virtual machine using SSH or Serial Over LAN (SOL) is required.

To remotely login using a local version of the CLI, you need a downloaded copy of the Bare Metal Orchestrator CLI installed on your local Linux machine and a copy of your user config file for authentication.

NOTE:

Bare Metal Orchestrator overview 19

The recommendation is to create a Global Admin account as soon as possible and use that to configure Bare Metal

Orchestrator instead of using the default dell user account. For information about creating user accounts, see the RBAC

overview. To log into the web UI, see the Bare Metal Orchestrator Installation Guide.

About this task

The CLI is a text-driven interface that is used for most management tasks. You can enter bmo --help at any time for help. For more about CLI commands, see the Bare Metal Orchestrator CLI Reference Guide.

Steps

1. Open your SSH client and enter the IP address or the hostname of the Bare Metal Orchestrator virtual machine (VM). For high availability configurations, establish a CLI session on the Load Balancer for the Bare Metal Orchestrator cluster.

2. When prompted, enter the default Global Admin username dell and the password. The default password is Dell1234.

NOTE: We recommend that you change the default dell user account password using the $ passwd Linux

command as soon as possible and record the new password for future reference. Contact your Bare Metal Orchestrator

administrator for account information.

Using the CLI as a remote client

Prerequisites

The user's configuration YAML file and the Certified Signed Request (CSR) must already be created and you need the directory location of the user configuration file.

The IP address of the Linux machine that will host a local copy of the Bare Metal Orchestrator CLI. For a high availability (HA) deployment, you need the IP address of the load balancer.

About this task

You can use the SCP command to create a copy of the Bare Metal Orchestrator CLI to your local Linux machine. Use this copy to remotely access, view, and configure the cluster. The private key and CSR user config YAML file that was generated when your user account was created, is required to authenticate the remote session.

Steps

1. Open a CLI session on the Bare Metal Orchestrator VM using the default dell user account. For high availability configurations, establish a CLI session on the Load Balancer for the Bare Metal Orchestrator cluster.

2. Run the following command to open the user's config YAML file for editing: cat .yaml For example:

cat ryanconfig.yaml

3. In the user's config YAML file, ensure that the server IP address matches the IP address of the Bare Metal Orchestrator VM. If performing a high availability deployment, enter the IP address of the server that is hosting the Load Balancer.

The following shows a sample snippet of a user's config YAML file.

NOTE: The server IP address appears at the beginning and is highlighted in bold.

apiVersion: v1 clusters: - cluster: certificate-authority-data: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUJlVENDQVIrZ0F3SUJBZ0lCQURBS0JnZ3Foa2VkVoXc3B CRlE0bnYyM1pZSGcxRXBhR3RKeVQ3SU9UCi0tLS0tRU5EIENFUlRJRklDQVRFLS0tLS0K server: https://100.10.1.0:6443 name: metalweaver-cluster contexts: - context: cluster: metalweaver-cluster

20 Bare Metal Orchestrator overview

user: ryan name: metalweaver-cluster current-context: metalweaver-cluster kind: Config preferences: {}

4. Copy the user's config file to the destination host machine using the scp command and enter the login password when prompted. For example: scp ryanconfig.yaml @ The user config file downloads to the destination host machine. You can move the file to a convenient directory location.

5. Copy the Bare Metal Orchestrator CLI to the destination host machine using the scp command and enter the password when prompted. For example: scp /usr/local/bin/bmo @ The Bare Metal Orchestrator CLI downloads to the destination host machine.

6. Access the Bare Metal Orchestrator with the user config file. Run the following command: export KUBECONFIG=~/ .yaml

7. Enter bmo commands from the prompt. For example, if you copied the CLI to the local bin on the destination machine, run: bmo get site

Bare Metal Orchestrator overview 21

Role-based access control

Topics:

RBAC overview Create a user with a user-profile YAML file Generate a Private Key and Certificate Signing Request manually Create a user without a user-profile YAML file Get users Edit a user Delete a user View roles Describe roles

RBAC overview Role Based Access Control (RBAC) lets you securely manage user access to Bare Metal Orchestrator by assigning permissions based on the role of the user . The Global Admin and Global Reader roles have clearly defined permissions that determine the level of access to configure the cluster, manage tenants and users, and view cluster data.

You assign the user a role when you create their user account using the Command Line Interface (CLI). A unique userconfig.yaml file is generated when you create the role-based user account. The user config file contains either a username and password combination or a secure token.

Each user needs a copy of their generated userconfig.yaml file to authenticate when logging in to the Bare Metal Orchestrator web UI and when using a local copy of the CLI as a remote client. If the user config file is lost, a new one must be generated and provided to the user.

NOTE: For initial system deployments, you can create a role-based Global Admin account when you use the default dell user account with the CLI that is running on the Bare Metal Orchestrator virtual machine. For more information, see Access

and accounts.

The following operations can be performed:

Create, view, and delete a user Manually generate a Private Key and CSR View and describe roles

Roles

The following table describes the available user roles and the assigned permissions for each role.

NOTE: If a user is assigned multiple roles, the role with highest privileges is applied.

Table 18. Roles and permissions

Role Permissions

Global Admin Read and write privileges to all Bare Metal Orchestrator resources across all tenants, clusters, pods, servers, sites, hardware profiles, and so on.

Can create, edit, and delete users.

Can assign and edit user roles.

Cannot create, edit, or delete clusters.

2

22 Role-based access control

Table 18. Roles and permissions (continued)

Role Permissions

Global Reader Read-only access to all Bare Metal Orchestrator resources across all tenants, clusters, pods, servers, sites, hardware profiles, and so on.

Can view all other users.

Cannot create, edit, or delete clusters.

Example user profile files used to create user accounts

Before generating the user's config file for role-based authentication, you need to create a user profile YAML file that defines the user's role. You can see a sample user profile file in the samples/user-profile directory.

The following example JohnSmith.yaml user profile file is used to create a user account and generate the user config file for John Smith with the Global Reader role.

name: JohnSmith email: john_smith@dell.com country: USA city: Denver organization: Dell orgUnit: BDC province: Co roles: - global-reader

The following example Kyle.yaml user profile file is used to create a user account and generate the user config file for Kyle with the Global Admin role.

name: Kyle email: kyle@dell.com country: USA city: Denver organization: Dell orgUnit: BDC province: Co roles: - global-admin

The directory location of the user's profile file on the Bare Metal Orchestrator VM is where the user's config file is generated.

NOTE: If you combine multiple users in a single profile YAML file, a separate config YAML file is generated for each user.

Create a user with a user-profile YAML file

Prerequisites

A user-profile YAML file that defines the role and profile information for the user is saved to a directory location on the Bare Metal Orchestrator VM, see RBAC overview.

About this task

To create a role-based user account in Bare Metal Orchestrator and automatically generate a Private Key and CSR for the user:

Steps

1. Establish a CLI session on the Bare Metal Orchestrator VM. For high availability configurations, establish a CLI session using the virtual IP (VIP) of the Load Balancers for the Bare Metal Orchestrator cluster.

2. Run the following command:

bmo create user -f .yaml > .yaml

Role-based access control 23

For example:

bmo create user -f ryan.yaml > ryanconfig.yaml

NOTE: For Supermicro and HPE iLO servers, usernames cannot contain special characters.

Results

A new user account is created and the user config file is generated.

Generate a Private Key and Certificate Signing Request manually

Prerequisites

You must manually generate a Private Key and CSR before creating a user without a user profile YAML file.

About this task

To manually generate a Private Key and CSR for a specified user:

Steps

1. Establish a CLI session on the Bare Metal Orchestrator VM. For high availability configurations, establish a CLI session using the virtual IP (VIP) of the Load Balancers for the Bare Metal Orchestrator cluster.

2. Run the following two commands:

openssl genrsa -out myuser.key 2048 openssl req -new -key myuser.key -out myuser.csr

The Private Key and CSR are generated for the specified user.

3. Press Enter and ignore all prompts, until the following prompt appears:

Common Name (e.g. server FQDN or YOUR name):

4. Enter the name of the user and press Enter.

5. Ignore all prompts.

6. Run the following command:

ls Ensure the myuser.key and the myuser.csr files are successfully generated.

7. You can now create the user without a user-profile YAML file. For more information, see Create a user without a user-profile YAML file.

Create a user without a user-profile YAML file

Prerequisites

You must manually generate a private key and CSR before creating a user config file without a user-profile YAML file. For more information, see Generate a Private Key and Certificate Signing Request manually.

About this task

To create a Bare Metal Orchestrator user config file without a user-profile YAML file:

24 Role-based access control

Steps

1. Establish a CLI session on the Bare Metal Orchestrator VM. For high availability configurations, establish a CLI session using the virtual IP (VIP) of the Load Balancers for the Bare Metal Orchestrator cluster.

2. Run the following command:

bmo create user --roles=global-reader --client-key=./myuser.key --client- certificate=./myuser.csr >

NOTE: The must match the entered in the Common Name prompt, while generating the

user Private Key and CSR. For more information, see Generate a Private Key and Certificate Signing Request manually.

Common Name (e.g. server FQDN or YOUR name):

For example:

bmo create user ryan --roles=global-reader --client-key=./myuser.key --client- certificate=./myuser.csr > ryanconfig.yaml

The user config file is generated.

NOTE: Create a backup of any pre-existing user config file before proceeding to next step.

3. You can now perform one of the following options to use the user config file for role-based access to the web UI and for CLI operations: Recommended: Add the generated user config file in the home directory.

For example:

/home/username/.kube/ryanconfig

Export the user config file to a directory location on your local Linux machine to use for authentication when using the Bare Metal Orchestrator CLI as a remote client.

For example:

export KUBECONFIG=" "

When using the Bare Metal Orchestrator CLI as a remote client, append --kubeconfig .yaml in all CLI commands.

For example:

export KUBECONFIG=" "

For information about using the Bare Metal Orchestrator CLI as a remote client, see Using the CLI as a remote client.

Get users

About this task

To view detailed information about the current users in Bare Metal Orchestrator:

Steps

1. Establish a CLI session on the Bare Metal Orchestrator VM. For high availability configurations, establish a CLI session using the virtual IP (VIP) of the Load Balancers for the Bare Metal Orchestrator cluster.

2. Run the following command:

bmo get users The users created with Global Admin and Global Reader roles are displayed. For more information about the fields, see User field definitions.

Role-based access control 25

The following is an example output for the bmo get users command.

NAME ROLES kyle global-admin jerry global-reader

Edit a user

Steps

1. Establish a CLI session on the Bare Metal Orchestrator VM. For high availability configurations, establish a CLI session using the virtual IP (VIP) of the Load Balancers for the Bare Metal Orchestrator cluster.

2. Edit the .yaml and update the required attributes using Vim or a similar editor.

NOTE: You can only edit the user role.

3. Save the file and quit the editor.

4. To edit the user, run the following command:

bmo edit user --file .yaml

Delete a user

About this task

Delete a specific user and the associated user profile.

Steps

1. Establish a CLI session on the Bare Metal Orchestrator VM. For high availability configurations, establish a CLI session using the virtual IP (VIP) of the Load Balancers for the Bare Metal Orchestrator cluster.

2. To delete a user, run the following command:

bmo delete user For example:

bmo delete user john-smith

NOTE: Repeat these steps to delete multiple users.

View roles

About this task

To view detailed information about the available roles in Bare Metal Orchestrator:

Steps

1. Establish a CLI session on the Bare Metal Orchestrator VM. For high availability configurations, establish a CLI session using the virtual IP (VIP) of the Load Balancers for the Bare Metal Orchestrator cluster.

2. Run the following command:

bmo get roles The following is an example output:

global-admin global-reader

26 Role-based access control

Describe roles

About this task

View detailed information about a specific role in Bare Metal Orchestrator.

Steps

1. Establish a CLI session on the Bare Metal Orchestrator VM. For high availability configurations, establish a CLI session using the virtual IP (VIP) of the Load Balancers for the Bare Metal Orchestrator cluster.

2. Run the following command:

bmo describe role For example:

bmo describe role global-admin

Detailed information about the access and capabilities assigned to the specified role are listed.

Role-based access control 27

Managing sites

Topics:

Sites overview Site creation workflow Viewing nodes Creating remote sites Viewing sites Editing sites Reinitializing sites Deleting sites

Sites overview A site is a physical location where devices are deployed.

The following sites are used in Bare Metal Orchestrator:

Global Controller site: The GC, or GC site, is the default site that is created when Bare Metal Orchestrator is deployed. The GC site constitutes core components and site components. The GC can manage all sites and devices that are associated with it. It enables horizontal scaling and allows a single site to scale by creating one or more sites called remote sites.

Remote sites: You can create remote sites in different locations and each site can manage devices that are associated with it. For example, consider if you deploy four sites, one each at Santa Clara, Hopkinton, Durham, and Miami. All sites have separate sets of physical devices to manage. The GC manages all of them and is deployed in Austin. When you create sites, site components are deployed on each site.

You can:

Add worker nodes for creating sites. Create remote sites. View and update the site metadata. Monitor the health, operation, and status of your sites. Reinitialize a site that has failed. Delete remote sites. Manage device configurations and devices that are associated with the sites. Create hardware profiles on the Global Controller and apply them to servers associated with different sites. Update the DHCP configuration on sites.

NOTE: The term device includes servers and switches unless otherwise stated.

Site creation workflow

About this task

The high-level steps for creating sites are as follows:

Steps

1. Add worker nodes. For more information, see the Bare Metal Orchestrator Installation Guide.

2. Verify if the nodes are created successfully, see Viewing nodes.

3. Create remote sites, see Creating remote sites.

NOTE: The site controller and site components are installed when a remote site is created.

3

28 Managing sites

4. Verify that the sites are successfully created, see Viewing sites.

Next steps

Proceed to onboard servers at the sites, see Servers overview.

Viewing nodes View nodes to verify they are deployed.

Steps

1. Establish a CLI session on the Bare Metal Orchestrator VM. For high availability configurations, establish a CLI session using the virtual IP (VIP) of the Load Balancers for the Bare Metal Orchestrator cluster.

2. Run the following command:

bmo get node

Results

The node details are displayed. The following example output shows deployed nodes. For more information about the fields, see Node field definitions.

NAME ON-BOARDED SITE AGE INTERNAL-IP bmo-manager-1 gc 13d 111.11.0.11 worker-1 sclara 13d 100.10.0.10

Creating remote sites

Prerequisites

Update the hosts file and create worker nodes. For example, if you want to create two remote sites, update the hosts file with the IP address for both the worker nodes and create the nodes. For more information about updating the hosts file and creating worker nodes, see the Bare Metal Orchestrator Installation Guide.

Steps

1. Establish a CLI session on the Bare Metal Orchestrator VM. For high availability configurations, establish a CLI session using the virtual IP (VIP) of the Load Balancers for the Bare Metal Orchestrator cluster.

2. Change the directory to ~/samples/sites.

3. Create the .yaml file by copying the sample file.

For example:

cp .yaml remote-site1.yaml

4. Edit the .yaml file in Vim or a similar editor.

5. Specify these attributes in the .yaml file:

Enter a site name of up to 253 characters. For more information, see Metadata.

Enter the values for the site attributes. For more information, see Site field definitions.

An example of the updated remote-site1.yaml file is shown below:

apiVersion: mw.dell.com/v1 kind: Site metadata: name: sclara spec: nodeName: worker-1 type: remote

Managing sites 29

location: sclara metadata: id: SNCLCFBC city: SantaClara state: California address: "5450 Great America Pkwy, Santa Clara, CA 95054, USA" country: USA latLong: "37.404882, -121.978486"

6. Save the file and quit the editor.

7. Create the sites using the following command:

bmo create site -f .yaml For example:

bmo create site -f remote-site1.yaml

NOTE: Repeat this procedure to create other remote sites.

Viewing sites

About this task

To view details about the global and remote sites available in your cluster:

Steps

1. Establish a CLI session on the Bare Metal Orchestrator VM. For high availability configurations, establish a CLI session using the virtual IP (VIP) of the Load Balancers for the Bare Metal Orchestrator cluster.

2. Run the following command:

bmo get site

Results

This is an example output for a successful site deployment.

NAME NODE NAME LOCATION HEALTH STATE OPERATION AGE gc bmo-manager-1 gc OK Ready 1d sclara worker-1 sclara OK Ready 1d

Editing sites

Steps

1. Establish a CLI session on the Bare Metal Orchestrator VM. For high availability configurations, establish a CLI session using the virtual IP (VIP) of the Load Balancers for the Bare Metal Orchestrator cluster.

2. Edit the site.yaml file and update the required attributes in Vim or a similar editor. For more about attribute definitions, see YAML schema.

3. Save the file and quit the editor.

4. To edit the site, run the following command:

bmo edit site

30 Managing sites

Reinitializing sites You can reinitialize one or multiple sites in a cluster. Reinitializing is useful for reinstating a failed site after the issue that caused the failure is resolved.

Prerequisites

Sites must be configured and discoverable.

CAUTION: Do not reinitialize a failed site when the site operation value is empty. Do a get site and ensure that

the site operation value is not empty before reinitializing a site. Contact your Dell Support representative if a

site enters the failed or critical state and the operation value is empty.

About this task

To reinitialize a site, set the reInitialize attribute value to true in the site's YAML file. For information about site attribute definitions, see Site field definitions. The reInitialize attribute is automatically removed from the YAML file after it has run.

NOTE: When recreating a site with the same name, wait for the namespace to be terminated before creating the site.

When a site is reinitialized, Bare Metal Orchestrator reconciles the site, reapplies the site settings, and then reinstates the site. For a site that is in the failed state, Bare Metal Orchestrator takes the site out of the failed state before reinitializing.

Steps

1. Establish a CLI session on the Bare Metal Orchestrator VM. For high availability configurations, establish a CLI session using the virtual IP (VIP) of the Load Balancers for the Bare Metal Orchestrator cluster.

2. Edit the .yaml file in Vim or a similar editor.

For example:

vim remote_site1.yaml

3. Update the reInitialize attribute in the .yaml file and enter the value true.

An example of the updated remote-site1.yaml file is shown below:

apiVersion: mw.dell.com/v1 kind: Site metadata: name: sclara spec: nodeName: worker-1 type: remote location: sclara reInitialize: true metadata: id: SNCLCFBC city: SantaClara state: California address: "5450 Great America Pkwy, Santa Clara, CA 95054, USA" country: USA latLong: "37.404882, -121.978486"

4. Save the file and quit the editor.

5. To reinitialize the site, run the following command:

bmo edit site -f .yaml

Deleting sites

Prerequisites

Delete all servers and hardware profiles that are associated with the site.

Managing sites 31

About this task

Use this procedure to delete remote sites.

NOTE: You cannot delete a GC site.

When you delete a remote site, the given site object and its associated components are deleted. For more information on deleting worker nodes, see the Bare Metal Orchestrator Installation Guide.

Steps

1. Establish a CLI session on the Bare Metal Orchestrator VM. For high availability configurations, establish a CLI session using the virtual IP (VIP) of the Load Balancers for the Bare Metal Orchestrator cluster.

2. To delete the site, run the following command:

bmo delete site For example:

bmo delete site aust-1

NOTE: Repeat these steps to delete multiple sites.

32 Managing sites

Multi-tenancy

Topics:

Multi-tenancy overview Creating tenants Editing tenants Viewing tenants Describing a tenant Reinitializing tenants Deleting tenants

Multi-tenancy overview Multi-tenancy is a distributed Bare Metal Orchestrator architecture where a single instance of Bare Metal Orchestrator runs on a server and serves multiple tenants. A tenant is a group of users who share common access and specific privileges to the software instance. This includes its data, configuration, user management, resources, tenant-individual functionality, and nonfunctional properties.

The following table describes the available tenant roles in Bare Metal Orchestrator and the assigned permissions for each role.

Table 19. Tenant roles

Role Permissions

Tenant Admin Read and write privileges to all tenant-related operations and resources, within the assigned tenant.

Can assign more users to the tenant.

Can view or describe the assigned tenant.

Can view all servers in the pool of unassigned resources and the assigned tenant.

Can view all ISO media and firmware media in the default tenant.

Can view all sites in the pool of unassigned resources.

Can transfer servers from the pool of unassigned resources to the assigned tenant.

Can release servers from the assigned tenant to the pool of unassigned resources.

CAUTION:

When a server is returned to the pool of unassigned resources, the baseline-profile is applied. If the secureEraseDrives attribute is set to true, the server's disks are wiped and data

loss will occur. To avoid erasure of server disks, edit the baseline-profile and ensure the secureEraseDrives attribute is set to false.

Cannot edit servers of other tenants.

Cannot create users or any resources such as servers, ISO media, or firmware media, and so on.

Cannot delete any tenant or resources.

Tenant Reader Read-only access to Bare Metal Orchestrator resources, within the assigned tenant.

Can view all servers in the global pool and the assigned tenant.

Can view all ISO media and firmware media in the global pool.

Cannot create, edit, or delete tenants or resources.

4

Multi-tenancy 33

Multi-tenancy allows you to:

Create, edit, describe, or delete tenants. Create users and assign roles. Add users to the given tenant. Edit or delete users who are associated with the given tenant. Request or release a server or a switch from the given tenant.

The high-level flow for creating tenants, assigning servers or switches and users is as follows:

1. Create a user. For more information, see Create a user with a user-profile YAML file or Create a user without a user-profile YAML file.

2. Create tenants. For more information, see Creating tenants. 3. Add servers or switches and users to the tenant. For more information, see Editing tenants.

Creating tenants

About this task

To create tenants:

Steps

1. Establish a CLI session on the Bare Metal Orchestrator VM. For high availability configurations, establish a CLI session using the virtual IP (VIP) of the Load Balancers for the Bare Metal Orchestrator cluster.

2. Change the directory to ~/samples/tenants.

3. Create the .yaml file by copying the sample file.

For example:

cp tenant.yaml tenant1.yaml

4. Edit the .yaml file in Vim or a similar editor.

5. Specify these attributes in the .yaml file:

Enter the tenant name. For more information, see Metadata.

Optional: To associate servers, switches, or users, enter the values for appropriate tenant attributes. For more information, see Tenant field definitions.

For an example snapshot of the .yaml file, see Sample tenant YAML file.

6. Save the file and quit the editor.

7. Create a tenant using the following command:

bmo create tenant -f .yaml For example:

bmo create tenant -f tenant1.yaml

NOTE: Repeat these steps to create other tenants.

Editing tenants

Prerequisites

A user with a Global Admin or Global Reader role is required. For more information, see Role-based access control. Servers must be created. For more information, see Create a server or multiple servers and update configurations. Create switches if switches are being requested for the given tenant. For more information, see Create a switch and update

configurations.

34 Multi-tenancy

About this task

Update the tenant.yaml file to:

Request servers or switches for the given tenant. Release servers or switches from the given tenant.

NOTE: When a server is released, or returned to the unassigned resources pool, the server name is added to the

baseline hardware profile and the baseline hardware profile is applied to the released server. The baseline profile is used

to reset the server to default settings and securely erase its disks.

Assign users to the given tenant. Remove users from the given tenant.

Steps

1. Establish a CLI session on the Bare Metal Orchestrator VM. For high availability configurations, establish a CLI session using the virtual IP (VIP) of the Load Balancers for the Bare Metal Orchestrator cluster.

2. Edit the .yaml file in Vim or a similar editor.

For example:

vim tenant1.yaml

3. Update the required configuration. For more information, see Tenant field definitions.

For an example snapshot of the .yaml file, see Sample tenant YAML file.

4. Save the file and quit the editor.

5. Run the following command:

bmo edit tenant -f .yaml For example:

bmo edit tenant -f tenant1.yaml

Viewing tenants

About this task

To view tenants:

Steps

1. Establish a CLI session on the Bare Metal Orchestrator VM. For high availability configurations, establish a CLI session using the virtual IP (VIP) of the Load Balancers for the Bare Metal Orchestrator cluster.

2. Run the following command:

bmo get tenant

Results

This is an example output for successful tenant creation.

NAME STATE SERVER SWITCH OPERATION AGE tenant-it Ready 0 0 4d22h tenant-switch Ready 0 0 4d23h

Describing a tenant

About this task

To view detailed information about a specific tenant:

Multi-tenancy 35

Steps

1. Establish a CLI session on the Bare Metal Orchestrator VM. For high availability configurations, establish a CLI session using the virtual IP (VIP) of the Load Balancers for the Bare Metal Orchestrator cluster.

2. Run the following command:

bmo describe tenant

Reinitializing tenants You can reinitialize one or more tenants. Reinitializing helps reinstate a failed tenant after the issue that caused the failure is resolved.

About this task

To reinitialize a tenant, set the reInitialize attribute value to true in the tenant's YAML file. The reInitialize attribute is automatically removed from the YAML file after it is run.

When a tenant is reinitialized, Bare Metal Orchestrator reconciles the tenant, reapplies the tenant settings, and then reinstates the tenant. For a tenant in the failed state, Bare Metal Orchestrator takes the tenant out of the failed state after reinitialization.

To reinitialize a tenant:

Steps

1. Establish a CLI session on the Bare Metal Orchestrator VM. For high availability configurations, establish a CLI session using the virtual IP (VIP) of the Load Balancers for the Bare Metal Orchestrator cluster.

2. Edit the .yaml file in Vim or a similar editor.

For example:

vim tenant1.yaml

3. Update the reInitialize attribute in the .yaml file and enter the value as true. For information about tenant attribute definitions, see Tenant field definitions.

For an example snapshot of the .yaml file, see Sample tenant YAML file.

4. Save the file and quit the editor.

5. To reinitialize the tenant, run the following command:

bmo edit tenant -f .yaml

Deleting tenants

Prerequisites

Release the servers or switches that are associated with the tenant.

NOTE: When a server is released, or returned to the unassigned resources pool, the server name is added to the baseline

hardware profile and the baseline hardware profile is applied to the released server. The baseline profile is used to reset the

server to default settings and securely erase its disks.

About this task

To delete a tenant:

Steps

1. Establish a CLI session on the Bare Metal Orchestrator VM. For high availability configurations, establish a CLI session using the virtual IP (VIP) of the Load Balancers for the Bare Metal Orchestrator cluster.

2. To delete the tenant, run the following command:

36 Multi-tenancy

bmo delete tenant For example:

bmo delete tenant tenant1

NOTE: Repeat these steps to delete multiple tenants.

Multi-tenancy 37

Discovering devices You can manually add network devices like servers and switches to Bare Metal Orchestrator or use automatic discovery.

Topics:

Managed device discovery overview Default credentials for device discovery Manual bulk server discovery DHCP configuration and automatic discovery DHCP configuration options Onboard devices using ipscan Show auto-discovered devices list Delete ipscan settings for a site

Managed device discovery overview

There are multiple ways to onboard network devices to Bare Metal Orchestrator. Before onboarding any device, you must add the device's default credentials in the cred.yaml file, see Default credentials for device discovery.

Bare Metal Orchestrator can onboard Dell and Cisco switches. To onboard Dell switches, see the sections in this chapter related to manual and automatic device discovery. To onboard Cisco switches, see Onboard a Cisco switch in Bare Metal Orchestrator.

NOTE: The term devices includes servers and switches unless otherwise stated.

Manual device discovery using a device YAML file

Manual device discovery using this method identifies a device and its components, then retrieves the device's inventory information. In Bare Metal Orchestrator, you can discover devices manually by:

Creating a device. For servers, see Create a server or multiple servers and update configurations. For switches, see Create a switch and update configurations.

Viewing the inventory. For servers, see View server inventory. For switches, see View switch inventory.

NOTE: In the server YAML file, the userName and password fields must be blank for manual server discovery to work.

Manual bulk server discovery using a server YAML file

Manual bulk discovery using this method involves creating a list of servers and baseboard management controllers so that Bare Metal Orchestrator can access the servers, onboard them, and report their inventory. See Manual bulk server discovery.

Automatic device discovery using DHCP

This method of automatic server discovery requires having DHCP enabled in Bare Metal Orchestrator and in the BMC of the server that you want to onboard. For switches, DHCP must be enabled in Bare Metal Orchestrator and the switch to be onboarded. When a device is automatically discovered, the device components are automatically identified and added to Bare Metal Orchestrator's inventory information. For more information about enabling DHCP for automatic device discovery, see:

DHCP configuration and automatic discovery DHCP configuration options

5

38 Discovering devices

Automatic device discovery using ipscan The ipscan method auto-discovers all supported devices such as servers on a particular subnet for a site and onboards them. Only secure ports are scanned. For instructions, see Onboard devices using ipscan.

Default credentials for device discovery The discovery-manager service uses default credentials that are provided during Bare Metal Orchestrator deployment for automatic discovery of devices on the network. Before more devices can be auto-discovered or manually onboarded, you must add the device's default login credentials to the Bare Metal Orchestrator file called cred.yaml. You can edit or delete the default credentials using the Bare Metal Orchestrator command line interface or the web UI.

Bare Metal Orchestrator uses the default credentials in the cred.yaml file to connect to the server's BMC and to the switch's management interface. Default passwords are encrypted and stored as secrets. Bare Metal Orchestrator regularly polls the secrets to check for new and changed secrets.

During device discovery, Bare Metal Orchestrator tries using each credential in the cred.yaml file until the successful credential is found. For example, if there are five credentials, each credential is used to attempt to connect to devices and get their inventory. If the fourth credential is the right one, the fifth credential is not attempted.

If a successful set of credentials to connect to a device cannot be found, Bare Metal Orchestrator marks that device as unable to onboard and the device is not onboarded.

Example for a cred.yaml file:

credentials: - username: username1 password: password1 - username: username2 password: password2 - username: username3 password: password3 - username: username4 password: password4 - username: username5 password: password5

Edit default credentials

You can add or change credentials in the cred.yaml file. Before you discover and onboard devices, you must add the device's IP address and root login credentials to the cred.yaml file.

Steps

1. Establish a CLI session on the Bare Metal Orchestrator VM. For high availability configurations, establish a CLI session using the virtual IP (VIP) of the Load Balancers for the Bare Metal Orchestrator cluster.

2. Run the following command to edit the cred.yaml file and apply the changes:

bmo edit default-credential -f cred.yaml

Manual bulk server discovery You can edit a YAML file to create a list of servers for Bare Metal Orchestrator to discover and onboard.

Manual bulk server discovery is useful if you do not want to use automatic DHCP discovery. You can manually add several servers at once by using a text editor. This requires editing a YAML file to include the followings details for each server:

Server name and labels BMC endpoint IP address BMC username

Discovering devices 39

BMC password

The BMC endpoint must be in http(s)://<IP address> format. Separate the details of each server with three dashes (---). To create servers, see Create a server or multiple servers and update configurations.

Server profile YAML files can have empty userName and password fields. If the fields are empty, Bare Metal Orchestrator uses the default credentials in cred.yaml to attempt to connect to a server, onboard it, and get its inventory. If Bare Metal Orchestrator cannot use a set of credentials to connect to a server, it marks that server as unable to onboard and the server is moved to a failed state.

NOTE: In the server YAML file, the userName and password fields must be blank for manual server discovery to work.

This example shows two servers in a list created for manual bulk discovery.

apiVersion: mw.dell.com/v1 kind: Server metadata: name: dell-r740-71 labels: site: sclara spec: # Add fields here bmcEndPoint: "https:// " userName: "" password: "" --- apiVersion: mw.dell.com/v1 kind: Server metadata: name: dell-r6515-05 labels: site: sclara spec: # Add fields here bmcEndPoint: "https:// " userName: "" password: ""

DHCP configuration and automatic discovery DHCP configuration is part of the Bare Metal Orchestrator automatic device discovery process.

Bare Metal Orchestrator uses two services for automatic discovery:

dhcp-server, which assigns IP addresses to devices.

discovery-manager, which detects IP addresses and uses them to create device objects in Bare Metal Orchestrator.

The device objects are automatically displayed in the Inventory in the Bare Metal Orchestrator web user interface. DHCP for servers must be enabled on BMCs for automatic discovery using dhcp-server to work. See Enabling DHCP in an iDRAC for instructions.

NOTE: Bare Metal Orchestrator does not support IPv6.

DHCP configuration options

You must have a mechanism to assign IP addresses and enable discovery by DHCP for automatic device discovery to work. Bare Metal Orchestrator has three DHCP deployment mode options, and two automatic discovery options. The three DHCP options are:

None No DHCP. IP addresses are manually assigned and static. Choosing this option means devices must be manually discovered.

Relay The Bare Metal Orchestrator DHCP server is deployed in relay mode. It acts as a proxy and forwards requests to the DHCP server of the customer.

40 Discovering devices

NOTE: You must provide the DHCP relay interface name in the interfaces field and the

external DHCP server forwarding IP address in the dhcpForwardIpAddress field so Bare Metal

Orchestrator knows where to forward the requests.

Automatic discovery does not work in relay mode.

Figure 3. DHCP relay in Bare Metal Orchestrator

Server A DHCP manager pod is created when dhcpDeployMode is set to server. The DHCP server is a service that Bare Metal Orchestrator manages, and it is packaged and deployed as part of Bare Metal Orchestrator.

NOTE: You must define the subnet, IP address pool, lease, and netmask values and interface names.

The two automatic discovery options are:

Auto When discoveryViaDhcp is set to auto, Bare Metal Orchestrator attempts to automatically find devices.

None When discoveryViaDhcp is set to none, there is no automatic device discovery.

There are parameters you must pass to Bare Metal Orchestrator to enable DHCP. All DHCP configuration options are defined and passed in a YAML file. Customers must specify the IP addresses and interfaces in the YAML file.

DHCP YAML fields

DHCP options must be included in the YAML file that is passed when you create or edit a site. See DHCP fields for a table of Bare Metal Orchestrator DHCP options.

See Sample DHCP configuration YAML file for an example YAML file that shows the fields you need to define to configure DHCP.

Enabling DHCP in an iDRAC

DHCP must be enabled in the iDRAC of any servers you want to onboard.

Prerequisites

DHCP must be enabled in Bare Metal Orchestrator.

About this task

DHCP must be enabled on iDRACs for automatic discovery using dhcp-server to work.

To enable DHCP in the iDRAC:

Discovering devices 41

Steps

1. In the iDRAC Settings drop-down menu, select Settings.

2. Expand IPv4 Settings.

3. In the DHCP drop-down list, select Enabled and click Apply.

4. Verify that the iDRAC has an IP lease from the Bare Metal Orchestrator DHCP server IP address pool and that the iDRAC is accessible at this address.

Results

Now that the iDRAC is accessible by Bare Metal Orchestrator from its assigned IP address, Bare Metal Orchestrator can onboard the server automatically using the discovery-manager service. The server and its inventory are now viewable in the Bare Metal Orchestrator web UI.

Onboard devices using ipscan

Prerequisites

Update the cred.yaml file with the root login credentials of the devices and servers on the network to be onboarded, see Default credentials for device discovery.

Ensure devices to be onboarded meet the hardware and software requirements, see Validated hardware components. Devices must be on the same subnet for auto-discovery using ipscan. Only secure ports are scanned on the subnet.

About this task

Create an ipscan.yaml file and include the IP addresses of the devices on the network to auto-discover. An example ipscan.yaml file is available in the /samples/ipscan/ directory. Both YAML and JSON file formats are accepted.

The attributes you can set include:

start_range The starting IP address for an IP range. Must be specified coupled with endRange.

end_range The end IP address for an IP range. Must be specified coupled with startRange.

subnet_cidr An IP network specified in CIDR format.

hosts A user-defined list of specific IP addresses to scan.

scan_frequency Schedule the frequency of IP scans in seconds. Only one IP scan can be active for a site at any one time. The current scan must end before the next scan starts. The minimum scan frequency is once every 300 seconds and the maximum is once every 86400 seconds.

Steps

1. Establish a CLI session on the Bare Metal Orchestrator VM. For high availability configurations, establish a CLI session using the virtual IP (VIP) of the Load Balancers for the Bare Metal Orchestrator cluster.

2. Change the directory to ~/samples/ipscan.

3. In an editor such as Vim, edit the ipscan.yaml file and add the IP addresses of the devices on the network you are onboarding.

For example:

vim ipscan.yaml The following is an example ipscan.yaml file.

start_range: 172.16.3.57 end_range: 172.16.3.60 subnet_cidr: 172.16.3.32/27 # in seconds scan_frequency: 400 hosts: - 172.16.3.54 - 172.16.3.100

42 Discovering devices

4. Run the following command:

bmo create ipscan -n -f .yaml where is the location that was defined for the site, and is the name of the ipscan YAML file.

5. Run the following command to verify server discovery and onboarding:

bmo get server

Show auto-discovered devices list

About this task

Use this procedure to display the IP addresses of network devices that were auto-discovered the last time ipconfig was run. The current IP scan settings are also displayed. If ipscan has not yet been run or the IP scan settings have been deleted, the settings are empty.

Steps

1. Establish a CLI session on the Bare Metal Orchestrator VM. For high availability configurations, establish a CLI session using the virtual IP (VIP) of the Load Balancers for the Bare Metal Orchestrator cluster.

2. Run the following command:

bmo get ipscan -n where is the location that was defined for the site.

The following is an example output for bmo get ipscan -n , where the IP scan settings are empty and there are no auto-discovered IP addresses to display.

ip_list: [] last_conf: []

The following is an example output for a populated list of auto-discovered IP addresses from the last time ipscan was run and the current IP scan settings.

ip_list: 100.10.1.2 100.10.1.9 100.10.1.101 100.10.1.102

last_conf start_range: 100.10.1.0 end_range: 100.10.1.4 subnet_cidr: 100.10.1.8/31 # in seconds scan_frequency: 400 hosts: - 100.10.1.101 - 100.10.1.102

NOTE: You can run bmo get server to see a list of onboarded servers.

Delete ipscan settings for a site

About this task

Use this procedure to delete the ipconfig scan settings for a site. The IP address start and end ranges and the subnet CIDR value are deleted. Plus any specified host IP addresses are removed. The site's scan_frequency value is also reset to 0, which stops auto-discovery scanning for devices at the site.

Discovering devices 43

Steps

1. Establish a CLI session on the Bare Metal Orchestrator VM. For high availability configurations, establish a CLI session using the virtual IP (VIP) of the Load Balancers for the Bare Metal Orchestrator cluster.

2. Run the following command:

bmo delete ipscan -n where is the location that was defined for the site.

44 Discovering devices

Managing servers

Topics:

Servers overview Create a server or multiple servers and update configurations Edit server configuration View servers and server status View server inventory Reinitialize servers Delete servers Decommission servers Decommission disks Edit iDRAC default factory settings

Servers overview Server configuration is performed with YAML files on Bare Metal Orchestrator. These files are templates that contain configuration settings for an individual server or multiple servers. You can update the file with attributes that can trigger specific work flows like firmware updates, operating system deployment, and so forth. You can use the sample server .yaml files to create servers, update the required configurations, and apply them on the target server.

For more information about the supported configurations, see Managing server configurations.

You can perform the following operations on servers:

Creating, editing, and deleting servers Viewing server inventory and hardware details Reinitializing servers Monitoring the health, provisioning, and power status of servers

Create a server or multiple servers and update configurations

Prerequisites

Gather the IP address and credentials that have administrative access on the iDRAC. Meet the hardware and software requirements. For more information, see Validated hardware components. Decide on your configuration requirements. For more information, see Managing server configurations.

About this task

To create servers or update configurations:

Steps

1. Establish a CLI session on the Bare Metal Orchestrator VM. For high availability configurations, establish a CLI session using the virtual IP (VIP) of the Load Balancers for the Bare Metal Orchestrator cluster.

2. Change the directory to ~/samples/servers.

3. Create a new server .yaml file by copying the sample file.

6

Managing servers 45

cp .yaml .yaml NOTE: Copy the sample file based on your configuration requirements. For example, if you are updating the BMC

attributes, copy the bmc_attributes.yaml file.

4. Edit the .yaml file in Vim or a similar editor.

For example:

vim dell_server_new.yaml

5. Customize the .yaml file:

Update the metadata. For more information, see Metadata. Update the fields mentioned in Server connectivity field definitions. For server telemetry, update the fields mentioned in Server and profile telemetry field definitions. Update the attribute values based on the configurations you want to perform. For more information about the server

configurations, see Managing server configurations. If you are just onboarding servers and do not wish to do any configuration changes, omit this step.

NOTE: To create multiple servers, see Manual bulk server discovery.

For an example snapshot of the consolidated .yaml file updated with attributes for different configurations, see Sample server YAML file.

6. Save the file and quit the editor.

7. Create the server instance.

bmo create server -f .yaml For example:

bmo create server -f dell_server_new.yaml

Edit server configuration

About this task

To edit the server configuration:

Steps

1. Establish a CLI session on the Bare Metal Orchestrator VM. For high availability configurations, establish a CLI session using the virtual IP (VIP) of the Load Balancers for the Bare Metal Orchestrator cluster.

2. Edit the .yaml file with Vim or a similar editor.

For example:

vim dell_server_new.yaml

3. Update the attribute values based on the configurations you want to perform. For more information about the server configurations, see Managing server configurations.

For an example snapshot of the consolidated .yaml file updated with attributes for all configurations, see Sample server YAML file.

4. Save the file and quit the editor.

5. Edit the server.

If the server is associated with a tenant, run: bmo edit server -n If the server is not associated with a tenant, run: bmo edit server -f .yaml To edit configuration on multiple servers, see Edit hardware profile configuration.

46 Managing servers

View servers and server status

About this task

To view servers or server status:

Steps

1. Establish a CLI session on the Bare Metal Orchestrator VM. For high availability configurations, establish a CLI session using the virtual IP (VIP) of the Load Balancers for the Bare Metal Orchestrator cluster.

2. View server details.

If the server is associated with a tenant, run: bmo get server -n If the server is not associated with a tenant, run: bmo get server

This retrieves the list of servers and server details.

This is an example output for a successful server configuration:

NAME POWER STATUS PROVISIONING STATUS COMMAND EXECUTING SITE LOCATION AGE dell On Ready miami 5d11h

When the Provisioning Status transitions from Busy to Ready state, the server configuration is successful. For more information about the server provisioning status, see Server provisioning status.

View server inventory

About this task

To view detailed inventory information about the device:

Steps

1. Establish a CLI session on the Bare Metal Orchestrator VM. For high availability configurations, establish a CLI session using the virtual IP (VIP) of the Load Balancers for the Bare Metal Orchestrator cluster.

2. View server inventory.

If the server is associated with a tenant, run: bmo describe server -n If the server is not associated with a tenant, run: bmo describe server The metadata, spec, and status fields are displayed. For more information about the fields, see YAML objects and common fields.

Reinitialize servers You can reinitialize a server on one or multiple nodes in a cluster, as well as servers in a distributed deployment that supports multi-tenancy. Reinitializing is useful for reinstating a failed server after the issue that was causing the failure is resolved. For servers in the ready state, reinitializing recollects the server's inventory.

Prerequisites

Nodes must be configured and discoverable.

About this task

To reinitialize a server, set the reInitialize attribute value to "true" in the server's YAML file. For bulk operations (servers), use the reInitialize attribute in a hardware profile. The reInitialize attribute is automatically removed from the YAML file after it is run.

When a server is not in a failed state, Bare Metal Orchestrator performs these reinitialization steps:

1. Rerun inventory against the server.

Managing servers 47

2. Reconcile the server. 3. Reapply any configuration profile that targets the server and then reinstate the server.

For a server in a failed state, Bare Metal Orchestrator takes the server out of the failed state before reinitializing.

Steps

1. Establish a CLI session on the Bare Metal Orchestrator VM. For high availability configurations, establish a CLI session using the virtual IP (VIP) of the Load Balancers for the Bare Metal Orchestrator cluster.

2. Edit the .yaml file with Vim or a similar editor.

For example:

vim dell_server.yaml

3. For servers, add the reInitialize attribute in the .yaml file and enter the value true.

For example:

apiVersion: mw.dell.com/v1 kind: Server metadata: name: dell-server-2 labels: site: austin spec: bmcEndPoint: https:// userName: dell password: 123456 powerstate: "On" location: placement: rack: "Rack 922" row: "Row 954" postalAddress: building: "Dell RR4" room: "Room 50" reInitialize: true bios: attributes: logicalProc: Enabled continued ...

4. Save the file and quit the editor.

5. Run the following command:

bmo edit server -f .yaml

Delete servers

About this task

To delete a server:

Steps

1. Establish a CLI session on the Bare Metal Orchestrator VM. For high availability configurations, establish a CLI session using the virtual IP (VIP) of the Load Balancers for the Bare Metal Orchestrator cluster.

2. Delete a server:

If the server is associated with a tenant, run: bmo delete server -n If the server is not associated with a tenant, run: bmo delete server

48 Managing servers

For example:

bmo delete server dell_server1

NOTE: Repeat these steps to delete multiple servers.

Decommission servers Use a baseline hardware profile to decommission servers.

The baseline profile returns a server to a default configuration by securely erasing its disks and restoring default settings. Use the baseline profile to decommission servers and put them in a clean state before they are returned to the pool of available servers.

Baseline profiles are created during Bare Metal Orchestrator deployment. You must edit baseline profiles for each onboarded server. Baseline profiles cannot be deleted.

The baseline profile consists of:

Factory default BIOS settings Factory default baseboard management controller settings Factory default BMC settings User-defined default firmware versions Secure disk erasure

See Sample baseline profile YAML file for an example baseline profile YAML file and Server decommissioning field definitions for baseline hardware-specific attributes.

Selectors and marking servers for decommission

A default baseline profile selector called profileName: profile is used to target specific servers for decommission. You can also add custom selectors to help target specific servers for decommissioning. The server must have labels configured that exactly match the selectors.

For example: if the following is configured in the baseline profile:

selectors: profileName: profile decommission: dell-servers20

the servers that have the following labels configured are targeted for decommissioning:

labels: profileName: profile decommission: dell-servers20

NOTE: Multiple, user-defined selectors are supported. You can add them in the spec section of the baseline profile to help

target specific servers. However, don't modify the default selector.

Use a baseline profile to decommission a server

To decommission a server, edit the server configuration and add the label that matches the selector that was added to the hardware profile, see Edit server configuration.

Bare Metal Orchestrator polls servers at regular intervals. If Bare Metal Orchestrator finds a matching profile label, it applies the baseline profile.

CAUTION: When a server is decommissioned and the server moves to the available server pool, the server's

disks are completely overwritten and all information is unrecoverable.

Managing servers 49

Secure disk erasure

Decommissioning a server is one way to securely erase a disk. You can also securely erase a disk without decommissioning a server. See Decommission disks.

Decommission disks

Bare Metal Orchestrator can securely erase a physical disk, including disks used in a RAID volume. The disks must be Secure Erase or cryptographic erasure capable.

NOTE: SD card erasure is not supported.

Set the SecureEraseDrives field to true to completely and permanently erase all information on a server's disks. The following example YAML file shows how to instruct Bare Metal Orchestrator to securely erase a server's disks.

apiVersion: mw.dell.com/v1 kind: Server metadata: name: dell-r740xd labels: vendor: dell site: gc spec: # Add fields here bmcEndPoint: "https://"" userName: root password: "" Decommission: SecureEraseDrives: true

Edit iDRAC default factory settings

About this task

Bare Metal Orchestrator can reset certain iDRAC system components to factory default. You can perform a factory reset while on-boarding a new server. You can factory reset the following three system components in iDRAC:

BMC settings: Reset iDRAC settings to factory defaults. BIOS settings: Reset BIOS attributes to factory defaults. Server disk: Securely erases storage drives.

After the factory reset, wait at least five minutes before you onboard a server.

NOTE: Do not run any other operations on the server while resetting the iDRAC. Once iDRAC reset is complete, delete the

server, and onboard the server again with the desired configuration.

Steps

1. Establish a CLI session on the Bare Metal Orchestrator VM. For high availability configurations, establish a CLI session using the virtual IP (VIP) of the Load Balancers for the Bare Metal Orchestrator cluster.

2. Change the directory to ~/samples/servers.

3. Edit the .yaml file with Vim or a similar editor.

4. Customize the factoryReset field with required configurations. For attribute definitions, see iDRAC factory default setting field definitions.

Example snapshot of the .yaml file updated with attributes to reset iDRAC system components:

spec: bmcEndPoint: "https://1.2.3.4" userName: root

50 Managing servers

password: REPLACE_THIS factoryReset: bmcResetType: Default factoryResetBMC: false factoryResetBIOS: false factoryResetStorage: false

5. Save the file and quit the editor.

6. Do one of the following: To on-board a new server, run:

bmo create server -f .yaml To reset an existing server, run:

bmo edit server -f .yaml

NOTE: You can perform a factory reset on multiple servers simultaneously using a hardware profile by customizing the

factoryReset field with required configurations. Ensure that no other hardware profiles are applied on the servers

before resetting the iDRAC.

Managing servers 51

Provisioning hardware

Topics:

Hardware profiles overview Hardware profile targeting Create hardware profiles Preview server configuration status Apply a hardware profile configuration Edit hardware profile configuration View hardware profiles View hardware profile details Delete hardware profiles

Hardware profiles overview Hardware profiles are deployment templates that contain configuration settings. You can apply these configuration profiles to multiple servers for rapid and reproducible configuration.

Bare Metal Orchestrator provides the flexibility to create hardware profiles with different specifications and to apply them to one or multiple servers.

Hardware profiles enable you to:

Perform bulk provisioning. Manage multiple servers in a consistent manner. Automate repetitive administrative tasks.

In Bare Metal Orchestrator, hardware profiles are YAML files that you create and populate with attributes that trigger specific workflows, such as firmware updates, operating system deployment, and so forth.

To apply a hardware profile to specific servers, you can either list the names of the servers to target directly in the hardware profile or use selectors and labels.

Selectors and labels are user defined. The selector attribute you add to the hardware profile targets servers that have a matching label attribute.

For example, the following shows a selector attribute called hwprofile added to the hardware profile.

selectors: hwprofile: hw-profile001

The hardware profile is applied to any server that has a matching hwprofile label configured with the matching value. For example:

labels: hwprofile: hw-profile001

Hardware profiles also support a preview attribute so you can see the status of targeted servers before the hardware profile is applied, see Preview server configuration status.

NOTE:

You can use the sample hardware profile .yaml files provided during deployment to create new hardware profiles and

deploy specific profile configurations on servers. For more information about the supported configurations, see Managing

server configurations.

For more information about targeting servers, see Hardware profile targeting.

7

52 Provisioning hardware

Hardware profile targeting Hardware profiles are an efficient way to configure multiple servers in the cluster. You can apply a hardware profile to multiple servers using the server name or using profile selectors and labels.

To define which servers the hardware profile targets, you can add server names directly into the spec section of the hardware profile using the serverList attribute. For example:

spec: apply: true ## the hardware profile is applied only to servers listed below serverList: - name: server22 namespace: metalweaver - name: server21 namespace: metalweaver - name: server30 namespace: metalweaver ## Add more fields below server: powerState: "Off"

Another method to target servers is user-defined selectors and labels. The selector that you add to the hardware profile targets servers that have a matching label attribute.

The following shows an example hwprofile selector in the spec section of a hardware profile called hw-config001. Selector names are user defined.

spec: selectors: hwprofile: hw-config001

CAUTION: Do not name the selector profile. That name is reserved for internal operations.

Hardware profiles that are created using the Bare Metal Orchestrator Web UI already have a default selector called profileName: profile. You can add custom selectors to these hardware profiles, but don't modify the default selector.

To target a specific server, use the server's YAML file to edit the server configuration and add a matching hwprofile label. The following example shows a matching hwprofile label in the metadata section of a server YAML file.

apiVersion: mw.dell.com/v1 kind: Server metadata: name: dell-r740xd labels: site: gc hwprofile: hw-config001

Create hardware profiles You can provision multiple servers using a hardware profile.

Prerequisites

Decide on your configuration requirements. For more information, see Managing server configurations.

About this task

To create a hardware profile:

Steps

1. Establish a CLI session on the Bare Metal Orchestrator VM. For high availability configurations, establish a CLI session using the virtual IP (VIP) of the Load Balancers for the Bare Metal Orchestrator cluster.

Provisioning hardware 53

2. Change the directory to ~/samples/hardware-profiles.

3. Create a new hardware profile .yaml file by copying the sample file.

cp .yaml .yaml NOTE: Make sure that you copy the sample file based on your configuration requirements. For example, if you are doing

an ESXi operating system deployment, copy the hw_pf_esxi_install.yaml file.

4. Edit the .yaml file with Vim or a similar editor.

For example:

vim dell_hwprofile_ntp_update.yaml

5. Customize the .yaml file:

Update the metadata. For more information, see Metadata. For telemetry, update the fields mentioned in Server and profile telemetry field definitions. Update the attribute values based on the configurations you want to perform. For more information about the server

configurations, see Managing server configurations. Target specific servers. For more information, see Hardware profile targeting. Add the preview attribute to check target server status before applying the hardware profile configuration, see

Preview server configuration status.

For an example snapshot of the consolidated hardware profile updated with attributes for all configurations, see Sample hardware profile YAML file.

6. Save the file and quit the editor.

7. Create the hardware profile.

bmo create hardwareprofile -f .yaml For example:

bmo create hardwareprofile -f dell_hwprofile_ntp_update.yaml

Preview server configuration status

About this task

When using a hardware profile to configure servers, you can include the preview attribute to collect status information for the servers that the hardware profile targets before you apply the hardware profile configuration. Targeted servers that are in a non-ready state are shown under failedList.

NOTE: You cannot set both the apply and preview attributes to true at the same time in the hardware profile.

To preview server status in the hardware profile:

Steps

1. Establish a CLI session on the Bare Metal Orchestrator VM. For high availability configurations, establish a CLI session using the virtual IP (VIP) of the Load Balancers for the Bare Metal Orchestrator cluster.

2. Edit the .yaml file with Vim or a similar editor.

For example:

vim hw_profile001.yaml

3. Add the preview attribute and assign a value of true.

For example:

apiVersion: mw.dell.com/v1 kind: HardwareProfile metadata: name: hw-profile001 labels:

54 Provisioning hardware

site: gc spec: preview: true apply: false ## the hardware profile is applied only to servers listed below serverList: - name: server22 namespace: metalweaver - name: server21 namespace: metalweaver ## Add more fields below server: powerState: On

4. Save the file and quit the editor.

5. Run bmo describe hardwareprofile -f .yaml and scroll down to see the status section that was added below the spec section. For example:

bmo describe hardwareprofile -f hw-profile001.yaml The following is a sample status section of a hardware profile that is targeting two servers. One of the servers is in the failedList.

status: serverStatus: hash: 123777888999222444555 preview: summary: "hardware profile will not be applied on (1) servers due to non ready state at time [2022-01-27T11:10:53Z] failedList:

metalweaver server21

Apply a hardware profile configuration

Prerequisites

Either the hardware profile is updated with a list of the servers to be updated, or a selector is included in the hardware profile and the target servers have a matching label, see Hardware profile targeting.

About this task

Servers that have a matching label or that are specifically listed in the hardware profile are configured when that hardware profile is applied.

NOTE: You cannot set both the apply and preview attributes to true at the same time in the hardware profile.

To apply a hardware profile configuration:

Steps

1. Establish a CLI session on the Bare Metal Orchestrator VM. For high availability configurations, establish a CLI session using the virtual IP (VIP) of the Load Balancers for the Bare Metal Orchestrator cluster.

2. Edit the .yaml file with Vim or a similar editor.

For example:

vim hw_profile001.yaml

3. Add the apply attribute and assign a value of true.

For example:

spec: apply: true

Provisioning hardware 55

selectors: hwprofile: hw-profile001 serverList: - name: server22 namespace: metalweaver - name: server21 namespace: metalweaver ## Add more fields below server: powerState: "Off"

4. Save the file and quit the editor.

5. Run bmo edit hardwareprofile -f .yaml. For example:

bmo edit hardwareprofile -f hw-profile001.yaml The hardware profile is applied to all targeted servers.

Edit hardware profile configuration

About this task

To edit a hardware profile configuration:

Steps

1. Establish a CLI session on the Bare Metal Orchestrator VM. For high availability configurations, establish a CLI session using the virtual IP (VIP) of the Load Balancers for the Bare Metal Orchestrator cluster.

2. Edit the .yaml file with Vim or a similar editor.

For example:

vim dell_hwprofile_ntp_update.yaml

3. Update the attribute values based on the configurations you want to perform. For more information about the server configurations, see Managing server configurations.

For an example snapshot of the consolidated hardware profile updated with attributes for all configurations, see Sample hardware profile YAML file.

4. Save the file and quit the editor.

5. Run:

bmo edit hardwareprofile -f .yaml

View hardware profiles

About this task

To view a hardware profile:

Steps

1. Establish a CLI session on the Bare Metal Orchestrator VM. For high availability configurations, establish a CLI session using the virtual IP (VIP) of the Load Balancers for the Bare Metal Orchestrator cluster.

2. Run:

bmo get hardwareprofile This command retrieves the list of hardware profiles in Bare Metal Orchestrator.

56 Provisioning hardware

View hardware profile details

About this task

To view detailed information about the hardware profile:

Steps

1. Establish a CLI session on the Bare Metal Orchestrator VM. For high availability configurations, establish a CLI session using the virtual IP (VIP) of the Load Balancers for the Bare Metal Orchestrator cluster.

2. Run:

bmo describe hardwareprofile

Delete hardware profiles

About this task

NOTE: When you delete a hardware profile that is associated with a profile telemetry object, you have to first delete

the profile telemetry object before deleting the hardware profile. The profile telemetry object is not automatically deleted

when the hardware profile is deleted. For information about the profile telemetry delete command, see the Bare Metal

Orchestrator Command Line Interface Reference Guide.

To delete a hardware profile:

Steps

1. Establish a CLI session on the Bare Metal Orchestrator VM. For high availability configurations, establish a CLI session using the virtual IP (VIP) of the Load Balancers for the Bare Metal Orchestrator cluster.

2. To delete a hardware profile, run:

bmo delete hardwareprofile For example:

bmo delete hardwareprofile dell_hwprofile

NOTE: Repeat these steps to delete multiple hardware profiles.

Provisioning hardware 57

Managing server configurations

Topics:

Power state configuration - servers BIOS configuration - servers BMC configuration - servers Operating system deployment Operating system upgrade - servers Firmware update RAID configuration Telemetry enablement

Power state configuration - servers

You can set the power state on and off for a server or multiple servers.

The following table describes how you can update the power state for servers.

Table 20. Power State Configuration

Operation Description

Update the power state for a server Update the power state attribute while creating or editing a server.

Create a server or multiple servers and update configurations

Edit server configuration

NOTE: For more information about the powerState attribute, see

Power field definitions.

Update the power state for multiple servers Update the power state attribute while creating or editing a hardware profile.

Create hardware profiles

Edit hardware profile configuration

Verify if the power state change is successful for a server

View servers and server status

View server inventory

Verify if the power state change is successful for multiple servers

View hardware profiles

View hardware profile details

BIOS configuration - servers

The BIOS configuration feature allows you to view and update the attributes for the following BIOS settings:

Boot mode and the boot order System performance settings such as the memory speed, turbo mode, power policy, and so forth Memory functions such as the memory operating mode, node interleave, and so forth Processor settings such as the number of enabled cores, hardware and software prefetcher, and so forth Serial communication port properties such as the port address, associating the serial connector, and so forth

8

58 Managing server configurations

Single Root Input/Output Virtualization (SR-IOV) device properties

The following table describes how you can update and verify the BIOS configuration.

Table 21. BIOS Configuration

Operation Description

Update the BIOS configuration on a server Update the required BIOS attributes while creating or editing a server.

Create a server or multiple servers and update configurations Edit server configuration

NOTE: For more information about the BIOS attributes to be updated, see BIOS attribute definitions.

Update the BIOS configuration on multiple servers Update the required BIOS attributes while creating or editing a hardware profile.

Create hardware profiles

Edit hardware profile configuration

Verify if the BIOS configuration is successful on a server

View servers and server status

View server inventory

Verify if the BIOS configuration is successful on multiple servers

View hardware profiles

View hardware profile details

BMC configuration - servers The BMC configuration feature allows you to view and update the attributes for the following BMC settings:

DNS server configuration NTP server configuration User account settings such as creating, updating, and deleting user accounts Network connectivity settings such as vlan, topology, and so forth Service settings such as SNMP, timezone, and so forth Boot order Virtual console settings Network settings such as gateway, subnet mask, and so forth

The following table describes how you can update and verify the BMC configuration.

Table 22. BMC Configuration

Operation Description

Update the BMC configuration on a server Update the required BMC attributes while creating or editing a server.

Create a server or multiple servers and update configurations Edit server configuration

NOTE: For more information about the BMC attributes to be updated, see BMC attribute definitions.

Update the BMC configuration on multiple servers Update the required BMC attributes while creating or editing a hardware profile.

Create hardware profiles

Edit hardware profile configuration

Verify if the BMC configuration is successful on a server

View servers and server status

View server inventory

Managing server configurations 59

Table 22. BMC Configuration (continued)

Operation Description

Verify if the BMC configuration is successful on multiple servers

View hardware profiles

View hardware profile details

Operating system deployment

Operating system deployment is the process of installing an operating system on one or more servers. See Validated hypervisors and operating systems for the hypervisors and operating systems that Bare Metal Orchestrator can deploy.

You can perform the following operations:

View, create, edit or delete media objects. Update the media attributes while creating or editing a media object.

For more information about the CLI commands for media, see the Bare Metal Orchestrator Command Line Interface Reference Guide.

Install the operating system. Verify the operating system installation.

Deployment requirements

The following table lists the minimum free space required on the Bare Metal Orchestrator Global Controller and Worker nodes to deploy the operating system on a single server. Ensure there is enough free space on the Global Controller and at each worker site before installing the operating system.

NOTE: The specified minimum free space required to install the operating system is over and above the minimum free

space requirement of the Global Controller, worker nodes, and the two redundant high availability (HA) nodes in an HA

deployment. See the hardware requirements section of the Bare Metal Orchestrator Installation Guide for more information

about minimum free space requirements for servers.

Table 23. Minimum free space requirements for operating system deployment

Operating system Minimum free space

ESXi 10 GB

openSUSE 24 GB

Red Hat Enterprise Linux 50 GB

Wind River Cloud Platform 500 GB on each server in the cloud cluster

To check the available free space on a VM, see Confirm available free space on the node.

For Red Hat Enterprise Linux installations, if a server fails to onboard during the installation process because there is not enough available free space, contact Dell support before attempting to install the operating system again. See Contacting Dell Support for details.

NOTE: Bulk deployment operations are not supported on Red Hat Enterprise Linux. This operating system can only be

deployed on one server at a time.

Operating system deployment workflow - servers

Prerequisites

Only one drive must be visible to the operating system for installation. If the server has the PowerEdge RAID Controller (PERC) installed, only RAID volumes are visible to the operating system.

60 Managing server configurations

NOTE: To install the RHEL operating system onto a virtual volume created by the PERC S150 RAID Controller, the

installVolumeTypeOrder in the OS Spec must have the value RAID as the first type listed, with the virtual volume

name supplied as the name value.

If no drive is visible to the operating system, then the operating system installation fails. If more than one drive is available, the server boots up from the first drive that is configured in the boot order during the

operating system installation.

NOTE: The boot order attribute settings and the supported drives are described in the operating system field definition

tables for each operating system, see Operating system attributes.

There must be enough free space to install the operating system, see Operating system deployment. You need the host operating system root user password for the rootpw attribute value when deploying certain operating

systems. For details about attributes, see Operating system attributes. .

About this task

You can deploy an operating system on one or multiple servers at a time.

Observe the following:

For ESXi installation, Bare Metal Orchestrator can perform custom driver installation by accessing the drivers from the Bare Metal Orchestrator's web server or an external web server.

For Wind River Cloud Platform deployments, you must install the Wind River operating system on each server in the cloud cluster that hosts a Controller-0 component. A sample operating system deployment YAML file os_install_wr.yaml is located in ~/samples/servers. See Sample operating system YAML files - Wind River Cloud Platform.

If deploying Red Hat Enterprise Linux on a Dell or Supermicro server using a PXE device, you can use a Hardware Profile to deploy to multiple servers at once, if they have common PXE supported NIC interfaces.

Steps

1. Upload the operating system ISO image to the web server using the Bare Metal Orchestrator CLI, see Upload images and binary files to the web server.

2. Upload the required driver packages to the driver folder in the web server using the Bare Metal Orchestrator CLI.

NOTE: This step is applicable only for ESXi installation.

3. Create a media object that represents the operating system ISO stored in the web server. For more information, see Create a media object.

4. Create an OS driver media file. For more information, see Create a driver media object.

NOTE: This step is applicable only for ESXi installation.

5. Optional: Confirm available free space on the node.

6. Install the operating system on one or more servers. Update the Operating system attributes in the operating system deployment YAML file. You can also configure RAID volumes if you are using RAID controllers. For more information about the RAID attributes, see RAID attribute definitions.

The following table describes how to install an operating system.

Table 24. Alternate ways to install an operating system

Operation Description

Install the operating system on a server Update the operating system attributes while creating or editing a server.

Create a server or multiple servers and update configurations

Edit server configuration

Install the operating system on multiple servers Update the operating system attributes while creating or editing a hardware profile.

Create hardware profiles

Edit hardware profile configuration

Managing server configurations 61

The operating system installation begins.

CAUTION:

The server reboots several times during the installation. Do not manually shut down the server or interrupt

the installation process.

7. Bare Metal Orchestrator instructs the BMC to mount the virtual media (ISO) as a virtual CD.

8. Bare Metal Orchestrator sets the next boot order of the server to virtual CD and does the following:

Restarts the server if the server is powered on. Powers on the server if the server is powered off.

9. The server boots from the virtual CD and runs the operating system installer.

10. The operating system installer installs and configures the operating system. To verify the operating system installation, see Verify operating system deployment - servers.

11. The server reboots off the local drive. NOTE: If the operating system deployment is unsuccessful, contact Dell Support. See Contacting Dell Support for

details.

Create a media object

About this task

To create a media object:

Steps

1. Establish a CLI session on the Bare Metal Orchestrator VM. For high availability configurations, establish a CLI session using the virtual IP (VIP) of the Load Balancers for the Bare Metal Orchestrator cluster.

2. Change the directory to ~/samples/media.

3. Create a new media .yaml file for the uploaded ISO by copying the sample file.

cp .yaml 4. Edit the .yaml file in Vim or a similar editor.

For example:

vi esxi.yaml

5. Customize the .yaml with the required configurations:

Update the name of the media object. For more information, see Metadata. Update the value for the media attributes. For more information, see Media field definitions.

This is an example snapshot of an updated esxi.yaml file, where <External_BMO_IP> is the external IP address of the VM that is running Bare Metal Orchestrator.

apiVersion: mw.dell.com/v1 kind: Media metadata: name: os-media spec: # Required:type can be either "server" or "network" based on the hardware resource server or switch. type: "server" # Optional:vendor refers to whether it is a custom Dell image or generic vendor image. # Ex: If ESXi ISO image is generic then vendor is "vmware", if it is a Dell customized image then vendor is "dell". vendor: "vmware" # Required: osname can be either "esxi", "rhel", "wr" or "suse". osname: "esxi" # Optional: osversion refers to version of the OS type. osversion: "6.7.3"

62 Managing server configurations

# Required: osfilename is the ISO name. osfilename: "VMware-VMvisor-Installer-6.7.0.update03-14320388.x86_64.iso" # Optional: Provide the external IP address of the VM that is running Bare Metal Orchestrator, which is the location of the OVA file. The external IP address of Bare Metal Orchestrator is only needed if the operating system is installing on a server that is located on an external network. # externalIPAddr: " "

NOTE: The comments in the YAML file start with a hash character (#) and is followed by text or the name of the

attribute. You can remove # to un-comment and edit the attribute value.

This is an example snapshot of an updated rhel.yaml file.

apiVersion: mw.dell.com/v1 kind: Media metadata: name: os-media spec: # Required:type can be either "server" or "network" based on the hardware resource server or switch. type: "server" # Optional:vendor refers to whether it is a custom Dell image or generic vendor image. vendor: "redhat" # Required: osname can be either "esxi", "rhel", "wr" or "suse". osname: "rhel" # Optional: osversion refers to version of the OS type. osversion: "8.4" # Required: osfilename is the ISO name. osfilename: "rhel-8.4-x86_64-dvd.iso" # Optional: Provide the external IP address of the VM that is running Bare Metal Orchestrator, which is the location of the OVA file. The external IP address of Bare Metal Orchestrator is only needed if the operating system is installing on a server that is located on an external network. # externalIPAddr: " "

This is an example snapshot of an esxipxe.yaml media file for the web server. Use this media file when creating an ISO image file for ESXi.

NOTE: The <External_BMO_IP> is not required.

NOTE: The osfilename value should begin with the name of the webserver folder, if known. For

example, if the webserver folder name is isos, the filename value should read as: isos/VMware-VMvisor- Installer-7.0U2a-17867351.x86_64.iso.

apiVersion: mw.dell.com/v1 kind: Media metadata: name: esxi-7 spec: # media file must be available in https web server . osfilename: "VMware-VMvisor-Installer-7.0U2a-17867351.x86_64.iso" type: "server" vendor: "vmware" osname: "esxi" osversion: "7u2"

This is an example snapshot of a rhelpxe.yaml media file for the web server. Use this media file when creating an ISO image for RHEL.

NOTE: The <External_BMO_IP> is not required.

Managing server configurations 63

NOTE: The osfilename value should begin with the name of the webserver folder, if known. For

example, if the webserver folder name is isos, the filename value should read as: isos/VMware-VMvisor- Installer-7.0U2a-17867351.x86_64.iso.

apiVersion: mw.dell.com/v1 kind: Media metadata: name: rhel8.4 spec: # osfilename is the ISO file path in https web server, media file must be available in web server osfilename: "rhel-8.4-x86_64-dvd.iso" type: "server" vendor: "redhat" osname: "rhel" osversion: "8.4"

6. Save the file and quit the editor.

7. Create the media object.

bmo create media -f .yaml For example:

bmo create media -f esxi.yaml

8. View the created media object.

bmo get media

Create a driver media object

About this task

For ESXi installation, Bare Metal Orchestrator can perform custom driver installation by accessing the drivers from the Bare Metal Orchestrator's web server or an external web server.

Observe the following:

You can perform custom driver installations only when installing or upgrading an operating system on a Dell or Supermicro server.

You must be aware of ESXi compatibility metrics between different release versions, and each version has a device driver(s) version compatibility. You can access the VMware Compatibility Guide in the following web link: VMWare compatibility guide.

You must create a media object for each type of device driver. For example, if you want to install icen and ibbd drivers, create two different media objects.

Update the type and the version correctly in the driver media file, and the values must match with the operating system driver and version specification.

Operating system deployment can be successful even if any driver installation fails. After installation is complete, check the OSDetails field in the server status to ensure that all the drivers are installed successfully.

If any driver installation fails, install the driver manually and verify the installation.

To create a driver media object:

Steps

1. Establish a CLI session on the Bare Metal Orchestrator VM. For high availability configurations, establish a CLI session using the virtual IP (VIP) of the Load Balancers for the Bare Metal Orchestrator cluster.

2. Change the directory to ~/samples/osdriver-profile-files.

3. Create a driver media .yaml file for the uploaded ISO .exe, by copying the sample file.

cp .yaml

64 Managing server configurations

4. Edit the .yaml file in Vim or a similar editor.

For example:

vi osdriver_media.yaml

5. Customize the .yaml with the required configurations:

Update the name of the driver media object. For more information, see Metadata. Update the value for the driver media attributes. For more information, see Driver media field definitions.

# This is a sample osDriver CRD apiVersion: mw.dell.com/v1 kind: Osdriver metadata: name: icen spec: # Add fields here filePath: "http:// :81/data/driver/Intel- icen_1.7.3.0-1OEM.670.0.0.8169922-18990249.zip" type: "icen" version: "1.7.3"

6. Save the file and quit the editor.

7. Create the driver media object.

bmo create osdriver -f .yaml For example:

bmo create osdriver -f osdriver_media.yaml

8. View the created driver media object.

bmo get osdriver

Upload images and binary files to the web server

Prerequisites

Determine where on the web server you want to upload the image or binary file.

For high availability, images and binary files are uploaded to the web server located on the GC site.

About this task

You can use the Bare Metal Orchestrator CLI to upload ISO images, firmware images, json files, and more to folders located in the web server.

To upload the images using the Bare Metal Orchestrator GUI, see Bare Metal Orchestrator Web User Interface Guide.

NOTE: For OS installation through virtual media, upload the files to the isos folder in the web server. For OS installation

using PXE boot, upload the files directly to the web server and do not specify any folder for uploading.

Steps

1. Establish a CLI session on the Bare Metal Orchestrator VM. For high availability configurations, establish a CLI session using the virtual IP (VIP) of the Load Balancers for the Bare Metal Orchestrator cluster.

2. Optional: List images and binary files currently in the web server. Run:

bmo get fs To list the contents of a specific folder on the web server, run: bmo get fs -m

3. Run one of the following commands to upload an image or binary file to the web server: bmo upload fs -f

Managing server configurations 65

bmo upload fs --file 4. Run the following command to upload an image or binary file to a specific folder on the web server:

bmo upload fs -f -m NOTE:

You can use this command to either upload to an existing folder or create a new folder with the folder name you provide.

Confirm available free space on the node

About this task

Before installing an operating system on the Global Controller or a worker node, ensure there is sufficient free space available on them. For information about space requirements, see Operating system deployment.

Steps

1. Establish a CLI session on the Bare Metal Orchestrator VM. For high availability configurations, establish a CLI session using the virtual IP (VIP) of the Load Balancers for the Bare Metal Orchestrator cluster.

2. Run the following command to check the available free space.

df -TH Example output:

Filesystem Type Size Used Avail Use% Mounted on undev devtmpfs 17G 0 17G 0% /dev tmpfs tmpfs 3.4G 6.3G 3.4G 1% /run /dev/sdal ext4 158G 84G 67G 56% / tmpfs tmpfs 17G 0 17G 0% /dev/shm tmpfs tmpfs 5.3M 0 5.3M 0% /run/lock tmpfs tmpfs 17G 0 17G 0% /sys/fs/cgroup

The available free space for the server is shown in the Avail column of file system /dev/sdal.

Operating system attributes

To deploy an operating system, update the following attributes.

bios attributes: procVirtualization, bootMode, and serialPortAddress bmc attributes: rfsIgnoreCertWarning and serialRedirectEnable Operating system field definitions

For more information about each of the bios and bmc attributes and their supported values, see Server and hardware profile field definitions.

Verify operating system deployment - servers

About this task

To verify operating system deployment:

Steps

1. Establish a CLI session on the Bare Metal Orchestrator VM. For high availability configurations, establish a CLI session using the virtual IP (VIP) of the Load Balancers for the Bare Metal Orchestrator cluster.

2. Validate if the operating system installation is complete.

To validate in the CLI, see View servers and server status

66 Managing server configurations

When the Provisioning Status transitions from Busy to Ready state, the operating system installation is complete.

To validate in the iDRAC: a. Log in to iDRAC.

The Dashboard is displayed.

b. Under Virtual Console, click Start the Virtual Console.

The image displays the state of the remote console.

NOTE: If the operating system deployment fails, contact Dell Support. See Contacting Dell Support for details.

Delete images and binary files from the web server

About this task

You can use the Bare Metal Orchestrator CLI to delete ISO images, firmware images, json files, and more from the web server.

Steps

1. Establish a CLI session on the Bare Metal Orchestrator VM. For high availability configurations, establish a CLI session using the virtual IP (VIP) of the Load Balancers for the Bare Metal Orchestrator cluster.

2. Optional: List images and binary files currently in the web server. Run:

bmo get fs To list the contents of a specific folder on the web server, run: bmo get fs -m

3. Run one of the following commands to delete an image or binary file from the web server: bmo delete fs -f bmo delete fs --file

4. Run the following command to delete an image or binary file from a specific folder on the web server:

bmo delete fs -f -m

Operating system installation using PXE boot

Install an operating system using PXE booting onto a preboot execution environment (PXE). A PXE boot device allows servers to boot remotely over a network connection, replacing the use of a Compact Disc (CD) or Universal Serial Bus (USB) drive to install an operating system.

From Bare Metal Orchestrator, only the ESXi and RHEL operating systems are currently supported and can be installed onto a PXE boot device.

NOTE: Operating system installation on Supermicro servers is supported in Bare Metal Orchestrator through a PXE boot

device.

The steps to install an operating system onto a PXE boot device are similar to installing an operating system onto a server, with the following exceptions:

NOTE: Before you begin the installation process, the Switch configuration should include the mapping of the PXE port to

an iDRAC, or Supermicro server to enable inband communication. In addition, the inband connection needs to be enabled in

iDRAC and in Bare Metal Orchestrator.

When configuring the site.yaml file, add a dhcp subnet containing two dhcp pools with the required IP configurations. One pool for PXE boot, and the second pool for the installed Operating System. The PXE boot dhcp pool should contain the attribute allowMembers with the value of PXEClient. In addition, the following attributes require specific values to enable the use of a PXE boot device:

Attribute Value

dhcpDeployMode Server

Managing server configurations 67

Attribute Value

vendorClassIdentifier PXEClient

bootSize Greater than or equal to 1807

inBandIP Enter the VLAN IP of the site node network interface for which the inband connectivity to the server for the PXE- enabled interface is configured. This differs for each site.

Refer to the site_dhcp_pxe.yaml file in the Samples folder for an example of a site configuration file.

Upload the ISO image to the web server. For more information about how to upload an ISO image to the web server, see Upload images and binary files to the web server.

When installing the operating system through a hardware profile and connecting a PXE port to a server, you must ensure that the common port across all servers is connected. For example, the common port integrated nic1 port1 must be connected to all servers.

When configuring the spec fields for the server.yaml, media.yaml and site.yaml files, ensure that the following BIOS attributes are configured with the correct values to enable a PXE boot device:

Attribute Value Supported vendors

bootMode Uefi or Bios Dell, Supermicro

PXEDev1EnDis Enabled Dell, Supermicro

PXEDev12EnDis Dell

PXEDev3EnDis

PXEDev4EnDis

pxeDev1Interface The ID of the PXE NIC device. For example: NIC.Integrated.1-1-1

NOTE: The ID of the PXE NIC device can be found in the list of Network Boot options in the NIC section of the inventory.

Dell, Supermicro

pxeDev2Interface Dell

pxeDev3Interface

pxeDev4Interface

operatingsystemname pxe Dell, Supermicro

Refer to the site_dhcp_pxe.yaml, os_install_esxi_pxe.yaml, os_install_rhel_pxe.yaml files and the esxipxe.yaml and the rhelpxe.yaml media files in the Samples folder for an example of files configured for PXE boot.

Operating system upgrade - servers The procedure to upgrade the ESXi version that is currently installed on servers in the Bare Metal Orchestrator cluster is similar to the procedure used to provision servers. During the ESXi operating system upgrade, you can optionally overwrite the existing operating system with a fresh installation.

You can perform the following operations: Upgrade the current ESXi operating system version on one or multiple servers in the cluster. For information about version

compatibility, see VMWare vSphere Hypervisor (ESXi) interoperability matrix. Overwrite the existing ESXi operating system version on one or multiple servers with a fresh installation of the ESXi

operating system. Upgrade the current ESXi operating system version on one or multiple servers and simultaneously deploy new servers with

the upgrade ESXi operating system version. Verify the operating system update.

NOTE: Overwriting the existing ESXi operating system with a fresh installation replaces all current server settings with the

settings that you apply when deploying the upgraded operating system.

For more information about operating system deployments and minimum space requirements, see Operating system deployment.

68 Managing server configurations

Operating system upgrade workflow

The high-level flow of the ESXi operating system update is as follows: 1. Upload the ESXi ISO image of the target version to the web server using the Bare Metal Orchestrator CLI, see Upload

images and binary files to the web server. 2. Create a media object that references the target ESXi ISO in the web server. For more information, see Create a media

object. 3. Update the ESXi operating system version on one or multiple servers and optionally overwrite the existing operating system

deployment simultaneously by updating the Operating system attributes.

The following table describes the procedures that are used to upgrade the operating system.

Table 25. Upgrading ESXi operating system version

Operation Description

Update the ESXi operating system version on a server

Specify the name of the media object that references the target operating system ISO when you edit the server, see Edit server configuration.

Optionally, add the overwriteinstallation attribute to the server YAML file if you want to overwrite the existing ESXi version with a fresh installation of the specified operating system. For more information, see Operating system attributes.

Update the ESXi operating system version on multiple servers

Specify the name of the media object that references the target operating system ISO in a hardware profile and follow the procedure to provision multiple servers. See Create hardware profiles and Edit hardware profile configuration.

Optionally, add the overwriteinstallation attribute to the hardware profile YAML file if you want to overwrite the existing ESXi version with a fresh installation of the specified operating system. For more information, see Operating system attributes.

NOTE: Servers you target in the hardware profile that do not have the ESXi operating system installed get the upgrade version of the operating system applied. Servers that do have an older version of the ESXi operating system installed are upgraded.

Verify if the upgrade is successful on a server View servers and server status

View server inventory

Verify if the upgrade is successful on multiple servers

View hardware profiles

View hardware profile details

CAUTION: The server reboots several times during the upgrade. Do not manually shut down the server or

interrupt the upgrade process.

Pre-requisites

Before you upgrade the ESXi operating system: The server hardware must meet the requirements of the upgrade ESXi version and have enough free storage space available

for the operating system upgrade. Stop all VMs on the ESXi host before starting the ESXi upgrade process. The host must be put in to maintenance mode. If vMotion is not enabled, we recommend taking a backup of your host and your resources. If the ESXi host is managed by a vCenter, the vCenter version must be higher than or the same as the target ESXi version.

For example, VMware vCenter 7.0 can manage ESXi 7.0, ESXi 6.7, and ESXi 6.5, but vCenter 6.7 cannot manage ESXi 7.0 hosts. If your vCenter version is lower than the upgrade ESXi version, you must upgrade the vCenter version before proceeding to upgrade the ESXi operating system.

Managing server configurations 69

CAUTION: Follow the vSphere upgrade order; otherwise, the connection between the ESXi host and vCenter can

be lost.

Firmware update Use the Firmware update feature to upgrade or downgrade the firmware versions on one or more servers.

You can perform the following operations: View, create, edit, or delete firmware media objects. Update the media attributes while creating or editing a firmware media object.

For more information about the CLI commands for firmwaremedia, see the Bare Metal Orchestrator Command Line Interface Reference Guide.

Update the firmware versions of one or more types of firmware. For example, you can update the firmware version of BIOS, Diagnostics, Lifecycle controller, and so on.

Verify the firmware update.

The high-level flow of the firmware update is as follows: 1. Upload the firmware image to the web server using the Bare Metal Orchestrator CLI, see Upload images and binary files to

the web server.

2. Create a firmware media object. For more information, see Create a firmware media object. 3. Update the firmware versions on a server or on multiple servers at once.

The following table describes how you can update and verify the firmware versions.

Table 26. Updating and Verifying Firmware Versions

Operation Description

Update the firmware versions on a server Update the firmware attributes while creating or editing a server.

Create a server or multiple servers and update configurations

Edit server configuration NOTE: For more information about the attributes to be updated, see Firmware field definitions.

Update the firmware versions on multiple servers Update the firmware attributes while creating or editing a hardware profile.

Create hardware profiles

Edit hardware profile configuration

Verify if the firmware update is successful on a server

View servers and server status

View server inventory

Verify if the firmware update is successful on multiple servers

View hardware profiles

View hardware profile details

Create a firmware media object

About this task

You must create a firmware media object for each type of firmware update. For example, if you are updating firmware for both BIOS and diagnostics, create two different media objects.

Observe the following:

Bare Metal Orchestrator validates the firmware version against the version available in the sever for some firmware category. If the version provided in the firmware media is the same as that of the server, Bare Metal Orchestrator skips the firmware installation for the specific firmware. This optimization saves time, and thus allows quick onboarding of a

70 Managing server configurations

server. The supported firmware category types are: BIOS, BMC, Network, CPLD, Chipset, Diagnostics, OSDriverPack, EnterpriseSolutions, FiberChannel, Memory, Power, SASDrive, SASNonRaid, SASRaid, SecureSystemManagement, SerialATA, SolidStateStorage, SystemManagement, DeviceFirmware, IdentityModule, and Other.

NOTE: The Category field is mandatory for the creation of a firmware media object. A firmware media object cannot be

created with a custom category type.

Update the category and the version correctly in the firmware media file, and the version must match with the actual version of firmware. For example, if executable file "BIOS_499DG_WN64_1.0.2.EXE" is used, then the version is 1.0.2. If executable file "iDRAC-with-Lifecycle-Controller_Firmware_WGTYV_WN64_5.00.20.10_A00.EXE" is used, then the version is 5.00.20.10.

If the same firmware version and category type is already present in the iDRAC, the firmware update will not be applied.

To create a firmware media object:

Steps

1. Establish a CLI session on the Bare Metal Orchestrator VM. For high availability configurations, establish a CLI session using the virtual IP (VIP) of the Load Balancers for the Bare Metal Orchestrator cluster.

2. Change the directory to ~/samples/firmwaremedia.

3. Create a new firmware media .yaml file for the uploaded firmware images .exe, by copying the sample file.

cp .yaml 4. Edit the .yaml file in Vim or a similar editor.

For example:

vi fw_media.yaml

5. Customize the .yaml with the required configurations:

Update the name of the firmware media object. For more information, see Metadata. Update the value for the firmware media attributes. For more information, see Firmware media field definitions.

This is an example snapshot of the updated fw_media.yaml file:

apiVersion: "mw.dell.com/v1" kind: FirmwareMedia metadata: name: firmware-full spec: vendor: "dell" model: "r640" firmwareName: "OS Collector" category: "Diagnostics" version: "v0.6.0" imagefilename: "iDRAC-with-Lifecycle- Controller_Firmware_7CH5T_WN64_5.00.10.00_A00.EXE" # This field is optional. If the worker node for the site has an IP address that is not directly accessible from the BMC, enter the external IP address of the Bare Metal Orchestrator VM here. #externalIPAddr: "100.10.10.1"

6. Save the file and quit the editor.

7. Create the firmware media object.

bmo create firmwaremedia -f .yaml For example:

bmo create firmwaremedia -f fw_media.yaml

8. View the created firmware media object.

bmo get firmwaremedia

Managing server configurations 71

RAID configuration Use the RAID configuration feature to configure RAID volumes on one or more servers that have RAID controllers. To view the list of RAID hardware types supported in Bare Metal Orchestrator, see Validated hardware components. You can also create a virtual RAID 1 volume for RHEL OS installation using the PERC S150 Raid Controller.

NOTE: If the RAID controller is in the Enhanced HBA (eHBA) mode, then the Bare Metal Orchestrator sets the value to

RAID mode.

You can perform the following operations: Create RAID volumes and verify the creation. Delete RAID volumes and verify the deletion.

Prerequisite Before using an S150 RAID Controller to create a virtual RAID 1 volume, you must convert the PERC S150 RAID Controller

disks to RAID capable in Linux Mode. To do this, complete the following steps: 1. Access the iDRAC application in your web browser and launch the Virtual Console. 2. Navigate to the BIOS settings. 3. From the Device Settings, select DELL EMC PERC S150. 4. Select Controller Management, then select Convert to RAID Capable Disk. 5. From the Select Raid Type field, select Linux RAID, and then click Save.

The following table describes how you can create, delete, or verify the RAID configuration:

Table 27. RAID Configuration

Operation Description

Create the RAID volumes on a server Update the RAID attributes while creating or editing a server.

Create a server or multiple servers and update configurations

Edit server configuration NOTE: For more information about the RAID attributes to be updated, see RAID attribute definitions.

Create the RAID volumes on multiple servers Update the RAID attributes while creating or editing a hardware profile.

Create hardware profiles

Edit hardware profile configuration

Create a virtual RAID 1 volume on one or multiple servers

Follow the steps for creating a server on one or multiple servers. When configuring the Server Spec, you must include the following attribute under the raidVolumes section for the volume to be created using the S150 controller: swRaid: "Yes"

NOTE: If the swRaid value is "No", the virtual volumes are

created using Hardware PERC controllers. If there is no value provided for the swRaid attribute, any available Hardware or

Software RAID storage controller is used to create the volume.

You must also specify the RAID 1 volume in the Operating System Spec. See Operating system deployment workflow - servers for more information.

Delete a RAID volume or all RAID volumes on a server or on multiple servers

Delete the RAID volumes

Verify if the RAID volume creation or deletion is successful on a server

View servers and server status

View server inventory

Verify if the RAID volume creation or deletion is successful on multiple servers

View hardware profiles

View hardware profile details

72 Managing server configurations

Delete the RAID volumes

You can delete a specific RAID volume or all RAID volumes.

Steps

1. To delete a specific RAID volume:

Edit the server or a hardware profile .yaml:

a. Set the attribute deleteNonMatchingVolumes value as true.

b. Remove the specific RAID volume.

NOTE: For more information about:

RAID attribute definitions, see RAID attribute definitions.

Editing a server, see Edit server configuration.

Editing a hardware profile, see Edit hardware profile configuration.

2. To delete all RAID volumes:

Edit the server or a hardware profile .yaml:

a. Set the attribute deleteNonMatchingVolumes value as true.

b. Remove all RAID volumes.

Telemetry enablement Bare Metal Orchestrator can enable telemetry data collection and configure metrics to be captured from Dell servers.

You can collect metrics for individual servers or apply a hardware profile and collect metrics from multiple servers. The telemetry data that is captured can be used to trigger alerts or warnings, optimize server operations, and enhance cyber resilience. For information about the metric reports that you can generate and the attributes or fields for each of the metric reports, see Telemetry field definitions.

In Bare Metal Orchestrator, you can perform the following telemetry operations:

Enable telemetry for a server Enable telemetry for servers

In addition to the above operations, you can also perform view, edit, and delete telemetry operations. For information about the commands, see the topics, servertelemetry and profiletelemetry in the Bare Metal Orchestrator Command Line Interface Reference Guide.

NOTE: When you delete a hardware profile that is associated with a profile telemetry object, you have to first delete the

profile telemetry object before deleting the hardware profile. The profile telemetry object is not automatically deleted when

the hardware profile is deleted. However, if a server that is associated with a server telemetry object is deleted, the server

telemetry object automatically gets deleted.

Enable telemetry for a server

After you enable telemetry collection from a server, you can configure the telemetry metrics that Bare Metal Orchestrator will collect from the server.

About this task

Create a server telemetry instance using the server telemetry YAML file for the associated server. The YAML file contains a list of metric reports for Dell servers and the configuration attributes for each report. The server telemetry YAML file must be created with the same site label as that of the associated server. For information about the metric reports that you can generate and the attributes or fields for each of the metric reports, see Telemetry field definitions.

For information about the commands for server telemetry, see the Bare Metal Orchestrator Command Line Interface Reference Guide.

NOTE: The server telemetry name and the associated server name must be the same.

Managing server configurations 73

Complete the following steps:

Steps

1. Establish a CLI session on the Bare Metal Orchestrator VM. For high availability configurations, establish a CLI session using the virtual IP (VIP) of the Load Balancers for the Bare Metal Orchestrator cluster.

2. Change the directory to ~/samples/servers/.

3. Create a server telemetry YAML file by copying the sample file, telemetry_servertelemetry.yaml.

cp telemetry_servertelemetry.yaml .yaml

4. Edit the .yaml file in Vim or a similar editor.

5. Customize the .yaml file:

Update the metadata. For more information, see Metadata. Update the fields mentioned in Telemetry field definitions.

A sample server telemetry YAML file is available at Sample server telemetry YAML file.

6. Save the file and quit the editor.

7. Create the server telemetry instance with the following command:

bmo create servertelemetry -f .yaml 8. Onboard a server. Add the attributes, telemetryEnable and reconcileTelemetry to the server YAML file. For more information,

see Create a server or multiple servers and update configurations.

The following is an example of the server YAML file:

apiVersion: mw.dell.com/v1 kind: Server metadata: name: dell-r740-71 labels: site: gc location: pune spec: bmcEndPoint: "https://0.0.0.0" userName: "root" password: "password" telemetryEnable: Enabled reconcileTelemetry: true

9. Verify that telemetry is enabled, and metrics is configured on the server. For more information, see View servers and server status.

Enable telemetry for servers

You can apply a hardware profile to enable and collect metrics from multiple servers. After you enable telemetry collection in a hardware profile, you can configure the telemetry metrics that Bare Metal Orchestrator will collect from the servers.

About this task

Create a profile telemetry instance using the profile telemetry YAML file for the associated hardware profile. The file contains a list of metric reports for Dell servers and the configuration attributes for each report. The profile telemetry YAML file must be created with the same site label as that of the associated hardware profile. For information about the metric reports that you can generate and the attributes or fields for each of the metric reports, see Telemetry field definitions.

For information about the commands for profile telemetry, see the Bare Metal Orchestrator Command Line Interface Reference Guide.

NOTE: The profile telemetry name and the associated hardware profile name must be the same.

Complete the following steps:

74 Managing server configurations

Steps

1. Establish a CLI session on the Bare Metal Orchestrator VM. For high availability configurations, establish a CLI session using the virtual IP (VIP) of the Load Balancers for the Bare Metal Orchestrator cluster.

2. Change the directory to ~/samples/hardware-profiles/.

3. Create a profile telemetry YAML file by copying the sample file, telemetry_profiletelemetry.yaml.

cp telemetry_profiletelemetry.yaml .yaml

4. Edit the .yaml file in Vim or a similar editor.

5. Customize the .yaml file:

Update the metadata. For more information, see Metadata. Update the fields mentioned in Telemetry field definitions.

A sample profile telemetry YAML file is available at Sample profile telemetry YAML file.

6. Save the file and quit the editor.

7. Create the profile telemetry instance with the following command:

bmo create profiletelemetry -f .yaml 8. Create a hardware profile. Add the attributes, telemetryEnable and reconcileTelemetry to the hardware profile YAML file. For

more information, see Create hardware profiles.

The following is an example of the hardware profile YAML file:

apiVersion: mw.dell.com/v1 kind: HardwareProfile metadata: name: hardwareprofile-1 labels: site: gc spec: apply: false preview: true server: telemetryEnable: Enabled reconcileTelemetry: True

selectors: location: pune

NOTE: The hardware profile is applied to the targeted servers only when the apply attribute is set to true.

9. Verify that profile telemetry is enabled and metrics is configured on the server. For more information, see View servers and server status.

Managing server configurations 75

Managing web server A web server is required to host files and images which can be utilized for various Bare Metal Orchestrator operations such as PXE and TCP stack deployment. You can perform basic web server operations such as view, upload, download and delete.

Topics:

View files on web server Upload files to the web server Download files from web server Delete files from the web server

View files on web server

Prerequisites

About this task

You can use the Bare Metal Orchestrator CLI or web UI to view the files on the web server.

Steps

1. Establish a CLI session on the Bare Metal Orchestrator VM. For high availability configurations, establish a CLI session using the virtual IP (VIP) of the Load Balancers for the Bare Metal Orchestrator cluster.

2. Run the following command to list the files transferred to the default storage path in the web server.

bmo get fs 3. Run the following command to list the files from a specific folder in the web server.

bmo get fs -m

Upload files to the web server

Prerequisites

Determine where on the web server you want to upload the files.

For high availability, images and binary files are uploaded to the web server located on the GC site.

About this task

You can use the Bare Metal Orchestrator CLI to upload ISO images, firmware images, json files, and more to the webserver.

NOTE: To upload the images using the Bare Metal Orchestrator GUI, see Bare Metal Orchestrator Web User Interface

Guide.

Steps

1. Establish a CLI session on the Bare Metal Orchestrator VM. For high availability configurations, establish a CLI session using the virtual IP (VIP) of the Load Balancers for the Bare Metal Orchestrator cluster.

2. Optional: List images and binary files currently in the web server. Run:

bmo get fs

9

76 Managing web server

To list the contents of a specific folder on the web server, run: bmo get fs -m

3. Run one of the following commands to upload an image or binary file to the web server: bmo upload fs -f bmo upload fs --file

4. Run the following command to upload an image or binary file to a specific folder on the web server:

bmo upload fs -f -m NOTE:

You can use this command to either upload to an existing folder or create a new folder with the folder name you provide.

Download files from web server

Prerequisites

About this task

You can use the Bare Metal Orchestrator CLI to download the files from the webserver.

Steps

1. Establish a CLI session on the Bare Metal Orchestrator VM. For high availability configurations, establish a CLI session using the virtual IP (VIP) of the Load Balancers for the Bare Metal Orchestrator cluster.

2. Run the following command to download a specific file from the web server.

bmo download fs -f > bmo download fs --file

3. Run the following command to download a file from a specific folder in the web server.

bmo download fs -f -m

Delete files from the web server

Prerequisites

About this task

You can use the Bare Metal Orchestrator CLI to delete files from the web server.

Steps

1. Establish a CLI session on the Bare Metal Orchestrator VM. For high availability configurations, establish a CLI session using the virtual IP (VIP) of the Load Balancers for the Bare Metal Orchestrator cluster.

2. Optional: List images and binary files currently in the web server. Run:

bmo get fs To list the contents of a specific folder on the web server, run: bmo get fs -m

3. Run one of the following commands to delete an image or binary file from the web server: bmo delete fs -f bmo delete fs --file

4. Run the following command to delete an image or binary file from a specific folder on the web server:

bmo delete fs -f -m

Managing web server 77

Managing switches

Topics:

Switch overview Create a switch and update configurations Edit switch configuration View switches and switch status View switch inventory Reinitialize a switch Delete a switch Onboard a Cisco switch in Bare Metal Orchestrator

Switch overview Bare Metal Orchestrator can onboard a switch in ONIE, NOS, or NSO mode.

ONIE and NOS modes are for onboarding Dell switches. In the ONIE mode, you can collect switch inventory details such as the boot mode. You can also install the Dell OS10 operating system. After you install the operating system, the mode changes to NOS.

In the NOS mode, the switch controller connects through the management interface of the switch and collects inventory details. For information about onboarding Dell switches, see Managed device discovery overview.

The NSO mode is for onboarding Cisco switches. To onboard a Cisco switch, you must first register a Cisco NSO instance in Bare Metal Orchestrator. Bare Metal Orchestrator then communicates with the switch using this instance and a nso-sku- pack to collect inventory details. For information about onboarding a Cisco switch, see Onboard a Cisco switch in Bare Metal Orchestrator.

Switch configuration is performed with YAML files on Bare Metal Orchestrator. These files are templates that contain configuration settings for an individual switch. You can update the file with attributes that can trigger specific work flows like firmware updates and operating system deployment. You can use the sample switch YAML file to create a switch, update the required configurations, and apply them on the target switch.

For more information about the supported configurations, see Managing switch configurations.

You can perform the following operations on a switch:

Creating, editing, and deleting a switch Viewing switch inventory details Reinitializing a switch

Create a switch and update configurations Use the following steps to create a switch and update configurations.

Prerequisites

Gather the IP address and credentials that have administrative access from the management interface of the switch. Gather information about the mode of the switch by connecting to the switch. Meet the hardware and software requirements. For more information, see Validated hardware components. Decide on your configuration requirements. For more information, see Managing switch configurations.

About this task

To create a switch or update configurations:

10

78 Managing switches

Steps

1. Establish a CLI session on the Bare Metal Orchestrator VM. For high availability configurations, establish a CLI session using the virtual IP (VIP) of the Load Balancers for the Bare Metal Orchestrator cluster.

2. Change the directory to ~/samples/switch-profiles.

3. Create a switch YAML file by copying the sample file. If the switch is in ONIE mode, use mw_dell_switch_onie_mode.yaml. If the switch is in NOS mode, use mw_dell_switch_nos_mode.yaml.

cp .yaml .yaml

4. Edit the .yaml file in Vim or a similar editor.

For example:

vim dell_switch_new.yaml

5. Customize the .yaml file:

Update the metadata. For more information, see Metadata. Update the fields mentioned in the Switch connectivity field definitions. Update the attribute values based on the configurations you want to perform. For more information about the switch

configurations, see Managing switch configurations. If you are only onboarding a switch and do not want to make any configuration changes, omit this step.

NOTE: For a switch created in the ONIE mode, the ONIE password is optional. Set the attribute to None.

6. Save the file and quit the editor.

7. Create the switch instance.

bmo create switch -f .yaml For example:

bmo create switch -f dell_switch_new.yaml

Edit switch configuration Update the attributes in the switch YAML file based on the configurations that you want to perform.

About this task

Complete the following steps:

Steps

1. Establish a CLI session on the Bare Metal Orchestrator VM. For high availability configurations, establish a CLI session using the virtual IP (VIP) of the Load Balancers for the Bare Metal Orchestrator cluster.

2. Edit the .yaml file with Vim or a similar editor.

For example:

vim dell_switch_new.yaml

3. Update the attribute values based on the configurations you want to perform. For more information about the switch attributes, see: Switch operating system field definitions Switch connectivity field definitions Switch common field definitions

4. Save the file and quit the editor.

5. Edit the switch configuration.

If the switch is associated with a tenant, run the following command:

bmo edit switch -n

Managing switches 79

If the switch is not associated with a tenant, run the following command:

bmo edit switch -f .yaml

View switches and switch status To view the list of switches that are onboarded or the switch status:

Steps

1. Establish a CLI session on the Bare Metal Orchestrator VM. For high availability configurations, establish a CLI session using the virtual IP (VIP) of the Load Balancers for the Bare Metal Orchestrator cluster.

2. View switch details.

If the switch is associated with a tenant, run the following command:

bmo get switch -n If the switch is not associated with a tenant, run the following command:

bmo get switch

Retrieves the list of switches and switch details.

The following is an example output for a successful switch configuration:

NAME SWITCH MODE PROVISIONING COMMAND EXECUTING SITE LOCATION AGE switch-dell onie Ready gc 8s

When the Provisioning Status transitions from Busy to Ready state, onboarding the switch is successful.

View switch inventory To view detailed inventory information about the switch:

Steps

1. Establish a CLI session on the Bare Metal Orchestrator VM. For high availability configurations, establish a CLI session using the virtual IP (VIP) of the Load Balancers for the Bare Metal Orchestrator cluster.

2. View switch inventory.

If the switch is associated with a tenant, run the following command:

bmo describe switch -n If the switch is not associated with a tenant, run the following command:

bmo describe switch

The metadata, spec, and status fields are displayed. For more information about the fields, see YAML objects and common fields and Switch field definitions.

Reinitialize a switch You can reinitialize a switch on one or multiple nodes in a cluster. Reinitialization is useful for reinstating a failed switch after the issue that was causing the failure is resolved. For a switch in the ready state, reinitializing recollects the switch's inventory.

Prerequisites

Nodes must be configured and discoverable.

80 Managing switches

About this task

To reinitialize a switch, set the reInitialize attribute value to true in the switch YAML file. The reInitialize attribute is automatically removed from the YAML file after it is run.

When a switch is not in a failed state, Bare Metal Orchestrator performs these reinitialization steps:

1. Rerun inventory against the switch. 2. Reconcile the switch. 3. Reapply any configuration profile that targets the switch and then reinstate the switch.

For a switch in a failed state, Bare Metal Orchestrator takes the switch out of the failed state before reinitializing.

Steps

1. Establish a CLI session on the Bare Metal Orchestrator VM. For high availability configurations, establish a CLI session using the virtual IP (VIP) of the Load Balancers for the Bare Metal Orchestrator cluster.

2. Edit the .yaml file with Vim or a similar editor.

For example:

vim device_switch.yaml

3. Add the reInitialize attribute in the .yaml file and enter the value true.

For example:

apiVersion: mw.dell.com/v1 kind: Switch metadata: name: switch1 namespace: metalweaver labels: site: gc spec: metadata: {} systemmode: - nos - onie - nso mgmtipaddress: password: 123456 username: admin onie: ipaddress: mac: 'mac_address' password: 123456 username: root reInitialize: true enableRestConf: true continued ...

4. Save the file and quit the editor.

5. Run the following command:

bmo edit switch -f .yaml

Delete a switch To delete a switch:

Steps

1. Establish a CLI session on the Bare Metal Orchestrator VM. For high availability configurations, establish a CLI session using the virtual IP (VIP) of the Load Balancers for the Bare Metal Orchestrator cluster.

2. Delete a switch.

If the switch is associated with a tenant, run the following command:

Managing switches 81

bmo delete switch -n If the switch is not associated with a tenant, run the following command:

bmo delete switch

Onboard a Cisco switch in Bare Metal Orchestrator To onboard a Cisco switch, you must first register a Network Service Orchestrator (NSO) instance in Bare Metal Orchestrator.

Prerequisites

Register the NSO instance. For more information, see Register an NSO instance in Bare Metal Orchestrator.

About this task

Complete the following steps:

Steps

1. Establish a CLI session on the Bare Metal Orchestrator VM. For high availability configurations, establish a CLI session using the virtual IP (VIP) of the Load Balancers for the Bare Metal Orchestrator cluster.

2. Change the directory to ~/samples/switch-profiles.

3. Create a switch YAML file by copying the sample file, mw_cisco_switch_nso_mode.yaml.

cp .yaml .yaml

4. Edit the .yaml file in Vim or a similar editor.

For example:

vim cisco_switch_new.yaml

5. Customize the .yaml file:

Update the metadata. For more information, see Metadata. Update the fields mentioned in Cisco switch field definitions.

This is an example switch.yaml file for a Cisco switch:

apiVersion: mw.dell.com/v1 kind: Switch metadata: name: Ciswitch labels: site: gc spec: devicename: cisco-nexus mgmtipaddress: username: admin password: " " vendor: Cisco model: Nexus mode: nso sdncontroller: nso3 devicetype: "cli" nedid: cisco-nx-cli-5.22:cisco-nx-cli-5.22 port: "8080" adminstate: "unlocked" authgroup: "myauthgroup"

6. Save the file and quit the editor.

7. Create the switch instance with the following command:

bmo create switch -f .yaml

82 Managing switches

For example:

bmo create switch -f cisco_switch_new.yaml

8. Verify that the Cisco switch was onboarded successfully. For more information, see View switches and switch status and View switch inventory.

After onboarding a Cisco switch, you can configure Layer 2 VLAN, Layer 3 VLAN, and Ethernet interface settings on the switch. For more information, see:

Layer 2 VLAN configuration - Cisco switch Layer 3 VLAN configuration - Cisco switch Ethernet interface configuration - Cisco switch

Register an NSO instance in Bare Metal Orchestrator

In Bare Metal Orchestrator, to register a Network Services Orchestrator (NSO) instance, a SDNController YAML file is created.

About this task

The network controller in Bare Metal Orchestrator uses the file to communicate with NSO.

Complete the following steps:

Steps

1. Establish a CLI session on the Bare Metal Orchestrator VM. For high availability configurations, establish a CLI session using the virtual IP (VIP) of the Load Balancers for the Bare Metal Orchestrator cluster.

2. Change the directory to ~/samples/switch-profiles.

3. Create a SDNController YAML file by copying the sample file, mw_cisco_nso_sdncontroller.yaml.

cp .yaml .yaml

4. Edit the .yaml file in Vim or a similar editor.

For example:

vim sdn_nso.yaml

5. Customize the .yaml file:

Update the attributes in the SDNController YAML file. For more information, see SDNController field definitions.

This is an example sdncontroller.yaml file for a Cisco switch:

# This is sample SDNController spec apiVersion: mw.dell.com/v1 kind: SDNController metadata: name: nso3 labels: site: gc spec: ipaddress: username: Password:

6. Save the file and quit the editor.

7. Create the NSO instance with the following command:

bmo create sdncontroller -f .yaml

Managing switches 83

Managing switch configurations

Topics:

Operating system deployment - Dell switch Operating system deployment workflow - Dell switch Create a media object - Dell switch Verify operating system deployment - Dell switch License deployment workflow - Dell switch Create a license media object - Dell switch Operating system upgrade - Dell switch Firmware update - Dell switch Create a firmware media object - Dell switch Layer 2 VLAN configuration - Cisco switch Layer 3 VLAN configuration - Cisco switch Ethernet interface configuration - Cisco switch

Operating system deployment - Dell switch Operating system deployment is the process of installing an operating system on a switch.

See Validated hypervisors and operating systems for the switch operating system that Bare Metal Orchestrator can deploy.

You can perform the following operations: View, create, edit, or delete media objects. Update the media attributes while creating or editing a media object.

For more information about the CLI commands for media, see the Bare Metal Orchestrator Command Line Interface Reference Guide.

Install the operating system. Verify the operating system installation.

Operating system deployment workflow - Dell switch The switch must be in the Open Network Install Environment (ONIE) mode to install the operating system.

Prerequisites

There must be enough free space to install the operating system.

About this task

Complete the following steps to install the operating system on a switch:

Steps

1. Onboard a switch in the ONIE mode using a switch YAML file. A sample YAML file, mw_dell_switch_onie_mode.yaml is located at ~/samples/switch-profiles. For more information, see Create a switch and update configurations.

2. Upload the NOS image file to the web server using the Bare Metal Orchestrator CLI:

bmo upload fs -f

11

84 Managing switch configurations

3. Create a media object that references the target NOS image file that is stored in the web server. For more information, see Create a media object - Dell switch.

4. Edit the switch. In the switch YAML file, set the operatingsystemname attribute to the media name. For more information, see: Switch operating system field definitions Edit switch configuration

5. Verify the operating system installation. For more information, see Verify operating system deployment - Dell switch.

6. Assign the management IP address of the switch manually after the operating system installation.

7. Edit the switch. In the switch YAML file, change the systemmode to NOS, provide the mgmtipaddress, username, and password.

Create a media object - Dell switch To install or upgrade the operating system for a Dell switch, you require a media object.

About this task

To create a media object:

Steps

1. Establish a CLI session on the Bare Metal Orchestrator VM. For high availability configurations, establish a CLI session using the virtual IP (VIP) of the Load Balancers for the Bare Metal Orchestrator cluster.

2. Change the directory to ~/samples/media.

3. Create a media YAML file for the uploaded image file by copying the sample file, os10.yaml.

cp .yaml .yaml 4. Edit the .yaml file in Vim or a similar editor.

For example:

vi os10.yaml

5. Customize the .yaml with the required configurations:

Update the name of the media object. For more information, see Metadata. Update the value for the media attributes. For more information, see Media field definitions.

The following is an example snapshot of a media.yaml file for a switch:

apiVersion: mw.dell.com/v1 kind: Media metadata: name: os10media spec: # Required type: "switch" # Optional: vendor refers to whether a Dell EMC customized image or generic vendor image. # Ex: If ESXi ISO image is generic then vendor is "vmware", if it is a Dell customized image then vendor is "dell". vendor: "dell" # Required osname: "os10" # Optional: osversion refers to version of the OS type. # Normal version must take the form X.Y.Z where X is major version, Y is minor version and Z is the patch version. osversion: "10.5.0.3" # Required: osfilename is the os image. osfilename: "PKGS_OS10-Enterprise-10.5.0.3P1.612stretch-installer-x86_64.bin" # Optional: externalIPAddr is required for routing purpose if BMO can't directly reach the switch through the static IP. externalIPAddr: ""

Managing switch configurations 85

6. Save the file and quit the editor.

7. Create the media object with the following command:

bmo create media -f .yaml For example:

bmo create media -f os10.yaml

8. View the created media object with the following command:

bmo get media

Verify operating system deployment - Dell switch To verify the operating system deployment:

Steps

1. Establish a CLI session on the Bare Metal Orchestrator VM. For high availability configurations, establish a CLI session using the virtual IP (VIP) of the Load Balancers for the Bare Metal Orchestrator cluster.

2. Validate that the operating system installation is complete.

To validate in the CLI, see View switches and switch status.

When the Provisioning Status transitions from Busy to Ready state, the operating system installation is complete.

NOTE: If the operating system deployment fails, contact Dell Support. See Contacting Dell Support for details.

License deployment workflow - Dell switch The switch must be in the Network Operating System (NOS) mode to install the Dell OS10 license.

About this task

Complete the following steps to install the license on a switch:

Steps

1. Onboard a switch in the NOS mode using a switch YAML file. A sample YAML file, mw_dell_switch_nos_mode.yaml, is located in ~/samples/switch-profiles. For more information, see Create a switch and update configurations.

2. Upload the license file to the web server using the Bare Metal Orchestrator CLI:

bmo upload fs -f

3. Create a media object that references the target license file that is stored in the web server. For more information, see Create a license media object - Dell switch.

4. Edit the switch. In the switch YAML file, set the licensekey attribute to the license media name. For more information about editing the switch, see Edit switch configuration.

5. Verify the license installation and status. For more information, see the following:

View switches and switch status View switch inventory

86 Managing switch configurations

Create a license media object - Dell switch Create a license media object to install Dell OS10 license on a switch.

About this task

To create a license media object:

Steps

1. Establish a CLI session on the Bare Metal Orchestrator VM. For high availability configurations, establish a CLI session using the virtual IP (VIP) of the Load Balancers for the Bare Metal Orchestrator cluster.

2. Change the directory to ~/samples/licensemedia.

3. Create a license media YAML file for the uploaded license image by copying the sample file, mw_dell_licensemedia_sample.yaml.

cp .yaml .yaml 4. Edit the .yaml file in Vim or a similar editor.

For example:

vi license_media.yaml

5. Customize the .yaml file with the required configurations:

Update the name of the license media object. For more information, see Metadata. Provide the license file name in the licensefilename attribute. Optional: Provide the external IP address of the VM that is running Bare Metal Orchestrator in the externalIPAddr

attribute.

The following is an example snapshot of the updated license_media.yaml file:

apiVersion: mw.dell.com/v1 kind: LicenseMedia metadata: name: lmedia spec: licensefilename: license_213.xml # Optional: externalIPAddr is required for routing purpose if Bare Metal Orchestrator can't directly reach the switch through the static IP address. externalIPAddr: ""

6. Save the file and quit the editor.

7. Create the license media object with the following command:

bmo create licensemedia -f .yaml For example:

bmo create licensemedia -f license_media.yaml

8. View the created license media object with the following command:

bmo get licensemedia 9. Verify the license inventory details with the following command:

bmo describe licensemedia

Managing switch configurations 87

Operating system upgrade - Dell switch Perform an operating system upgrade on a Dell switch only if the switch is in NOS mode.

About this task

For an operating system upgrade, in the switch YAML file, the attributes, operatingsystemname and overwriteinstallation are required. The operatingsystemname attribute is set to the operating system media name. The upgrade is performed only if the overwriteinstallation attribute is set to true.

Complete the following steps for a NOS operating system upgrade of a Dell switch:

Steps

1. Upload the NOS operating system image file to the web server using the Bare Metal Orchestrator CLI:

bmo upload fs -f

2. Create a media object that references the target NOS operating system image file that is stored in the web server. For more information, see Create a media object - Dell switch.

3. Edit the switch configuration. In the switch YAML file, add the operating system name and set the overwriteinstallation attribute to true. For more information, see the following:

Switch operating system field definitions Edit switch configuration

4. Verify that the upgrade is successful and check the NOS version. For more information, see the following:

View switches and switch status View switch inventory

Firmware update - Dell switch Use the firmware update feature to upgrade or downgrade the firmware version on a switch in NOS mode.

About this task

You can perform the following operations:

View, create, edit, or delete firmware media objects. Update the media attributes while creating or editing a firmware media object. For more information about the CLI

commands for firmware media, see the Bare Metal Orchestrator Command Line Interface Reference Guide. Update the firmware version. Verify the firmware update.

Complete the following steps to update firmware for a switch in NOS mode:

Steps

1. Upload the firmware image to the web server using the Bare Metal Orchestrator CLI:

bmo upload fs -f

2. Create a firmware media object. For more information, see Create a firmware media object - Dell switch.

3. Update the firmware attributes while creating or editing a switch. Provide the firmwareName in the switch YAML file:

NOTE: The switch model attribute in the firmwaremedia YAML file and the switch YAML file must be the same.

To update the firmware attributes while creating a switch, see Create a switch and update configurations. To update the firmware attributes while editing a switch, see Edit switch configuration. For information about the firmware attributes, see Firmware media field definitions.

4. Verify that the firmware update is successful and check the firmware version. For more information, see the following:

88 Managing switch configurations

View switches and switch status View switch inventory

Create a firmware media object - Dell switch Create a firmware media object for a firmware update.

About this task

To create a firmware media object:

Steps

1. Establish a CLI session on the Bare Metal Orchestrator VM. For high availability configurations, establish a CLI session using the virtual IP (VIP) of the Load Balancers for the Bare Metal Orchestrator cluster.

2. Change the directory to ~/samples/firmwaremedia.

3. Create a firmware media YAML file for the uploaded firmware image by copying the sample file, firmware_onie.yaml.

cp .yaml 4. Edit the .yaml file in Vim or a similar editor.

For example:

vi fw_media.yaml

5. Customize the .yaml file with the required configurations:

Update the name of the firmware media object. For more information, see Metadata. Update the value for the firmware media attributes. For more information, see Firmware media field definitions.

This is an example snapshot of the updated fw_media.yaml file:

# This is a sample firmware media spec apiVersion: mw.dell.com/v1 kind: FirmwareMedia metadata: name: firmwareDellSwitch spec: type: "switch" vendor: "dell" model: "S5212F-ON" firmwareName: "ONIE-Update" category: "DeviceFirmware" version: "v0.3.40" imagefilename: "onie-firmware-x86_64-dellemc_s5200_c3538-r0.3.40.5.1-20.bin" # This field is optional. If the worker node for the site has an IP address that is not directly accessible from the BMC, enter the external IP address of the Bare Metal Orchestrator VM here. #externalIPAddr: " "

6. Save the file and quit the editor.

7. Create the firmware media object with the following command:

bmo create firmwaremedia -f .yaml For example:

bmo create firmwaremedia -f fw_media.yaml

8. View the created firmware media object with the following command:

bmo get firmwaremedia 9. Verify the firmware version with the following command:

bmo describe firmwaremedia

Managing switch configurations 89

Layer 2 VLAN configuration - Cisco switch Configure Layer 2 VLAN on a Cisco switch with the following steps:

Steps

1. Onboard a switch in the NSO mode. For more information, see Onboard a Cisco switch in Bare Metal Orchestrator.

2. Change the directory to ~/samples/switch-profiles.

3. Create a switchportconfig YAML file by copying the sample file, mw_cisco_switchportconfig_access_mode.yaml.

cp .yaml .yaml

4. Edit the .yaml file in Vim or a similar editor.

5. Customize the .yaml file:

Update the attributes in the switchportconfig YAML file. For more information, see Switch port configuration field definitions.

This is an example switchportconfig.yaml file for a Cisco switch:

apiVersion: mw.dell.com/v1 kind: SwitchPortConfig metadata: name: spec: l2Vlan: - vlanID: 999 shutdown: false description: "test1l2vlan"

6. Save the file and quit the editor.

7. Create the switchportconfig YAML file with the following command:

bmo create switchportconfig -f switchportconfig.yaml 8. Edit the Cisco switch configuration with the following command:

bmo edit switch -f .yaml In the switch YAML file, add the switchPortConfig attribute under the IncludeConfig section and assign a value. For example, switch-port-config-1 to apply the Layer 2 VLAN configuration.

9. Verify the updated details. For more information, see View switches and switch status and View switch inventory.

Layer 3 VLAN configuration - Cisco switch Configure Layer 3 VLAN on a Cisco switch with the following steps:

Steps

1. Onboard a switch in the NSO mode. For more information, see Onboard a Cisco switch in Bare Metal Orchestrator.

2. Change the directory to ~/samples/switch-profiles.

3. Create a switchportconfig YAML file by copying the sample file, mw_cisco_switchportconfig_access_mode.yaml.

cp .yaml .yaml

4. Edit the .yaml file in Vim or a similar editor.

5. Customize the .yaml file:

Update the attributes in the switchportconfig YAML file. For more information, see Switch port configuration field definitions.

This is an example switchportconfig.yaml file for a Cisco switch:

apiVersion: mw.dell.com/v1 kind: SwitchPortConfig metadata:

90 Managing switch configurations

name: spec: l3Vlan: name: "699" description: "test1l3vlan" mtu: 9216 ipaddress: redirects: false

6. Save the file and quit the editor.

7. Create the switchportconfig YAML file with the following command:

bmo create switchportconfig -f switchportconfig.yaml 8. Edit the Cisco switch configuration with the following command:

bmo edit switch -f .yaml In the switch YAML file, add the switchPortConfig attribute under the IncludeConfig section and assign a value. For example, switch-port-config-1 to apply the Layer 3 VLAN configuration.

9. Verify the updated details. For more information, see View switches and switch status and View switch inventory.

Ethernet interface configuration - Cisco switch Set the mode for the Ethernet interface on a Cisco switch with the following steps:

Steps

1. Onboard a switch in the NSO mode. For more information, see Onboard a Cisco switch in Bare Metal Orchestrator.

2. Change the directory to ~/samples/switch-profiles.

3. Create a switchportconfig YAML file by copying the sample file, switch_port_config_trunk_mode.yaml.

cp .yaml .yaml

4. Edit the .yaml file in Vim or a similar editor.

5. Customize the .yaml file:

Update the attributes in the switchportconfig YAML file. For more information, see Switch port configuration field definitions.

This is an example switchportconfig.yaml file for a Cisco switch:

apiVersion: mw.dell.com/v1 kind: SwitchPortConfig metadata: name: switch-port-config-1 spec: interfaceConfig: name:"2/10" switchport: true mode : "trunk" mtu:9216 trunkVlan: -149 -159

6. Save the file and quit the editor.

7. Create the switchportconfig YAML file with the following command:

bmo create switchportconfig -f switchportconfig.yaml 8. Edit the Cisco switch configuration with the following command:

bmo edit switch -f .yaml In the switch YAML file, add the switchPortConfig attribute under the IncludeConfig section and assign a value. For example, switch-port-config-1 to apply the Ethernet interface configuration.

9. Verify the updated details. For more information, see View switches and switch status and View switch inventory.

Managing switch configurations 91

After applying the Ethernet interface configuration, you can perform the following:

To change the Ethernet interface port mode, see Change the Ethernet interface port mode - Cisco switch. To assign an IP address for the Ethernet interface, see Set the IP address for the Ethernet interface - Cisco switch.

Change the Ethernet interface port mode - Cisco switch

Prerequisites

Create the switchportconfig YAML file and apply the Ethernet interface configuration. For more information, see Ethernet interface configuration - Cisco switch.

About this task

Change the port mode of the Ethernet interface from trunk to access for a Cisco switch with the following steps:

Steps

1. Establish a CLI session on the Bare Metal Orchestrator VM. For high availability configurations, establish a CLI session using the virtual IP (VIP) of the Load Balancers for the Bare Metal Orchestrator cluster.

2. Edit your switchportconfig YAML file with the following command:

bmo edit switchportconfig -f switchportconfig.yaml

3. Customize the switchportconfig.yaml file:

Under the interfaceConfig section, set the mode attribute to access.

Remove attributes that are related to the trunk mode. Add the accessVLAN attribute and provide a value.

This is an example switchportconfig.yaml file with the updated configuration:

apiVersion: mw.dell.com/v1 kind: SwitchPortConfig metadata: name: switch-port-config-1 spec: interfaceConfig: name:"2/10" switchport: true mode : "access" mtu:9216 accessVlan: 109 l2Vlan: vlanID: shutdown: false description: l3Vlan: name: description: mtu: ipaddress: redirects: false

4. Edit the Cisco switch configuration with the following command:

bmo edit switch -f .yaml In the switch YAML file, add the reConfigure attribute and set it to true. The attribute applies the updated configuration on the switch.

5. Verify the updated details. For more information, see View switches and switch status and View switch inventory.

92 Managing switch configurations

Set the IP address for the Ethernet interface - Cisco switch

Prerequisites

Create the switchportconfig YAML file and apply the Ethernet interface configuration. For more information, see Ethernet interface configuration - Cisco switch.

About this task

Assign an IP address for the Ethernet interface with the following steps:

Steps

1. Establish a CLI session on the Bare Metal Orchestrator VM. For high availability configurations, establish a CLI session using the virtual IP (VIP) of the Load Balancers for the Bare Metal Orchestrator cluster.

2. Edit the switchportconfig YAML file with the following command:

bmo edit switchportconfig -f switchportconfig.yaml

3. Customize the switchportconfig.yaml file:

Under the interfaceConfig section, remove attributes that are related to the mode. Set the switchport attribute to false.

Add the ipaddress attribute and provide the interface IP address.

This is an example switchportconfig.yaml file with the updated configuration:

apiVersion: mw.dell.com/v1 kind: SwitchPortConfig metadata: name: switch-port-config-1 spec: interfaceConfig: name:"2/10" switchport: false mtu:9216 ipaddress: l2Vlan: vlanID: shutdown: false description: l3Vlan: name: description: mtu: ipaddress: redirects: false

4. Edit the Cisco switch configuration with the following command:

bmo edit switch -f .yaml In the switch YAML file, add the reConfigure attribute and set it to true. The attribute applies the updated configuration on the switch.

5. Verify the updated details. For more information, see View switches and switch status and View switch inventory.

Managing switch configurations 93

VMware TCP Stack deployment This chapter contains the following topics:

Topics:

Introduction Create configuration files Deploying a stack Reinitializing a stack Grow a stack (new domain) Grow a stack (existing domain) Get stack Describe stack Edit a stack configuration Delete a stack instance

Introduction

Bare Metal Orchestrator supports the deployment of VMware Telco Cloud Platform (TCP) 2.0.

VMware TCP is a cloud-native platform that enables CSPs to rapidly deploy and efficiently operate multi-vendor CNFs and VNFs, with agility and scalability across 5G networks that span from the core and the edge to the radio access network (RAN). The two fundamental elements of this architecture are VMware Telco Cloud Infrastructure, and the VMware Telco Cloud Automation (TCA) tool, which is the installer used for VMware TCP stack deployment.

VMware TCP stack deployment supports four types of deployment models, also known as domains.

Table 28. Domain types for TCP stack deployment -TCP RAN sites

Domain type Minimum number of servers required

Central Site 4

Regional Site 4

Compute Cluster 3

Cell Site Group 1

Table 29. Domain types for TCP stack deployment -TCP Core sites

Domain type Minimum number of servers required

Central Site 4

Central Site Management Domain 4

Central Site Workload Domain 3

NOTE: You need to have at least one Central Site to deploy VMware TCP. Other domains are optional.

These deployment models and their configurations need to be provided to Bare Metal Orchestrator before the VMware TCP stack can be deployed.

12

94 VMware TCP Stack deployment

Prerequisites

The following prerequisites have to be met before you can deploy VMware TCP stack with Bare Metal Orchestrator:

Install ESXi 7.0 update 1 on all servers on which the stack will be deployed. All servers should be of the same model type and have the same hardware. For more information about installing the operating system, see Operating system deployment.

Buy and install licenses for all components in the VMware software bundle that is used to deploy, monitor, and manage the VMware TCP stack. The bundle has the following components: VMware ESXi VMware vCenter Server VMware NSX-T VMware vSAN VMware Tanzu Kubernetes Grid VMware Telco Cloud Automation VMware Telco Cloud Automation-Control Plane VMware vRealize Orchestrator VMware vRealize Log Insight

Deploy the following: DNS serverProvide the details in the TCPConfig.json file (see Creating the configuration files) NTP serverProvide the details in the TCPConfig.json file (see Creating the configuration files)

Stack deployment workflow

The following are the high-level steps for using VMware TCP with Bare Metal Orchestrator:

1. Add the servers on which the stack is to be deployed to Bare Metal Orchestrator see Create a server or multiple servers and update configurations. Use the sample esxi-install.yaml file located at ~/samples/stacks/tcp and update it with the required details (IP address, username, password, VLAN, operating system install volume, and network information).

2. Use Bare Metal Orchestrator CLI to prepare your hardware with the necessary BMC and BIOS configurations. 3. Edit the sample configuration files provided and upload them to the web server see Creating the configuration files. 4. Create and apply a stack profile YAML file using Bare Metal Orchestrator CLI. 5. Monitor the deployment progress in Bare Metal Orchestrator CLI. 6. Deploy Cell Sites and Regional Sites in the VMware TCP stack domain see Grow a stack (new domain) and Grow a stack

(existing domain).

NOTE: Avoid reboot or delete operations on the server that you are using for stack deployment. If a server is part of a

stack, you cannot perform the following:

Operating system install or operating system upgrade

BIOS operations

Decommissioning

IPv4 settings

RAID operations

Power operations

Create configuration files

Prerequisites

You must be logged into Bare Metal Orchestrator as a Dell user.

About this task

Follow these steps to prepare the stack, host, and installer VM configuration files required for stack deployment:

VMware TCP Stack deployment 95

Steps

1. Establish a CLI session on the Bare Metal Orchestrator VM. For high availability configurations, establish a CLI session using the virtual IP (VIP) of the Load Balancers for the Bare Metal Orchestrator cluster.

2. Download the tca.ova file.

3. Navigate to ~/samples/stacks/tcp and download these three sample configuration templates to your local machine:

TCPConfig.json InstallerConfig.json AddHosts.json

4. Edit the TCPConfig.json file to add the necessary configuration information. Update the images with IP address, port and folder details.

The following is an example TCPConfig.json file:

"images": { "cloudbuilder": "http://100.67.53.238:81/data/stack/VMware-Cloud- Builder-4.2.0.0-17559673_OVF10.ova", "vro": "http://100.67.53.238:81/data/stack/011N_VA-8.4.2.17400_OVF10.ova", "tca": "http://100.67.53.238:81/data/stack/VMware-Cloud- Automation-1.9.1-18002366.ova", "haproxy": [], "kube": [ "http://100.67.53.238:81/data/stack/photon-3-kube-v1.20.4.ova ], "vsphere_plugin": "http://100.67.53.238:81/data/stack/vco-plugin-7.4.0.13701555.zip", "vrli": "http://100.67.53.238:81/data/stack/VMware-vRealize-Log- Insight-8.3.0.0-17494646_OVF10.ova"

where 100.67.53.238 is the IP address of the Bare Metal Orchestrator virtual machine or IP address of the server hosting the Load Balancer, and stack is the folder created while uploading the files to web server.

5. Edit InstallerConfig.json and AddHosts.json files to add the necessary configuration information, and then upload all the three json files to the web server. Provide the tca.ova file name in the InstallerConfig.json file.

6. Using the CLI, run the following command to upload the OVA file to the folder called stack in the web server:

bmo upload fs -f f -m where is the name of the OVA and is stack.

7. Using the CLI, run the following command to upload the edited json files to the folder called stack in the web server:

bmo upload fs -f -m where is the name of the json file and is stack.

8. Optional: Run the following command to list the contents of the stack folder:

bmo get fs -m where is stack.

Deploying a stack

Prerequisites

Before creating a stack profile, you must:

Ensure the three required configuration files (TCPConfig.json, InstallerConfig.json, and AddHosts.json) are created and uploaded to the VM, see Create configuration files.

Onboard all servers and create a hardware profile for ESXi.

To use a hardware profile, you must have DHCP running and all the servers must have the same type of firmware version, model, and BIOS. You can also use a server profile to onboard servers that have ESXi installed on them.

96 VMware TCP Stack deployment

NOTE: See the sample files for stack deployment that are bundled with the Bare Metal Orchestrator OVA file. They are

located here: ~/samples/stacks/tcp.

About this task

To deploy a stack:

Steps

1. Establish a CLI session on the Bare Metal Orchestrator VM. For high availability configurations, establish a CLI session using the virtual IP (VIP) of the Load Balancers for the Bare Metal Orchestrator cluster.

2. Create a new stack profile .yaml file by copying the sample file (see Stack deployment YAML example).

cp .yaml .yaml 3. Edit the .yaml file in Vim or a similar editor.

For example: vim dell_stack.yaml

4. Customize the .yaml file with the required configurations. Add the IP addresses of the ESXi servers and other required details (username, password, DNS list, VLAN, and so on).

NOTE: The name field in "serverForDeployment[i].name" must match the server names in Bare Metal

Orchestrator. The names given for the fields "spec.stackConfig", "spec.stackHostAdditionConfig" and

"spec.stackInstallerConfig.configFile" must match the names of the configuration files uploaded in web

server.

5. Save the file and quit the editor.

6. Create the stack deployment from the stack yaml:

bmo create stack -f .yaml For example:

bmo create stack -f dell_stack.yaml

7. Verify that the stack has been created and the DeployStack Operation status is busy with this command:

bmo get stack 8. The stack deployment process can take several hours to complete depending on the deployment size. Check the progress

percentage for each domain with this command:

bmo describe stack tcp-stack-1

Results

Once the deployment is completed, the stack state shows as "Ready".

Reinitializing a stack

About this task

If failures occur during the stack deployment process, you can reinitialize the stack. This sends a resync request to the stack installer.

NOTE: If errors during the installer deployment process leave the hosts in an unrecoverable state, you need to clean up the

installer host and then delete and redeploy the stack.

To reinitialize a stack:

Steps

1. Edit the stack resource to add the field "spec.reInitialize". Set the value of the field to true.

bmo edit stack tcp-stack-1 2. Alternatively, edit the stack YAML file and apply the changes throughout the stack:

VMware TCP Stack deployment 97

bmo edit stack tcp-stack-1 -f dell_stack.yaml

Grow a stack (new domain) This task explains how to grow a stack with a new domain and new hosts.

About this task

To grow a stack (new domain):

Steps

1. Establish a CLI session on the Bare Metal Orchestrator VM. For high availability configurations, establish a CLI session using the virtual IP (VIP) of the Load Balancers for the Bare Metal Orchestrator cluster.

2. Add the new servers in Bare Metal Orchestrator using the sample esxi-install.yaml located at ~/samples/ stacks/tcp. Update it with the required details (IP address, username, password, VLAN, OS install volume, and network information).

3. Run the following command:

bmo create server -f server1.yaml 4. Wait for the servers to reach "Ready" state on the ESXi installation process.

5. Update the TCPConfig.json config file used for the original stack deployment by adding the new domain configuration to it. Upload the updated file to the web server.

6. Update the AddHosts.json config file used for the original stack deployment by adding the new hosts to it. Upload the updated file to the web server.

7. Update the stack resource to grow the stack. Do one of the following: Open the stack YAML file used to create the stack originally and add the new host details under

"serverForDeployment[]". Run this command to update the stack: bmo edit stack -f dell_stack.yaml Run the following command and add the new host under "serverForDeployment[]": bmo edit stack tcp-

stack-1

8. Monitor the progress of the grow stack operation in each domain. Run the following command:

bmo describe stack tcp-stack-1 Once the grow operation on the stack is completed, the stack state shows as "Ready".

Grow a stack (existing domain) This task explains how to grow an existing domain with new hosts.

About this task

To grow a stack (existing domain):

Steps

1. Establish a CLI session on the Bare Metal Orchestrator VM. For high availability configurations, establish a CLI session using the virtual IP (VIP) of the Load Balancers for the Bare Metal Orchestrator cluster.

2. Add the new servers in Bare Metal Orchestrator using the sample esxi-install.yaml located at ~/samples/ stacks/tcp. Update it with the required details (IP address, username, password, VLAN, OS install volume, and network information).

3. Run the following command:

bmo create server -f server1.yaml 4. Wait for the servers to reach "Ready" state on the ESXi installation process.

5. Update the AddHosts.json config file used for the original stack deployment by adding the new hosts to it. Upload the updated file to the web server.

6. Update the stack resource to grow the stack. Do one of the following: Open the stack YAML file used to create the stack originally and add the new host details under

"serverForDeployment[]". Run this command to update the stack: bmo edit stack -f dell_stack.yaml

98 VMware TCP Stack deployment

Run the following command and add the new host under "serverForDeployment[]": bmo edit stack tcp- stack-1

7. Monitor the progress of the grow stack operation in each domain. Run the following command:

bmo describe stack tcp-stack-1 Once the grow operation on the stack is completed, the stack state shows as "Ready".

Get stack

About this task

To view brief information about one or more stacks:

Steps

1. Establish a CLI session on the Bare Metal Orchestrator VM. For high availability configurations, establish a CLI session using the virtual IP (VIP) of the Load Balancers for the Bare Metal Orchestrator cluster.

2. To view details of all stacks, run: bmo get stack(s).

3. To view details of a named stack, run: bmo get stack

Describe stack

About this task

To view detailed information about a specific stack:

Steps

1. Establish a CLI session on the Bare Metal Orchestrator VM. For high availability configurations, establish a CLI session using the virtual IP (VIP) of the Load Balancers for the Bare Metal Orchestrator cluster.

2. Run: bmo describe stack .

Edit a stack configuration

About this task

To edit a stack configuration:

Steps

1. Establish a CLI session on the Bare Metal Orchestrator VM. For high availability configurations, establish a CLI session using the virtual IP (VIP) of the Load Balancers for the Bare Metal Orchestrator cluster.

2. Edit the .yaml file in Vim or a similar editor.

For example:

vim dell_stack.yaml

3. Update the value for the attributes based on the configurations you want to perform.

4. Save the file and quit the editor.

5. Run: bmo edit stack -f .yaml

Delete a stack instance

About this task

To delete a stack instance:

VMware TCP Stack deployment 99

Steps

1. Establish a CLI session on the Bare Metal Orchestrator VM. For high availability configurations, establish a CLI session using the virtual IP (VIP) of the Load Balancers for the Bare Metal Orchestrator cluster.

2. To delete a stack, run:

bmo delete stack For example:

bmo delete stack tcp-stack-1

3. Delete all the servers that were used as part of this stack deployment. For example:

bmo delete server server-for-stack-1

Note: After deleting a stack instance, you must clean up the servers that were part of the stack and/or do a fresh installation of the operating system before using the servers for other tasks.

100 VMware TCP Stack deployment

VMware TKG deployment This chapter contains the following topics:

Topics:

Introduction TKG deployment workflow Create the configuration files for TKG deployment Create the templates for TKG deployment Deploy TKG clusters Deploy TCP stack and TKG clusters Delete TKG templates Delete TKG clusters Reinitialize a stack to redeploy TKG

Introduction

VMware Tanzu Kubernetes Grid (TKG) provides organizations with a consistent, upstream-compatible, regional Kubernetes substrate that is ready for end-user workloads and ecosystem integrations. With TKG, you can deploy Kubernetes clusters across Software-defined Datacenters (SDDC) and public cloud environments, such as vSphere.

Bare Metal Orchestrator supports the deployment and life cycle management of complete TKG instance, including the management clusters, the shared and in-cluster services, and the Tanzu Kubernetes clusters.

Management Cluster

A management cluster is the first element that you deploy when you create a TKG instance. The management cluster is a Kubernetes cluster that performs the role of the primary management and operational center for the TKG instance. This is where the Cluster API runs to create the Tanzu Kubernetes clusters, and configure the shared and in-cluster services.

Shared and In-Cluster Services

Shared and in-cluster services are the services that run in the TKG instance, to provide authentication and authorization of Tanzu Kubernetes clusters, logging, and ingress control.

Tanzu Kubernetes Cluster

A Tanzu Kubernetes Cluster, also referred to as a workload cluster, is the cluster that handles application workloads.

The following table describes the operations you can perform using Bare Metal Orchestrator:

Operation Description

Edit and upload the TKG configuration files to the web server

Create the configuration files for TKG deployment

Create TKG templates Create the templates for TKG deployment

Deploy TKG clusters Deploy TKG clusters

Deploy TCP stack and TKG clusters Deploy TCP stack and TKG clusters

13

VMware TKG deployment 101

Operation Description

View TKG templates and cluster deployments

Describe stack

Delete TKG clusters Delete TKG clusters

Delete TKG templates Delete TKG templates

Reinitialize stack to redeploy TKG Reinitialize a stack to redeploy TKG

TKG deployment workflow

About this task

Bare Metal Orchestrator supports the following deployment models to meet various business needs: Deploying TKG clusters on top of an existing TCP stack infrastructure Deploying TCP stack and TKG clusters together The following are the high-level steps for deploying TKG clusters:

Steps

1. To deploy the TKG clusters on an existing TCP stack:

a. Edit and upload the sample TKG configuration files to the web server. See Create the configuration files for TKG deployment.

b. Edit the sample stack configuration to create TKG templates. See Create the templates for TKG deployment. c. Edit the sample stack configuration to deploy the TKG clusters. See Deploy TKG clusters.

2. To deploy TCP stack and TGK clusters together:

a. Edit and upload the sample TCP configuration files to the web server. See Create configuration files. b. Edit and upload the sample TKG configuration files to the web server. See Create the configuration files for TKG

deployment. c. Edit the sample stack configuration to deploy the TCP stack and TKG clusters. See Deploy TCP stack and TKG clusters.

3. Monitor the deployment progress using the Bare Metal Orchestrator CLI. Use the bmo describe stack command and the bmo get stack commands to monitor progress.

Create the configuration files for TKG deployment

Prerequisites

You must be logged into Bare Metal Orchestrator as a Dell user. For high availability Bare Metal Orchestrator configurations, log in to the Load Balancer VM.

About this task

Bare Metal Orchestrator uses customized configuration files (JSON templates) as building blocks for the deployment of TKG clusters. These templates are crucial for proper functioning of the stack. You must import the templates into the web server.

Follow these steps to prepare the configuration files needed for TKG deployment:

Steps

1. Establish a CLI session on the Bare Metal Orchestrator VM. For high availability configurations, establish a CLI session using the virtual IP (VIP) of the Load Balancers for the Bare Metal Orchestrator cluster.

2. Navigate to ~/samples/stacks/tcp.

3. Based on the clusters you want to deploy, download one or more sample configuration templates to your local machine:

Management templatetkg-management-template.json Shared services templatetkg-sharedservice-template.json Workload templatetkg-workload-template.json

102 VMware TKG deployment

NOTE:

To deploy a management clustercreate the management template.

To deploy a shared service clustercreate a management cluster and shared service template.

To deploy a workload clustercreate a management cluster and a workload template.

4. Create a new template by copying the sample configuration template.

cp .yaml .yaml For example:

cp tkg-workload-template.json workload-template.json

5. Edit the new template .json file(s) to add the necessary configuration information (name, clusterType, description).

For more information about the configurable attributes, see Stack field definitions for TKG template.

6. Using the CLI, run the following command to upload the edited .json files to the folder called stack in the web server:

bmo upload fs -f -m where is the name of the json template file and is stack.

Create the templates for TKG deployment

Prerequisites

Upload the TKG template(s) to the web server. For more information, see Create the configuration files for TKG deployment.

About this task

Creating the right template for cluster deployment is essential for the proper functioning of the stack. To deploy a management clustercreate a management template. To deploy a shared service clustercreate a management and shared service template. To deploy a workload clustercreate a management and a workload template. Follow these steps to create management, shared services, or workload templates.

Steps

1. Establish a CLI session on the Bare Metal Orchestrator VM. For high availability configurations, establish a CLI session using the virtual IP (VIP) of the Load Balancers for the Bare Metal Orchestrator cluster.

2. Change the directory to ~/samples/stacks/tcp.

3. Create a new stack profile .yaml file by copying the sample file.

cp .yaml .yaml For example:

cp tcp_stack.yaml dell_stack.yaml

4. Edit the .yaml file in Vim or a similar editor.

For example:

vim dell_stack.yaml

5. Customize the createTKGTemplateList field with required configurations. For attribute definitions, see Stack field definitions for TKG template.

For an example snapshot of the .yaml file updated with TKG template configurations, see Sample TKG deployment YAML file.

NOTE: You can create a single template or multiple templates at once.

6. Save the file and quit the editor.

7. Run bmo edit stack -f .yaml.

VMware TKG deployment 103

8. Verify if the template has been successfully created using:

bmo describe stack The TKG templates are displayed in the status section of the output. For more information, see Stack status fields.

Deploy TKG clusters You can deploy the TKG clusters by adding new cluster settings or updating the existing settings.

Prerequisites

Create the TKG template(s) and the clusters. To deploy a management clustercreate a management template. To deploy a shared service clustercreate a management cluster and a shared service template. To deploy a workload clustercreate a management cluster and a workload template. For more information, see Create the templates for TKG deployment.

About this task

Follow these steps to deploy TKG clusters:

Steps

1. Establish a CLI session on the Bare Metal Orchestrator VM. For high availability configurations, establish a CLI session using the virtual IP (VIP) of the Load Balancers for the Bare Metal Orchestrator cluster.

2. Change the directory to ~/samples/stacks/tcp.

3. Create a new stack profile .yaml file by copying the sample file.

cp .yaml .yaml For example:

cp tcp_stack.yaml dell_stack.yaml

4. Edit the .yaml file in Vim or a similar editor.

For example:

vim dell_stack.yaml

5. Customize the createTKGClusterList field with required configurations. For attribute definitions, see Stack field definitions for TKG cluster deployment.

For an example snapshot of the .yaml file updated with TKG cluster configurations, see Sample VMWare TCP stack deployment YAML file.

NOTE: You can create a single cluster or multiple clusters at once.

If you are updating the .yaml file to deploy multiple clusters, then the sequence of

deployment in Bare Metal Orchestrator is:

a. All management clusters

b. All shared service clusters

c. All workload clusters

6. Save the file and quit the editor.

7. Run bmo edit stack -f .yaml.

8. Verify the deployment of clusters using:

bmo describe stack The TKG cluster details are displayed in the status section of the output. For more information, see Stack status fields.

104 VMware TKG deployment

Deploy TCP stack and TKG clusters

Prerequisites

The following prerequisites have to be met before you deploy the TCP stack and TKG clusters with Bare Metal Orchestrator:

Onboard all servers with ESXi operating system, deploy the DNS, NTP, and web server. See Prerequisites. Edit the sample TCP configuration templates and upload the edited templates to the web server. See Create configuration

files. Edit the sample TKG configuration templates and upload the edited templates to the web server. See Create the

configuration files for TKG deployment. Create the TKG template(s) and the clusters.

To deploy a management clustercreate a management template. To deploy a shared service clustercreate a management cluster and a shared service template. To deploy a workload clustercreate a management cluster and a workload template. For more information, see Create the templates for TKG deployment.

About this task

While deploying the TCP stack and TKG clusters together, the sequence of deployment in Bare Metal Orchestrator is as follows: 1. TCP stack 2. All TKG templates 3. All management clusters 4. All shared service clusters 5. All workload clusters

Steps

1. Establish a CLI session on the Bare Metal Orchestrator VM. For high availability configurations, establish a CLI session using the virtual IP (VIP) of the Load Balancers for the Bare Metal Orchestrator cluster.

2. Change the directory to ~/samples/stacks/tcp.

3. Create a new stack profile .yaml file by copying the sample file.

cp .yaml .yaml For example:

cp tcp_stack.yaml dell_stack.yaml

4. Edit the .yaml file in Vim or a similar editor.

For example:

vim dell_stack.yaml

5. Update the configurations for TCP and TKG deployments.

For an example snapshot of the .yaml file updated with attributes for TCP and TKG deployments, see Sample VMWare TCP stack deployment YAML file.

For TCP attribute definitions, see Stack field definitions for VMWare TCP. For TKG template attribute definitions, see Stack field definitions for TKG template.

NOTE: Update the configurations for TKG template deployment in createTKGTemplateList field.

For TKG cluster attribute definitions, see Stack field definitions for TKG cluster deployment.

NOTE: Update the configurations for TKG cluster deployment in createTKGClusterList field.

6. Save the file and quit the editor.

7. Run bmo create stack -f .yaml.

8. Verify the deployment status of the TCP stack using:

bmo get stack When the Provisioning Status transitions from Busy to Ready state, the stack deployment is successful.

9. Verify the deployment of clusters using:

VMware TKG deployment 105

bmo describe stack The TKG cluster details are displayed in the status section of the output. For more information, see Stack status fields.

Delete TKG templates

About this task

To delete one or more TKG templates:

Steps

1. Establish a CLI session on the Bare Metal Orchestrator VM. For high availability configurations, establish a CLI session using the virtual IP (VIP) of the Load Balancers for the Bare Metal Orchestrator cluster.

2. Change the directory to ~/samples/stacks/tcp.

3. Edit the .yaml file in Vim or a similar editor.

For example:

vim dell_stack.yaml

4. In the deleteTKGTemplateList field, provide the names of the templates you want to delete.

For an example snapshot of the .yaml file updated with the list of templates to be deleted, see Sample TKG deployment YAML file.

5. Save the file and quit the editor.

6. Run bmo edit stack -f .yaml.

7. To verify the successful deletion, run:

bmo describe stack The deleted templates are removed from the status section of the output.

Delete TKG clusters

Prerequisites

Before deleting a management cluster, dependent shared service, and workload clusters must be deleted.

About this task

To delete one or more TKG clusters:

Steps

1. Establish a CLI session on the Bare Metal Orchestrator VM. For high availability configurations, establish a CLI session using the virtual IP (VIP) of the Load Balancers for the Bare Metal Orchestrator cluster.

2. Change the directory to ~/samples/stacks/tcp.

3. Edit the .yaml file in Vim or a similar editor.

For example:

vim dell_stack.yaml

4. In the deleteTKGClusterList field, provide the name of the cluster you want to delete.

NOTE: If you want to delete multiple clusters, provide the names of all the clusters you want to delete.

For an example snapshot of the .yaml file updated with the list of clusters to be deleted, see Sample TKG deployment YAML file.

If you are updating the .yaml file to delete multiple clusters, then the sequence of deletion is:

a. All workload clusters

106 VMware TKG deployment

b. All shared service clusters c. All management clusters

5. Save the file and quit the editor.

6. Run bmo edit stack -f .yaml.

7. To verify the successful deletion, run:

bmo describe stack The deleted clusters are removed from the status section of the output.

Reinitialize a stack to redeploy TKG If failures occur during TKG cluster deployment or TKG template creation process, you can reinitialize the stack. This sends a re-sync request to the stack installer. Reinitialize helps reinstate a failed deployment after the issue that caused the failure is resolved.

Steps

1. Establish a CLI session on the Bare Metal Orchestrator VM. For high availability configurations, establish a CLI session using the virtual IP (VIP) of the Load Balancers for the Bare Metal Orchestrator cluster.

2. Navigate to ~/samples/stacks/tcp.

3. Edit the .yaml file in Vim or a similar editor.

For example:

vim dell_stack.yaml

4. Update the reInitialize attribute and enter the value as true.

For an example snapshot of the .yaml file updated with TKG cluster configurations, see Sample VMWare TCP stack deployment YAML file.

5. Alternatively, customize the deleteTKGClusterList or deleteTKGTemplateList field with required configurations. For attribute definitions, see Stack field definitions for TKG cluster deployment.

6. Save the file and quit the editor.

7. To reinitialize, run the following command:

bmo edit stack -f .yaml

VMware TKG deployment 107

Wind River Cloud Platform stack deployment Use Bare Metal Orchestrator to deploy the Wind River Cloud Platform Central Cloud.

Topics:

Wind River Cloud Platform introduction Wind River Cloud Platform deployment workflow Create servers for Controller 1-n and Worker 0-n components Create the stack configuration files Deploy the Wind River Cloud Platform stack Delete the Wind River Cloud Platform stack

Wind River Cloud Platform introduction

Wind River Cloud Platform provides an integrated and ready-to-deploy cloud native platform that is deployed on dedicated servers across the network. Bare Metal Orchestrator supports an all-in-one duplex deployment of Wind River Cloud Platform version 21.05.

Multiple regions (also called sites) make up the cloud platform. Bare Metal Orchestrator only supports deployment of a Central Cloud.

Central Cloud (Central Site): Provides orchestration and synchronization services for the complete stack. This is a mandatory site for a Wind River Cloud Platform deployment. In the Central Cloud, there are three types of components. The Controller-0 and Controller-1 components are mandatory for an all-in-one duplex deployment. Controller-0 Controller 1-n Worker 0-n

Use Bare Metal Orchestrator to deploy and manage your Wind River Cloud Platform cluster. The Central Cloud is deployed on Bare Metal Orchestrator's Global Controller site.

Table 30. Servers required for Wind River Cloud Platform stack deployment

Domain type Minimum number of servers required

Central Cloud 3

A server for Controller-0, Controller-1, and Worker-0.

The maximum number of servers supported in a Wind River Cloud Platform deployment is 50.

Supported Dell Technologies PowerEdge server models include R640, R750, and XR11. For information about supported firmware and BIOS versions, see Validated hardware components.

The same server model must be used for Controller-0, Controller-1, and Workers.

CAUTION: Dedicate servers for Controller and Worker component use. Do not run other operations on these

servers. Completely remove stack deployment components from servers before repurposing.

Prerequisites

Before you deploy a Wind River Cloud Platform cluster, you need:

A VLAN for the Central Cloud Your NTP server details for servers hosting Controller-0 Your DNS server details for servers hosting Controller-0 A docker registry on the Controller-0 server to host all the Wind River stack docker images

14

108 Wind River Cloud Platform stack deployment

A copy of the docker registry certificate The Wind River Cloud Platform version 21.05 ISO image. Contact your Wind River representative for more information. Servers to host Controller-1 and the optional Worker 0-n components

Wind River Cloud Platform deployment workflow

About this task

Deploy the Wind River Cloud Platform operating system on each server in the cloud cluster that hosts a Controller-0 component.

The following are the high-level steps for deploying a Wind River Cloud Platform cluster:

1. Deploy the Wind River Cloud Platform operating system on each server in the cloud cluster that will host a Controller-0 component. A sample mw_dell_server_wr.yaml file is located in the Bare Metal Orchestrator~/samples/stacks/ windriver directory. You can update it with the required details (IP address, username, password, VLAN, operating system install volume, and so on.) for Controller-0. See Operating system deployment workflow - servers.

2. Create and configure servers for Controller-1 and any optional Worker 0-n components, see Create servers for Controller 1-n and Worker 0-n components.

3. Edit the sample stack deployment configuration files for Wind River Cloud Platform and upload the edited files to the folder called stack in the web server. See Create the stack configuration files.

deployment_config.yaml installer_config.yaml

4. Create the stack deployer profile wr_stack.yaml and deploy the cloud cluster. See Deploy the Wind River Cloud Platform stack.

5. Monitor the deployment progress using the Bare Metal Orchestrator CLI. Use the bmo describe command and the bmo get stack commands to monitor progress.

NOTE: The stack deployment process can take up to three hours to complete depending on the deployment size.

Before you can deploy the stack, the following must be uploaded to specific folders in the web server: The Wind River Cloud Platform ISO wind-river-cloud-platform-host-installer-21.05-b58.iso is uploaded

to the folder called isos.

The following artifacts that are extracted from the Windriver.zip file are uploaded to the folder called stack:

wind-river-cloud-platform-deployment-manager-2.0.6.tgz wind-river-cloud-platform-deployment-manager.yaml

The docker registry certificate for the Wind River Cloud Platform deployment is uploaded to the folder called stack. NOTE: Upload the Wind River docker images to the https image registry on the Controller-0 server to host all the Wind

River stack docker images.

The stack configuration files deployment_config.yaml and installer_config.yaml are created and added to the stack folder. For details, see Create the stack configuration files.

Create servers for Controller 1-n and Worker 0-n components

Prerequisites

Provide a server or VM for each Controller and Worker component you add to the Wind River Cloud Platform cluster. You need the BMC IP address for the Controller and Worker servers and the administrative credentials. Meet the hardware and software requirements:

Supported Dell Technologies PowerEdge server models include R640, R750, and XR11. For information about supported firmware and BIOS versions, see Validated hardware components.

The same server models must be used for Controller-0, Controller-1, and Workers.

CAUTION: Dedicate servers for Controller and Worker component use. Do not run other operations on these

servers. Completely remove stack deployment components from servers before repurposing.

Wind River Cloud Platform stack deployment 109

About this task

A Controller-1 and a Worker-0 component are required for each Controller-0 component in the cloud cluster. Additional Controller and Worker components are optional.

You create servers using the Bare Metal Orchestrator CLI and YAML files. Controller-1 and Worker servers are onboarded using the server IP address in the bmcEndpoint setting and require the BIOS settings to enable PXE boot. Sample server YAML files are provided in the ~/samples/servers for Controller and Worker components.

To create and configure servers for the Controller 1-n and Worker 0-n components of a Wind River Cloud Platform cluster:

Steps

1. Establish a CLI session on the Bare Metal Orchestrator VM. For high availability configurations, establish a CLI session using the virtual IP (VIP) of the Load Balancers for the Bare Metal Orchestrator cluster.

2. Change the directory to ~/samples/servers.

3. Create a new server .yaml file by copying the sample file.

cp .yaml .yaml NOTE: The sample server YAML file for a Controller-1 component is called wr-controller-1.yaml. The sample

server YAML file for a Worker is called wr-worker.yaml.

4. Edit the .yaml file in Vim or a similar editor.

For example:

vim controller-1-server.yaml

5. Customize the .yaml file:

Update the metadata. For more information, see Metadata. Update the server fields that are applicable for Wind River Cloud Platform Controller 1-n and Worker 0-n, see Server

connectivity field definitions.

The following is a sample YAML file for a Controller 1-n server:

apiVersion: mw.dell.com/v1 kind: Server metadata: name: controller-1 labels: site: gc model: dell spec: # Add fields here bmcEndPoint: "https:// " userName: "root" password: powerstate: "On" bios: attributes: pxeDev1EnDis: Enabled pxeDev1Interface: "NIC.Slot.2-1-1"

The following is a sample YAML file for a Worker server:

apiVersion: mw.dell.com/v1 kind: Server metadata: name: worker-0 labels: site: gc model: dell spec: # Add fields here bmcEndPoint: "https:// " userName: "root" password: powerstate: "On" bios:

110 Wind River Cloud Platform stack deployment

attributes: pxeDev1EnDis: Enabled pxeDev1Interface: "NIC.Slot.2-1-1"

6. Save the file and quit the editor.

7. Create the server instance.

bmo create server -f .yaml For example:

bmo create server -f controller-1-server.yaml

Create the stack configuration files

Prerequisites

Before you create the stack configuration files for a Wind River Cloud Platform deployment: You must be logged into Bare Metal Orchestrator as a Dell user. For high availability Bare Metal Orchestrator configurations,

log in to the Load Balancer VM. Collect the IP addresses and server information for Controller-0, Controller-1, and any optional Worker 0-n components in

the Central Cloud.

About this task

Follow these steps to prepare the stack configuration files that are needed for the Wind River Cloud Platform stack deployment:

Steps

1. Establish a CLI session on the Bare Metal Orchestrator VM. For high availability configurations, establish a CLI session using the virtual IP (VIP) of the Load Balancers for the Bare Metal Orchestrator cluster.

2. Navigate to ~/samples/stacks/windriver and download these sample stack deployment configuration files to your local machine.

deployment_config.yaml: defines the host profile information for Controller-0, Controller-1, and worker 0-n, network information for each of the sites in the cloud cluster, NTP and DNS server information, and boot file system information.

installer_config.yaml: defines the user name, password, and network information for each Controller-0 component for a particular site in the cloud cluster, cluster host details, PXE boot details, and OAM details.

3. Edit the files to add the necessary configuration information (IP addresses, username, password, VLANs, network information, and so on).

4. Using the CLI, run the following command to upload the edited files to the folder called stack in the web server:

bmo upload fs -f -m where is the name of the stack configuration file and is stack.

5. Optional: Run the following command to list the contents of the stack folder:

bmo get fs -m where is stack.

Deploy the Wind River Cloud Platform stack

Prerequisites

Before you deploy the stack:

Wind River Cloud Platform stack deployment 111

Deploy the Wind River Cloud Platform operating system on each server in the cloud cluster that hosts a Controller-0 component, see Operating system deployment workflow - servers.

Create and configure servers for Controller-1 and any optional Worker 0-n components, see Create servers for Controller 1-n and Worker 0-n components.

Create the stack configuration files for the Wind River Cloud Platform deployment and upload them to the folder called stack in the web server. See Create the stack configuration files.

NOTE: See the sample files for stack deployment that are bundled with the Bare Metal Orchestrator OVA file. They are

located here: /home/dell/samples/stacks/windriver.

Ensure the required certificates and files are uploaded to the web server in the appropriate folders. The Wind River Cloud Platform ISO wind-river-cloud-platform-host-installer-21.05-b58.iso is

uploaded to the folder called isos.

The following artifacts extracted from the Windriver.zip file are uploaded to the folder called stack:

wind-river-cloud-platform-deployment-manager-2.0.6.tgz wind-river-cloud-platform-deployment-manager.yaml

The docker registry certificate for the Wind River Cloud Platform deployment is uploaded to the folder called stack.

The stack configuration files deployment_config.yaml and installer_config.yaml are created and added to the stack folder. For details, see Create the stack configuration files.

About this task

A stack deployment profile is used to deploy the stack. The stack deployer profile defines the stack type, version, credentials, and network information for Controller-0 on the Central Cloud, and also lists the servers for deployment. The configFile attribute points to the installer_config.yaml file, where server details are provided.

Steps

1. Establish a CLI session on the Bare Metal Orchestrator VM. For high availability configurations, establish a CLI session using the virtual IP (VIP) of the Load Balancers for the Bare Metal Orchestrator cluster.

2. Create a new-stack.yaml profile file by copying wr-stack.yaml in ~/samples/stacks/windriver. See Sample Wind River Cloud Platform stack deployment YAML file).

cp .yaml .yaml 3. Edit the .yaml file in Vim or a similar editor.

For example:

vi wrcp_stack.yaml

4. Customize the new-stack-id with the required configurations. Add server details, server name, server domain, and type for all servers in the Central Cloud.

NOTE: The name field in "serverForDeployment[i].name" must match the server names

in Bare Metal Orchestrator. The names given for the fields "spec.stackConfig" and

"spec.stackInstallerConfig.configFile" must match the names of the configuration files uploaded in the

web server.

5. Save the file and quit the editor.

6. Create the stack deployment from the stack yaml:

bmo create stack -f .yaml For example:

bmo create stack -f wrpc_stack.yaml

7. Use the following command to verify that the stack has been created and the status is "busy" while the DeployStack Operation operation is in progress:

bmo get stack 8. The stack deployment process can take several hours to complete depending on the deployment size. Check the progress

percentage for each domain with this command:

bmo describe stack wrpc-stack

112 Wind River Cloud Platform stack deployment

Results

Stack deployment can take up to three hours, depending on the number of severs and the size of the cloud cluster. Once deployment is completed, the stack state shows as Ready.

Delete the Wind River Cloud Platform stack

About this task

Deleting the stack removes all configuration related to the Wind River Cloud Platform deployment from Bare Metal Orchestrator. Configuration that is related to the Wind River Cloud Platform deployment is not removed from servers that are part of the stack deployment. Before you can use the servers for other tasks, you must clean up the servers and do a fresh installation of the operating system.

To delete a Wind River Cloud Platform cluster:

Steps

1. Establish a CLI session on the Bare Metal Orchestrator VM. For high availability configurations, establish a CLI session using the virtual IP (VIP) of the Load Balancers for the Bare Metal Orchestrator cluster.

2. To delete a stack, run:

bmo delete stack For example:

bmo delete stack wrcp-stack-1

3. Delete all the servers that were used as part of this stack deployment. For example:

bmo delete server server-for-wrcp-stack-1

Note: Deleting the cluster does not remove all configuration related to the Wind River Cloud Platform deployment from the servers that are a part of the cluster. You must clean up the servers and do a fresh installation of the operating system before you can use the servers for other tasks.

Wind River Cloud Platform stack deployment 113

Backing up and restoring clusters Back up and restore the Bare Metal Orchestrator cluster.

Topics:

Backup and restore overview Backup the cluster Restore a cluster from a backup file Schedule cluster backups Stop scheduled backups Change the backup storage location Create backup storage location secret

Backup and restore overview When you create a backup of the Bare Metal Orchestrator cluster, a snapshot of the cluster resources is taken that can be used to recover from data loss.

You can use a backup to fully restore the Bare Metal Orchestrator cluster. The backup contains all configuration data, state, and metadata for the cluster.

Backups are saved to the MinIO S3 store on the Global Controller in a bucket called bmo-backup by default. We recommend that you change the backup file location to an external backup location.

You can use any Velero supported S3 storage provider as an external backup location. For more information, consult the official Velero website.

NOTE: Bare Metal Orchestrator does not manage or maintain external backup stores. For information about how to deploy

an external storage solution, consult the documentation for the external storage solution you are using.

You can schedule backups to occur at regular intervals or perform a one-time backup at any time. For help with restoring a cluster from a backup, contact your Dell Support representative.

Restore behavior

When a backup is taken of your Bare Metal Orchestrator cluster, a snapshot of the current configuration of nodes and servers is captured. When a restore is performed, any missing server objects that were deleted are re-created and the server's recorded age statistic restarts from the time of the restore.

In a disaster recovery scenario, all servers and the Bare Metal Orchestrator nodes are re-created.

In a partial recovery scenario, the restore operation restores any missing server objects that were deleted. However, if a server's configuration matches what is recorded in the backup, that server is skipped and a restore operation is not performed on that server. If a server was upgraded after the backup snapshot was created, for example if the BIOS was upgraded from 1.0.2 to 1.3.8, the restore operation does not revert that server to it's earlier state.

Limitations

Observe the following:

Save backups to only one backup storage location. Backup files expire one month after creation and you cannot use expired files to restore the cluster. If using an external S3 storage location for the backup files, the server hosting the external backup store must support SSL.

For more information, see Change the backup storage location. When restoring a cluster using a backup file:

15

114 Backing up and restoring clusters

The number of nodes in the new cluster must be equal to or greater than the number of nodes that were in the original cluster.

Objects that already exist in the cluster are not overwritten unless they have been modified. The container network interface (CNI) of the new cluster must be the same as the CNI of the original cluster.

NOTE: Bare Metal Orchestrator reserves IP addresses in subnet ranges 10.42.0.0/16 and 10.43.0.0/16 by default for

the Global Controller cluster communications and must not be used for any other purpose.

The age status indicator for a restored server restarts and shows the time since the server was restored.

NOTE: When scheduled backups are configured, periodically check the free space available in the MinIO S3 backup

location, and manually remove backup files to free up space if required. Remove expired backup files that are more than one

month old.

Backup the cluster

Prerequisites

If you are not using the default MinIO S3 storage location on the Global Controller for the backup files, you must set the location of the external MinIO S3 store. See Change the backup storage location.

The cluster must be operational.

About this task

You can backup the entire cluster at any time. Cluster information captured includes the Global Controller and worker node settings, site configurations, users and role information, and related metadata. Persistent volumes are not included in the backup file. Backup files expire one month from the date of creation.

To backup a cluster:

Steps

1. Establish a CLI session on the Bare Metal Orchestrator VM. For high availability configurations, establish a CLI session using the virtual IP (VIP) of the Load Balancers for the Bare Metal Orchestrator cluster.

2. Run:

bmo create backup save --name For example:

bmo create backup save --name backup1

3. To verify the snapshot was successful, run the following:

bmo get backup This is an example result of bmo get backup

NAMESPACE NAME AGE velero backup1 10s

Restore a cluster from a backup file

About this task

You can select a specific backup file and use that to restore the cluster. Restoring the cluster from a backup restores the Global Controller and worker nodes, site configurations, users and role information, and related metadata. Persistent volumes are not included in the backup file.

NOTE:

Do not perform other cluster operations while the cluster is being restored. For example, do not create new sites, add

worker nodes, or add users during the restore.

Backing up and restoring clusters 115

To restore a cluster from a backup file:

Steps

1. Establish a CLI session on the Bare Metal Orchestrator VM. For high availability configurations, establish a CLI session using the virtual IP (VIP) of the Load Balancers for the Bare Metal Orchestrator cluster.

2. Log in as the installer user with the password Dell1234.

3. Change the directory to mw-ova-ansible.

cd mw-ova-ansible 4. Enter pre-restore.sh to run the pre-restore script.

5. Verify the /tmp/pre-restore-output.log file generated for errors.

6. Run:

bmo create backup restore --backup_name 7. Enter post-restore.sh to run the post-restore script.

8. Verify the /tmp/post-restore-output.log file generated for errors.

9. Enter exit to terminate the SSH session.

Schedule cluster backups

Prerequisites

You must set up a MinIO S3 storage location for the backup. See Change the backup storage location. The cluster must be operational.

About this task

You can schedule regular backups of the entire Bare Metal Orchestrator cluster, including the Global Controller and worker node configurations, sites, and related metadata.

Set the scheduled backup time interval with a cron time string of five characters. Time values are based on UTC.

For example, enter the following time interval to schedule a backup to occur every 15th of the month at 10:00 am:

0.10.15.*.* where each attribute from left to right defines the following:

minute (values 0 to 59) hour (values 0 to 23) day of the month (values 1 to 31) month (values 1 to 12) day of the week (values 0 to 7, where both 0 and 7 represent Sunday)

Entering an * assigns no specific value.

You can also enter the time interval using the @every syntax and specify a combination of seconds (s), minutes (m), and hours (h).

For example: @every 2h30m NOTE: When scheduled backups are configured, periodically check the free space available in the MinIO S3 backup location

and manually remove backup files to free up space. Remove expired backup files that are more than one month old.

To schedule a cluster backup:

Steps

1. Establish a CLI session on the Bare Metal Orchestrator VM. For high availability configurations, establish a CLI session using the virtual IP (VIP) of the Load Balancers for the Bare Metal Orchestrator cluster.

2. Run the following command and enter a and the time interval.

bmo create backup schedule --name --schedule=" "

116 Backing up and restoring clusters

For example:

bmo create backup schedule --name backup1 --schedule="@every 60m"

NOTE: The name assigned to the backup schedule is the same name assigned to the backup files that are created.

3. Verify the snapshot was successful by running the following command:

bmo get backup This is an example result of bmo get backup.

NAMESPACE NAME AGE velero backup1-20211111192154 3h velero backup1-20211111200002 141m velero backup1-20211111210002 81m velero backup1-20211111220002 21m

Stop scheduled backups

About this task

Disable scheduled cluster backups by deleting the schedule. Deleting the scheduled backups only deletes the schedule configuration. The existing backup files remain in the backup file location.

To stop scheduled backups:

Steps

1. Establish a CLI session on the Bare Metal Orchestrator VM. For high availability configurations, establish a CLI session using the virtual IP (VIP) of the Load Balancers for the Bare Metal Orchestrator cluster.

2. Run the following command, where is the name that was assigned when the backup schedule was created.

bmo delete backup schedule --name 3. Enter exit to terminate the SSH session.

Change the backup storage location

Prerequisites

You need the IP address and port number of the backup store location where you want the backup files to be saved. The server hosting the external S3 backup store must support SSL. Creation of a new backup location secret is required, see Create backup storage location secret.

About this task

Backups are saved to the local MinIO S3 store on the Global Controller in a bucket called bmo-backups by default. We recommend deploying a backup storage location at a site that is external of the Bare Metal Orchestrator Global Controller.

You can use any Velero supported S3 provider as an external backup location. For more information, consult the official Velero website.

NOTE: Bare Metal Orchestrator does not manage or maintain external backup stores. For information on how to deploy an

external storage solution, consult the documentation for the external storage solution you are using.

To change the location where the backup files are stored, you must delete the current MinIO S3 backup storage location, and then create the new backup storage location. The creation of a new backup location secret is required.

Backing up and restoring clusters 117

Steps

1. Establish a CLI session on the Bare Metal Orchestrator VM. For high availability configurations, establish a CLI session using the virtual IP (VIP) of the Load Balancers for the Bare Metal Orchestrator cluster.

2. Run the following command to get the current backup location.

bmo get backup-location 3. Run the following command to delete the existing default MinIO S3 store location for the backup files.

bmo delete backup-location --name For example:

bmo delete backup-location --name bmo-backup-location

4. Run the following command and enter a new , as well as the of the external backup store and the used to contain the backup files.

bmo create backup location --name --bucket --address

where can be an IP address or FQDN value and the port.

For example:

bmo create backup location --name bmobackup1 --bucket clusterbackups --address 10.1.100.10:9000

Create backup storage location secret

About this task

Before you can change the backup storage location, you must delete the existing backup storage location secret and create a new one.

To create a backup storage location secret:

Steps

1. Establish a CLI session on the Bare Metal Orchestrator VM. For high availability configurations, establish a CLI session using the virtual IP (VIP) of the Load Balancers for the Bare Metal Orchestrator cluster.

2. Run:

bmo delete secret -n where is the name of the existing MinIO S3 backup storage location secret and the entered should be velero to identify that the object is related to cluster backups.

For example:

bmo delete secret mycredentials -n velero

3. Create a MinIO credentials file and specify these default attributes:

aws_access_key_id = aws_secret_access_key =

The following is an example of a MinIO credentials file called credentials-minio:

[default] aws_access_key_id = myaccesskey aws_secret_access_key = mysecretkey

4. Run the following command to encode the MinIO credentials file using base64 encoding.

base64 -w 0

118 Backing up and restoring clusters

For example:

#base64 -w 0 credentials-minio W2RlZmF1bHRdCmF3c19hY2Nlc3Nfa2V5X2lkID0gbXlhY2Nlc3NrZXkKYXdzX3NlY3JldF9hY2Nlc3Nfa2V5ID 0gbXlzZWNyZXRrZXkK

5. Create a YAML file for the backup location secret. Enter:

.yaml

For example:

secret.yaml

6. Edit the .yaml file in Vim or a similar editor to include the base64 encoded content that was generated earlier. The following is an example of the .yaml file:

apiVersion: v1 data: cloud: W2RlZmF1bHRdCmF3c19hY2Nlc3Nfa2V5X2lkID0gbXlhY2Nlc3NrZXkKYXdzX3NlY3JldF9hY2Nlc3Nfa2V5ID 0gbXlzZWNyZXRrZXkK kind: Secret metadata: name: cloud-credentials namespace: velero type: Opaque

7. Save the file and quit the editor.

8. Create the backup location secret. Run:

bmo create secret -f .yaml -n velero

Backing up and restoring clusters 119

Monitoring Bare Metal Orchestrator Use logs, telemetry, and events to monitor Bare Metal Orchestrator.

Topics:

Logging Adding a search index to OpenSearch dashboard Metrics reports Events

Logging Bare Metal Orchestrator logs are automatically collected and made available in a centralized OpenSearch dashboard that is deployed on the Global Controller.

Log aggregation

Fluentd performs log aggregation and an OpenSearch dashboard displays these logs. When Bare Metal Orchestrator is deployed, an OpenSearch dashboard pod and a Fleuntd logging agent pod are automatically created on the Global Controller.

OpenSearch only exists on the Global Controller, and Fluentd is deployed at all sites to collect logs. When a worker site is created by the Global Controller, a Fluentd pod is deployed on the worker site. Fluentd pushes logs collected at the worker site to OpenSearch.

Fluentd collects the following Bare Metal Orchestrator application logs from all sites:

file_name message log_level service_name site timestamp

You can filter and query these logs in OpenSearch. Use these logs to view errors in a configuration profile, errors from a site, or all errors during a specified time frame.

Access the OpenSearch dashboard

Run the following command to retrieve the internal IP address of the Global Controller:

bmo get node | grep

For example:

bmo get node | grep gc

Where gc is the default site name of the Global Controller.

The OpenSearch dashboard endpoint URL is http:// :31118. Use this endpoint URL to access the OpenSearch dashboard in a web browser.

NOTE: For high availability configurations, use the Load Balancer IP address instead of the Global Controller to access the

OpenSearch dashboard.

16

120 Monitoring Bare Metal Orchestrator

Adding a search index to OpenSearch dashboard You must add a search index before you can view and query Bare Metal Orchestrator logs in OpenSearch.

Prerequisites

Bare Metal Orchestrator is deployed. You have the OpenSearch dashboard endpoint URL. The default URL of the endpoint is http://

:31118. See Access the OpenSearch dashboard to retrieve the endpoint URL.

About this task

For high availability (HA) configurations, use the Load Balancer IP address instead of the Global Controller to access the OpenSearch dashboard.

NOTE: If the Global Controller fails, Bare Metal Orchestrator logs do not display in the OpenSearch dashboard.

To add a search index to the OpenSearch dashboard:

Steps

1. Log in to the OpenSeach dashboard. The default login credentials are admin and admin.

2. In the left navigation panel, click Stack Management.

3. Click Index Patterns, then click Create index pattern.

Monitoring Bare Metal Orchestrator 121

4. Enter mw_logs_site* in the Index pattern name field and click Next step.

5. In the Time field drop-down list, select timestamp and click Create index pattern.

122 Monitoring Bare Metal Orchestrator

6. Above the left navigation panel, click Discover to view all the logs.

Monitoring Bare Metal Orchestrator 123

Metrics reports With Bare Metal Orchestrator, you can collect metrics for one or multiple servers in your network. When enabled, metrics are polled every 15 minutes. A snapshot of only the last metrics that were collected are retained in the metrics report.

You can perform the following operations: Create metrics reports to collect statistics for one or more servers and verify the creation. Create metrics reports to collect server statistics using hardware profiles and to verify the creation. Update metrics report collection. Stop metrics report collection.

Metrics reports can collect one or more of the following statistics:

CPU utilization: System usage as a percentage. Not all platforms support collection of this data. Memory utilization: System memory usage as a percentage. Not all platforms support collection of this data. Power usage: Power consumption for all CPUs, DIMMs, system input, and system output. Temperature: Device temperature sensor metric report.

NOTE: For iDRAC, a data center license is required to use this feature.

The following table describes how you can create and update metrics reports, view collected metrics, stop metrics collection, and verify metrics reports:

Table 31. Working with metrics collection

Operation Description

Create metrics reports for one or multiple servers. Update the metric attributes while creating or editing a server.

Create a server or multiple servers and update configurations

124 Monitoring Bare Metal Orchestrator

Table 31. Working with metrics collection (continued)

Operation Description

Edit server configuration NOTE: For more information about the metric attributes, see Metric attribute definitions.

Create metrics reports using a hardware profile. Update the metric attributes while creating or editing a hardware profile.

Create hardware profiles

Edit hardware profile configuration

Stop metrics report collection for a server or for multiple servers.

Delete the metric attributes while editing a server or hardware profile to stop collecting statistics.

Edit server configuration

Edit hardware profile configuration

View metrics for a server View server inventory

Verify if the metrics report creation or deletion is successful on a server.

View servers and server status

View server inventory

Verify if the metrics report creation or deletion is successful for multiple servers.

View hardware profiles

View hardware profile details

The following example shows the metric attributes that you can add to the spec section of a server YAML file or a hardware profile to enable metrics collection on Bare Metal Orchestrator:

spec: metric: pollFrequenceyMins: 15 metricReports: - name: CPUUtilization - name: MemoryUtilization - name: PowerConsumption - name: Temperature

Events

Bare Metal Orchestrator can generate events that helps you to respond to state changes in the Bare Metal Orchestrator resources. An event could be a create, update, or delete operation, a resource life-cycle state change, or a system event impacting a resource.

User can subscribe events for create, update, or delete operations on the following components: Server controller Hardware controller Tenant controller Site controller

Subscribe an event

Prerequisites

You must be logged into Bare Metal Orchestrator as a Dell user. For high availability Bare Metal Orchestrator configurations, log into the Load Balancer VM.

Monitoring Bare Metal Orchestrator 125

About this task

Follow these steps to subscribe for an event:

Steps

1. Establish a CLI session on the Bare Metal Orchestrator VM. For high availability configurations, establish a CLI session using the virtual IP (VIP) of the Load Balancers for the Bare Metal Orchestrator cluster.

2. Navigate to ~/samples/event-router and download any one sample configuration templates to your local machine based on your requirements:

Config-httpsink.json Config-kafka.json

3. Edit the json file and update the required attributes using Vim or a similar editor. For more information see Event field definitions.

The following is an example of Config-httpsink.json file:

{ "sink": "http", "httpSinkUrl": "http://httpsink.metalweaver.svc.cluster.local:5556/events", "sinkOutputFormat": "cloudEvents", "timeout": "30s", "retryCount": 5, "retryDelay": "10s", "unsubscribe": false, "subscribedEventTypes": "Normal Warning", "subscribedObjects": "Server Site HardwareProfile Tenant Switch Stackdeployer", "headers": { "Authorization": "Bearer superSecret" }

The following is an example of Config-kafka.json file:

{ "sink": "kafka", "kafkaBrokers": "my-cluster-kafka-external-bootstrap.my-kafka- project.svc.cluster.local:9094", "kafkaTopic": "my-topic", "subscribedEventTypes": "Normal Warning", "subscribedObjects": "Server Site HardwareProfile Tenant Switch Stackdeployer", "unsubscribe": false, "async": false, "sinkOutputFormat": "cloudEvents" }

4. Save the file and quit the editor.

5. Run the following command to encode the json file using base64 encoding.

base64 -w 0 For example:

#base64 -w 0 Config-httpsink.json ewogICAgInNpbmsiOiAia2Fma2EiLAogICAgImthZmthQnJva2VycyI6ICJteS1jbHVzdGVyLWthZmthLWV4dG VybmFsLWJvb3RzdHJhcC5teS1rYWZrYS1wcm9qZWN0LnN2Yy5jbHVzdGVyLmxvY2FsOjkwOTQiLAogICAgImth ZmthVG9waWMiOiAibXktdG9waWMiLAogICAgInN1YnNjcmliZWRFdmVudFR5cGVzIjogIk5vcm1hbCBXYXJuaW 5nIiwKICAgICJzdWJzY3JpYmVkT2JqZWN0cyI6ICJTZXJ2ZXIgU2l0ZSBIYXJkd2FyZVByb2ZpbGUgVGVuYW50 IFN3aXRjaCBTdGFja2RlcGxveWVyIiwKICAgICJ1bnN1YnNjcmliZSI6IGZhbHNlLAogICAgImFzeW5jIjogZm Fsc2UsCiAgICAic2lua091dHB1dEZvcm1hdCI6ICJjbG91ZEV2ZW50cyIKICB9CiAg

NOTE: Base64 encoding must be done whenever you update the json file.

6. Run:

bmo edit secret -n

126 Monitoring Bare Metal Orchestrator

For example:

bmo edit secret mw-event-router-secret -n mw-event-router-system

7. Edit the mw-event-router-secret file in Vim or a similar editor to update the config.json field with the base64 encoded content that was generated earlier. The following is an example of the .yaml file:

apiVersion: v1 data: config.json: W2RlZmF1bHRdCmF3c19hY2Nlc3Nfa2V5X2lkID0gbXlhY2Nlc3NrZXkKYXdzX3NlY3JldF9hY2Nlc3Nfa2V5ID 0gbXlzZWNyZXRrZXkK kind: Secret metadata: name: mw-event-router-secret namespace: mw-event-router-system type: Opaque

8. Save the file and quit the editor.

Monitoring Bare Metal Orchestrator 127

YAML schema

Topics:

YAML objects and common fields Metadata YAML field specifications YAML status fields Stack status fields

YAML objects and common fields You can create, edit, view, or delete objects with the YAML file. The following objects are supported:

server hardwareprofile media firmwaremedia user role site node tenant stack switch backup backup restore backup schedule backup location secret The .yaml file typically contains the following fields:

apiVersion Defines the version of the Kubernetes API that you are using for an object. The apiVersion is set to mw.dell.com/v1. Do not update this field.

kind A string value representing the type of the object. For example: Server. Do not update this field.

metadata Contains information about the object, such as its labels. You can update the metadata. For more information, see Metadata.

spec The specification section that contains configuration details of the objects. Specification differs based on the object created. This is an editable field. For more information about the specifications for different objects, see YAML field specifications.

status An auto-generated field that reports the current state of the system. Do not update this field. For more information about the status, see YAML status fields.

CAUTION: You can provide BMC credentials when creating a server or a hardware profile. The BMC password

that is provided is in a plain-text format, which is less secure. Ensure that you secure the appropriate YAML

files to safeguard your system from malicious attacks.

A

128 YAML schema

Metadata

The .yaml file metadata is described in the following table:

Table 32. YAML File Metadata

Field Description Supported values

name Name that describes the object. For example:

If you are creating a server, you can name it dell-server1.

If you are creating a site, you can name it austin.

If you are creating media, you can name it os-media.

NOTE: If discoveryViaDhcp is set to auto, the prefix auto- is

added to the site name.

The first and last character must be alphanumeric.

The maximum character limit for a server name is 51.

The maximum character limit for a site name is 253.

Alphanumeric (a to z, 0 to 9), dash (-), or period (.)

labels Specifies one or more labels and their values. You can define your own labels. However, the profile label is reserved for internal operations such as server decommissioning.

A site label is mandatory for server, switch, and hardware profiles.

site: Location field of the site. This is a required field.

NOTE: The site label must match the value set for the metadata location in the site object.

Examples of user-defined labels that you can use to identify and target specific servers and switches:

vendor: The name of the hardware manufacturer.

NOTE: Servers and switches that are auto-discovered have vendor labels that are updated automatically.

model: The model of the server or the switch. tenantName: Name of the tenant. Add this label to apply hardware profiles on the servers present under a tenant.

The maximum character limit is 63.

The first and last character must be alphanumeric.

Alphanumeric (a to z, A to Z, 0 to 9), dash (-), underscore (_), period (.), or can be left empty

YAML field specifications The following sections define YAML fields that are used to configure Bare Metal Orchestrator and its environment.

Site field definitions

The following table contains definitions and supported values for the fields in a site.

Table 33. Site Field Definitions

Field Description Example supported values

nodeName The name of the node where the site is deployed.

Must be the name of the Global Controller node or an existing worker node. Worker node names are user configurable.

bmo-manager-1 (Global Controller default)

worker1, worker2, etc.

YAML schema 129

Table 33. Site Field Definitions (continued)

Field Description Example supported values

type The site type. Use global for the Global Controller node. Use remote for remote worker sites that you create.

global or remote

location The site location. The supported characters are alphanumeric (a to z, 0 to 9) and hyphen (-). The maximum character limit is 15. The first and last character must be alphanumeric.

miami, austin, and so on

dhcpDeployMode See DHCP fields for descriptions. Not applicable.

DhcpConfigData See DHCP fields for descriptions. Not applicable.

reInitialize A value of "true" reinitializes and reinstates the site.

The reInitialize attribute is automatically removed from the YAML file after it has run.

When set to "false", no action is taken.

true or false

id An optional Common Language Location Identifier (CLLI) or any desired identifier code.

AUSTTXBC

city The city where the site is deployed. Mandatory attribute. Austin

state The state where the site is deployed. Mandatory attribute. Texas

address The address where the site is deployed. Mandatory attribute. 1 Dell Way, RR, TX 78682, USA

country The country where the site is deployed. Mandatory attribute. USA

latLong Optionally, set the geographic coordinates to indicate the position of the site.

30.48921768077312, -97.67029215397606

DHCP fields

Table 34. DHCP Fields

Field Description Example supported values

dhcpDeployMode How to use DHCP with Bare Metal Orchestrator. Options are no DHCP server and a managed Kubernetes pod providing a DHCP server or relay.

none

server

relay

autoDiscoveryMode Top-level field for server discovery by DHCP. Not applicable

discoveryViaDhcp Set the server discovery by DHCP to automatic or none. auto or none

DhcpConfigData Top-level field for your DHCP configuration values. Not applicable

dhcpSubnet You can define as many subnets as you need. Not applicable

defaultLeaseTime Default lease time for this subnet, in seconds. 3000

maxLeaseTime Maximum lease time for this subnet, in seconds. 6000

netmask The netmask for the subnet. 255.255.255.0

optionBroadcastAddress The broadcast address that is provided to clients for this subnet.

IPv4 address

optionRouters The gateway that is provided to clients for this subnet. IPv4 address

optionSubnetMask The subnet mask that is provided to clients for this subnet. 255.255.255.0

subnet The IP address of the subnet. IPv4 address

dhcpPool Define one or more DHCP IP pools. Not applicable

130 YAML schema

Table 34. DHCP Fields (continued)

Field Description Example supported values

allowMembers Define what can lease an IP address from this DHCP IP pool. This must be a vendor class identifier that is specified in the vendorClassIdentifier list.

For example:

iDRAC

denyMembers Define what cannot lease an IP address from this DHCP IP pool. This must be a vendor class identifier that is specified in the vendorClassIdentifier list.

Vendor class identifiers are transmitted with DHCP requests for IP addresses from clients.

For example:

A Linux server could send Linux 2.4.34 i686

endRange DHCP pool starting IP address. IPv4 address

startRange DHCP pool ending IP address. IPv4 address

interfaces A comma-separated list of network interface names that the DHCP server services clients on.

ens192, ens224

domain Top-level domain for your DHCP server. example.com

dns A comma-separated list of DNS server IP addresses. IPv4 addresses

additionalDhcpConfig A semicolon-separated list of DHCP server configuration commands.

See: ISC DHCP 4.4 Manual Pages - dhcpd.conf

vendorClassIdentifier Every DHCP client includes a vendor class identifier in DHCP requests that it sends to a DHCP server. A vendor class identifier is a text string that identifies the type of device.

For iDRACs, the vendor class identifier is "iDRAC".

This setting is used in the allowMembers and denyMembers fields. This action configures the DHCP server to only provide IP addresses from a pool to devices that have the given vendor class identifier.

A DHCP pool that has allowMembers: "iDRAC" causes the DHCP server to only allocate IPs in this pool to iDRACs. In this example, "iDRAC" must also appear in the vendorClassIdentifier list.

NOTE: For Supermicro servers, the vendor class identifier is udhcp 1.23.1 for the SYS-1019P-FRN2T model.

For Dell switches, the vendor class identifier is onie_vendor:x86_64-dellemc.

For HPE iLO servers, the vendor class identifier is CPQRIB3.

All values are supported.

dhcpRelayConfig Top-level field for DHCP relay configuration. Not applicable

dhcpForwardIpAddress The forwarding IP address of the external DHCP server. IPv4 addresses

bootSize The size of the primary boot image to download from the TFTP server. It is calculated from the size of the boot file in bytes divided by 512.

370

inbandIP The private IP from which the PXE InBand VLAN is configured.

A valid IP address

YAML schema 131

Server and hardware profile field definitions

The following sections describe server and hardware profile field definitions.

Server connectivity field definitions

This table contains definitions and supported values for the following fields in the server.

Table 35. Server connectivity field definitions

Field Description

bmcEndPoint The IP address of the BMC.

userName Add a BMC username.

password Add a BMC password.

NOTE: If the username and password credentials were added to the cred.yaml file, then adding them here using the

userName and password attributes is optional.

Power field definitions

The following table contains the definition and supported values for the power state.

Table 36. Power field definitions

Field Description Supported values

powerstate Power status of the server. On or Off

Server location field definitions

The following table describes the server location fields and their supported values.

Table 37. Server location field definitions

Field Description Supported values

placement rack: The rack name or number.

NOTE: Row numbers are the rack number within the row.

For example:

Rack 922

row: The row that the rack containing the server resides in. For example:

Row 80

postaladdress building: The name of the building where the server is located. For example:

Dell RR4

room: The name or number of the room where the server is located. For example:

Room 50

Server and profile telemetry field definitions

The following table describes the server and profile telemetry fields in the server YAML file and their supported values.

132 YAML schema

Table 38. Server and hardware profile telemetry field definitions

Field Description Supported values

telemetryEnable To enable telemetry on a server. Enabled or disabled

reconcileTelemetry To configure telemetry metrics. True or false

Operating system field definitions

This section provides field definitions and configurable values that Bare Metal Orchestrator supports for operating system server deployments.

The following table lists common operating system attributes that you configure when deploying an operating system on a server.

Table 39. Common operating system attribute settings

Field Description Supported values

operatingsystemname The name of the operating system media.

This name must match the metadata name value in the media object.

For ESXi, updating this field initiates an operating system version upgrade.

Examples:

esxi6.7u3

rhel8.4

suse15.3

wrmedia

overwriteInstallation Optional attribute used to overwrite the existing operating system that is installed on the server when you perform an operating system upgrade.

true or false

operatingsystemconfig

autoConfigureBoss Optional: Creates and configures a RAID 1 volume in BOSS cards for an OS install if the original volume is deleted or does not exist. The newly created volume is used to install and boot the OS. Set the value to true to store the OS install on the RAID 1 volume.

true or false

networkingDetails Optional attribute used to set a specific hostname for a server.

Updating the hostname value sets the hostname for the operating system on the server. This value is applied only when the OS installation is run on the server.

Make sure each hostname is unique and is configured on each server separately before installing an OS with a hardware profile.

NOTE: The networkingDetails field must be configured through the server profile only.

Examples:

esxi-hostname

rhel-hostname

suse-hostname

wr-hostname

ntpServer Specifies a list of NTP server names or serverIPv4 IP address for ESXi operating system. You can configure up to three NTP servers.

A valid IP address or server name

dnsSearch The local domain name which is affixed to a name that is not qualified. For example, if the DNS search domain is set to dell.com, and the name to be resolved is www, then the system searches for www.dell.com.

For example:

www.dell.com

dnsServer Specifies a list of DNS serverIPv4 IP address for ESXi operating system.

For example:

127.0.0.1

installVolumeID The FQDD identifier of the RAID, Host Bus Adapter (HBA), SD card inventory, or NVM Express (NVMe) volume to install the operating system on.

Example:

YAML schema 133

Table 39. Common operating system attribute settings (continued)

Field Description Supported values

Updating the installVolumeID in a hardware profile requires that the volume must have the same identifier available on all servers that the profile targets.

Optional field: If no value is specified, the system selects a volume for installing an operating system from the installVolumeTypeOrder field.

For RAID: Disk.Virtual.0:RAID.Slot.2-1

For SD card inventory: Disk.SDInternal.1

installVolumeTypeOrder Specify the order in which the volume type is selected for operating system installation.

The system checks the volumes starting with the first volume type. If the volume type is present on the server, the operating system is installed on that volume. If that volume type does not exist on the server, the next type is checked.

Optional field: If no value is specified, the system selects the volume for installing an operating system from the installVolumeID field.

For HBA, SDCARD, NVME and BOSS, the first volume name of that type that displays in the storage field of the status section is selected for operating system installation.

For RAID, you can specify the volume name. It must match the value set for the attribute name in the raidVolumes.

Delete all RAID volumes available on the server where the operating system was previously deployed if: an operating system is deployed on a specific RAID

volume. you want to install the operating system on a different

RAID volume.

You can now install the operating system on the new RAID volume.

For example, if an operating system is deployed on RAID Volume1, and you want to install the operating system on RAID Volume2, delete all RAID volumes that are used for the operating system installation. You can then perform operating system deployment on RAID Volume2.

NOTE: If a server does not have any storage controllers or volumes, then the ESXi OS installation installs onto the default hard drive.

SDCARD

NVME

RAID

HBA

BOSS

The following table lists configurable ESXi-specific operating system settings. For all operating system deployment settings and the preseed sample content, see Sample operating system deployment YAML files - ESXi .

Table 40. ESXi-specific operating system settings

Field Description Supported values

operatingsystemconfig

configtype Operating system configuration type. The Preseed file contains configurations that are required for operating system installation.

preseed

osDriver The name of the device driver media files. Examples:

icen-media

ibbd-media

intnet-media

134 YAML schema

Table 40. ESXi-specific operating system settings (continued)

Field Description Supported values

Preseed configdata settings

configdata Use the sample preseed configdata and update the following attributes.

For information about preseed file commands, see Installation and Upgrade Script Commands in the VMware vSphere Product Documentation for VMware vSphere 6.7.

NOTE: The blank lines between each command in the configdata section are required for successful operating system deployment.

See sample preseed configdata

rootpw Enter the host operating system password for root user. This is a user-supplied value.

network Add server network information where you are installing the operating system.

--bootproto: specify whether to obtain the network settings from DHCP or set them manually. The supported values are dhcp or static.

NOTE: For PXE boot, the bootproto must be set to dhcp.

The following fields are required if bootproto is set to static:

ip IP address of the server

gateway Default gateway IP address

netmask Subnet mask of the server

nameserver IP address of the DNS server. Omit this option if you do not intend to use a DNS server

vlanid The VLAN the server is on.

--device: specify the MAC address of either the network card or the server. For example: A0:12:10:00:C0:D3

--hostname: ESXi hostname. For example: esxi1.dell.com. This is an optional field.

Set bootproto to dhcp when using a hardware profile to configure the network attributes. Only one network entry is needed to install the operating system on multiple servers using a hardware profile.

Set bootproto to either static or dhcp when using a server YAML file to configure the network attributes. If the server has one or more NICs with multiple networking ports to set up, add separate network entries for each on separate lines in the server YAML file. Include the device attribute. Specify the MAC address of the NIC that you are setting up, which is from the BMC settings. The first NIC is used by default if the device attribute is omitted.

The following table lists configurable openSUSE-specific operating system settings. For all operating system deployment settings and the autoyast sample content, see Sample operating system deployment YAML files - openSUSE .

NOTE: The autoyast configdata section contains XML code. In the table, XML formatting is omitted and elements are

listed by name. However, some examples are presented using valid XML format. User-configurable PCDATA is listed under

supported values and appears as bold, italicized text in example code.

YAML schema 135

For example:

suse1

Table 41. openSUSE-specific operating system settings

Field Description Supported values

operatingsystemconfig

configtype Operating system configuration type. The autoyast file contains configurations that are required for operating system installation.

autoyast

autoyast configdata settings

configdata Use the sample autoyast file and update the configurable attributes.

NOTE: The XML elements are grouped and nested within attribute categories as listed in this table.

See the sample autoyast configdata

general mode

confirm config:type="boolean"

Enter a value of false so that the autoyast settings are automatically accepted and the installation can start.

true or false

final_halt config:type="boolean"

Enter the value false so that the VM does not shut down after the operating system is installed and configured.

true or false

timezone

hwclock Set whether the hardware clock uses local time or UTC. The default is UTC.

localtime or UTC

timezone Set the server time zone. Example:

America/Chicago

networking

keep_install_network config:type="boolean"

Merges the network configuration of the VM with the network configuration that is defined in this file. Set this element to true.

true or false

dns Nest the following elements within the DNS element and provide the necessary networking values:

hostname: This optional element provides the hostname, excluding the domain name. For example:

suse1 nameserver: Provide the IP address of the VM. For multiple

VMs, repeat this line for each IP address. For example:

1.2.3.4 1.2.3.3

See description

interfaces config

bootproto Specify whether to obtain the network settings from DHCP or set them manually. The supported values are dhcp or static.

Set bootproto to dhcp when using a hardware profile to deploy the operating system on multiple servers.

The following fields are not required if bootproto is set to dhcp:

dhcp or static

136 YAML schema

Table 41. openSUSE-specific operating system settings (continued)

Field Description Supported values

broadcast device ethtool_options ipaddr netmask Use dhcp when a DHCP server is set up (either an external DHCP server or local). This action provides IP addresses to the host operating system on the target server. If DHCP is used, then only the device name and the startmode are supplied.

You can set bootproto to either static or dhcp when using a server YAML file to deploy the operating system. If the server has one or more NICs with multiple network ports to set up, add a separate interface section for each port.

broadcast The broadcast IP address. This element is not required with DHCP.

A valid IP address

device A user-defined name for the interface. This element is not required with DHCP.

Example: p1p1

ethtool_options Optionally, specify the ethtool option during device activation. This element is not required with DHCP.

autoneg on or

autoneg off

ipaddr The IP address that is assigned to the interface. This element is not required with DHCP.

A valid IP address

netmask The subnet mask of the server. This element is not required with DHCP.

A valid subnet mask

startmode Defines when to bring up an interface. Supported values include: onboot hotplug auto ifplugd manual nfsroot off

Example: onboot

routing

destination Defines the route destination. This element is not required with DHCP.

Only one destination can be the default route. When defining multiple routes, you can assign the other destinations an IP address prefix.

default

For additional routes, an IP address prefix.

Example: 100.10.1.0/24

gateway The default gateway IP address. This element is not required with DHCP.

A valid IP address

device Enter the device name of the interface to associate with this route. This element is not required with DHCP.

Example: p1p1

services manager

services This is an optional section that you can add to automatically start system services after openSUSE is installed. Enter as many services as you want started.

See sample file

software

YAML schema 137

Table 41. openSUSE-specific operating system settings (continued)

Field Description Supported values

package The first two instances of the package element define the software packages that are required to run the second stage of the operating system installation.

autoyast2-installation

autoyast2

package Optionally, you can install other software packages during the operating system deployment. For example: openssh vim-data zypper iputils vim bash curl

See description

partitioning config

drive This mandatory section is added to install the operating system on a specific drive and to format the data from the drive.

See sample file

users config

user Defines the username, password, and if password encryption is used for a user. If you have multiple users, add a separate user code block for each user.

Set encrypted config to true if an encrypted password is used. Set to false if the password is not encrypted.

Enter the user password in the user_password element. Enter the user name in the username element.

NOTE: Ensure that the user is already setup for root access on the VM.

For encrypted config:

true or false

The following table lists configurable Red Hat Enterprise Linux-specific operating system settings. For all operating system deployment settings and the kickstart sample content, see Sample operating system deployment YAML files - Red Hat Enterprise Linux.

Table 42. Red Hat Enterprise Linux-specific operating system settings

Field Description Supported values

operatingsystemconfig

configtype Operating system configuration type. The Kickstart file contains configurations that are required for operating system installation.

kickstart

kickstart configdata settings

configdata Use the sample kickstart file and update the following attributes.

For information about Kickstart file commands, see APPENDIX J. KICKSTART COMMANDS AND OPTIONS REFERENCE in the Red Hat Enterprise Linux 8 System Design Guide on the Red Hat Customer Portal.

NOTE: The blank lines between each command in the configdata section are required for successful operating system deployment.

See sample kickstart configdata

rootpw Enter the host operating system password for root user. This is a user-supplied value.

138 YAML schema

Table 42. Red Hat Enterprise Linux-specific operating system settings (continued)

Field Description Supported values

lang Set the server language. The default is en_US.

See the Red Hat website for a complete list of supported languages.

Example: es_ES

keyboard Set the keyboard language. The default is us.

See the Red Hat website for a complete list of supported languages.

Example: fr

timezone Set the server time zone. The default is America/New_York --isUtc.

See the Red Hat Enterprise Linux website for information about the time zone and supported values.

Example:

America/New_York --isUtc

network Add server network information where you are installing the operating system.

--bootproto: specify whether to obtain the network settings from DHCP or set them manually. The supported values are dhcp or static.

NOTE: For PXE boot, the bootproto must be set to dhcp.

The following fields are required if bootproto is set to static:

ip IP address of the server

gateway Default gateway IP address

netmask Subnet mask of the server

nameserver IP address of the DNS server. Omit this option if you do not intend to use a DNS server

vlanid The VLAN the server is on.

--device: specify the MAC address of either the network card or the server. For example: A0:12:10:00:C0:D3

--hostname: The server hostname. For example: rhel1.dell.com. This is an optional field.

-- network adapter settings: specify whether to enable or disable the VirtualizationMode. The supported values are SRIOV to enable, or NONE to disable.

Set bootproto to dhcp when using a hardware profile to configure the network attributes. Only one network entry is needed to install the operating system on multiple servers using a hardware profile.

Set bootproto to either static or dhcp when using a server YAML file to configure the network attributes. If the server has one or more NICs with multiple networking ports to set up, add separate network entries for each on separate lines in the server YAML file. Include the device attribute. Specify the MAC address of the NIC that you are setting up, which is from the BMC settings. The first NIC is used by default if the device attribute is omitted.

See the sample YAML file

selinux Enable or disable Security-Enhanced Linux (SELinux) for the server.

--disabled

--enforcing

YAML schema 139

Table 42. Red Hat Enterprise Linux-specific operating system settings (continued)

Field Description Supported values

--permissive

firewall Enable or disable the Red Hat Enterprise Linux default firewall for the server.

--enabled or --disabled

@'minimal-environment Install the minimum required Red Hat Enterprise Linux operating system packages on the server. Dell Technologies recommends installing the minimal package.

@'minimal-environment

The following table lists configurable Wind River Cloud Platform operating system settings. For all operating system deployment settings and the kickstart sample content, see Sample operating system YAML files - Wind River Cloud Platform.

Table 43. Wind River Cloud Platform operating system settings

Field Description Supported values

operatingsystemname The name of the operating system media.

This name must match the metadata name value in the media object.

Example: wrmedia

operatingsystemconfig

bootMenuOption Sets the Wind River stack deployment mode. Supported options include:

Option 2: All-in-one duplex mode for serial consoles Option 3: All-in-one duplex mode for graphical consoles

2 or 3

installVolumeID The FQDD identifier of the RAID, HBA, SD card inventory, or NVMe volume to install the operating system on.

Updating the installVolumeID in a hardware profile requires that the volume must have the same identifier available on all servers that the profile targets.

Optional field. If no value is specified, the system selects a volume for installing an operating system from the installVolumeTypeOrder field.

Examples:

For RAID: Disk.Virtual.0:RAID.Slot.2-1

For SD card inventory: Disk.SDInternal.1

installVolumeTypeOrder Specify the order in which the type of volume is selected for installing an operating system.

The system checks the volumes starting with the first volume type. If the volume type is present on the server, the operating system is installed on that volume. If that volume type does not exist on the server, the next type is checked.

Optional field. If no value is specified, the system selects the volume for installing an operating system from the installVolumeID field.

For HBA, SDCARD, NVME and BOSS, the first volume name of that type that displays in the storage field of the status section is selected for operating system installation.

For RAID, you can specify the volume name. It must match the value set for the attribute name in the raidVolumes.

Delete all RAID volumes available on the server where the operating system was previously deployed if: an operating system is deployed on a specific RAID

volume. you want to install the operating system on a different

RAID volume.

NVME

SDCARD

RAID

HBA

BOSS

140 YAML schema

Table 43. Wind River Cloud Platform operating system settings (continued)

Field Description Supported values

For example, suppose that the Wind River Cloud Platform operating system is deployed on RAID Volume1. To install the operating system on RAID volume2, delete all RAID volumes that are used for the Wind River Cloud Platform operating system installation. You can then perform operating system deployment on RAID Volume2.

minimumDiskSize The minimum volume size of the operating system installation that is entered as a numerical value in gigabits. The default value is 500 GB.

Example: 500

configtype Operating system configuration type. The Kickstart file contains configurations that are required for operating system installation.

kickstart

kickstart configdata settings

configdata Use the sample kickstart file and update the following attributes.

NOTE: The blank lines between each command in the configdata section are required for successful operating system deployment.

See sample kickstart configdata

OAM_DEV= Enter the enumerated interface name of the BMC on the server where the operating system is to be installed.

Example:

OAM_DEV=enp94s0f0

OAM_VLAN= Sets the VLAN that the server is on. Example:

OAM_VLAN= 33

DEVICE= Specify the BMC device to use. Example:

DEVICE=OAM_DEV

BOOTPROTO= A boot-time protocol should not be used with the Wind River Cloud Platform. Enter a value of none.

none

IPADDR= The IP address of the server that is hosting the operating system.

A valid IP address

PREFIX= Enter the network subnet value. Example: 24

GATEWAY= Default gateway IP address. A valid IP address

ONBOOT= Specify if you want the interface to be activated at boot time. yes or no

VLAN Specify if the server is on a VLAN. yes or no

LINKDELAY= The amount of time that is entered (as an integer in seconds) to wait for link negotiation to complete before configuring the device.

Example: LINKDELAY= 30

Firmware field definitions

The following table contains definitions and supported values for the fields in firmware.

Table 44. Firmware field definitions

Field Description

firmwareNames List of firmware media to install.

YAML schema 141

Table 44. Firmware field definitions

Field Description

Specify all the firmware names if you are performing multiple firmware updates.

NOTE:

The firmware name must match the metadata name value in the firmware media object.

BIOS attribute definitions

For operating system deployments, a short list of BIOS attributes is supported.

Table 45. BIOS attributes supported for operating system deployments

Operating system Supported attributes

ESXi 6.7u3 procVirtualization: Enabled

bootMode: Uefi or Bios

serialPortAddress: Com1 or Com2

For Dell PowerEdge 14th generation servers, XR11 and XR12 Dell PowerEdge servers: Com1 For Dell PowerEdge 15th generation servers: Com2

openSUSE 15.3

Red Hat Enterprise Linux 8.4

Wind River Cloud Platform 21.05

bootMode: Uefi

serialPortAddress: Com1 or Com2

For Dell PowerEdge 14th generation servers, XR11 and XR12 Dell PowerEdge servers: Com1 For Dell PowerEdge 15th generation servers: Com2

Table 46. Boot settings

Attribute Description Supported values Supported vendors

setBootOrderEn Enables the boot option on the next boot for the list of FQDDs.

For example:

Disk.Bay.22

NIC.PxeDevice.1-1

PCIeExtender.Slot.1

Dell

setBootOrderDis Disables the boot option on the next boot for the list of FQDDs. A boot device cannot be mentioned

in setBootOrderEn and setBootOrderDis simultaneously.

The devices that are specified in the boot order are specific to a server. When you update the boot order in a hardware profile, make sure the same boot devices are on all the servers that are targeted by the hardware profile.

setBootOrderFqdd1 Specifies a list of FQDDs that represents the boot list to be applied on the next boot.

The system attempts to boot to devices starting with the first item in the boot order. If the boot attempt fails, the system goes to the next item in the boot order until the boot is successful, or no more boot options are found.

NOTE: Do not define bootOrder in Boot

attribute definitions while using these attributes.

setBootOrderFqdd2

setBootOrderFqdd3

setBootOrderFqdd4

142 YAML schema

Table 46. Boot settings (continued)

Attribute Description Supported values Supported vendors

setLegacyHddOrderFq dd1

Specifies a list of legacy hard drives to be applied on the next boot when bootMode is set to Bios.

For example:

RAID.Integrated.1-1

RAID.*.*

*.*.*

Dell

setLegacyHddOrderFq dd2

bootMode Specifies the boot mode for operating system installation.

Bios boot mode is the legacy boot mode. It enables compatibility with older operating systems that do not support Unified Extensible Firmware Interface (UEFI).

Uefi is an interface between operating systems and platform firmware. It supports drive partitions greater than 2 TB, provides enhanced security, and faster boot time.

NOTE:

You must install the operating system in the same boot mode. If you switch boot modes, this may prevent the system from booting.

Do not define bootOrder in Boot attribute

definitions while using bootMode.

Bios or Uefi Dell

Supermicro

OneTimeBootMode Enables the boot device list from which a boot device can be selected. After selecting the One-Time Boot Device List, the desired boot device must be selected from the corresponding Sequence Device field. The system attempts to boot once to the selected device on next startup.

OneTimeBootSeq

OneTimeHddSeq

Disabled

Dell

BootSeqRetry Enables or disables the Boot Sequence Retry feature or resets the system. If the last attempt to boot has failed, the system immediately performs a cold reset or retries to boot after a 30 second time-out period, depending on if this field is set to Reset or Enabled.

Enabled

Reset

Disabled

Table 47. System profile settings

Attribute Description Supported values Supported vendors

procPwrPerf Enables selection of CPU power management methodology.

SysDbpm uses a BIOS-controlled dynamic frequency manipulation scheme. This saves power across various utilization levels as part of the Dell Advanced Power Control (DAPC) capability.

OsDbpm is a performance-per-watt option that relies on the operating system to dynamically control individual core frequency. Both Windows and Linux can take advantage of this mode to reduce frequency of idle or underused cores to save power.

MaxPerf is typically selected for performance- centric workloads where it is acceptable to consume additional power to achieve the highest possible performance for the computing environment.

SysDbpm, OsDbpm, or MaxPerf

Dell

Supermicro

YAML schema 143

Table 47. System profile settings (continued)

Attribute Description Supported values Supported vendors

This mode drives processor frequency to the maximum across all cores and is always preferred for latency-sensitive environments.

memFrequency Enables selection of the system memory speed. NOTE: You can save more power by reducing the memory frequency, at the expense of reduced performance.

MaxPerf, 3200 MHz

2933 MHz, 2666 MHz

2400 MHz

2400 MHz

2133 MHz

1866 MHz

MaxReliability

procTurboMode Enables or disables processor turbo boost mode.

Turbo boost allows the processor cores to automatically enhance frequency beyond the advertised processor speed.

Enabled or Disabled

procC1E Enables or disables the processor to switch to a minimum performance state when it is idle.

Enabled or Disabled

procCStates Enables or disables the processor to operate in all available power states.

NOTE: When set to Enabled or Autonomous,

memory latency and frequency jitter may increase.

Enabled

Disabled

Autonomous

writeDataCrc Enables or disables the Write Data CRC. Enabled or Disabled

memPatrolScrub Sets the memory patrol scrub frequency. Patrol scrubbing searches the memory for errors and then repairs correctable errors, which prevents memory errors from accumulating.

NOTE:

Set to Extended to frequently scrub the entire memory array to further increase system reliability.

Set to Standard to scrub the entire memory array once in a 24-hour period.

Set to Disabled to stop patrol scrubbing.

Extended, Standard, or Disabled

memRefreshRate The memory controller periodically refreshes the data in the memory.

Set to 1x to indicate the frequency at which memory is refreshed.

Set to 2x to increase system reliability or when memory modules are operating at a higher than normal temperature.

CAUTION: Setting the refresh rate to 2x may have a negative impact on the memory subsystem performance.

1x or 2x Dell

Supermicro

uncoreFrequency Enables selection of the Processor Uncore Frequency. DynamicUFS or MaxUFS Dell

144 YAML schema

Table 47. System profile settings (continued)

Attribute Description Supported values Supported vendors

Set to DynamicUFS to allow the processor to optimize power resources across the cores and uncore during runtime.

energyPerformanceBias Enables selection of the energy-efficient policy.

The CPU uses this setting to manipulate internal processor behavior and determines whether to target higher performance or better power savings.

MaxPower

BalancedPerformance

BalancedEfficiency

LowPower

Dell

Supermicro

proc1TurboCoreNum Controls the number of turbo boost enabled cores for the Processor.

NOTE:

Set ProcTurboMode to Enabled and

ProcPwrPerf to MaxPerf on the server

before updating this field.

If this field value is greater than the number of available processor cores, the value gets automatically set to All instead of the given

value.

All, 1, 2, 4, 6, 8, 10, 12, 14, 16, 18, 20, 22, 24, 26, 28

Dell

proc2TurboCoreNum

monitorMwait Enables or disables the Monitor/Mwait instructions in the processor.

NOTE: This is a read-only field when ProcCStates is set to Enabled.

Enabled or Disabled

cpuInterconnectBusLin kPower

Enables or disables the CPU Interconnect Bus Link Power Management.

CAUTION: If this is Enabled, the CPU

Interconnect Bus Link Power Management can reduce the overall system power and performance slightly.

CpuInterconnectBusSp eed

Sets the frequency of the communication links among the CPUs in the system.

Maximum Data Rate indicates that the BIOS runs the communication links at the maximum frequency that is supported by the processors.

Maximum Data Rate Dell

Supermicro

pcieAspmL1 Enables or disables the PCI Advanced State Power Management (ASPM) L1 Link Power Management.

If this is Enabled, it may slightly reduce overall system power and performance.

NOTE: Some devices may become unresponsive or cause the system to become unresponsive when ASPM is enabled. For this reason, ASPM is only enabled for validated qualified cards.

Dell

OsAcpiCX Sets the OS ACPI Cx to C2 or C3 state. OsCxC2 or OsCxC3

ProcessorGpssTimer Allows the reduction of the GPSS timer to be set from 0-500us (typical value is 500us).

NOTE: This attribute is read-only and cannot be edited.

For XR11: 0us - 500us

YAML schema 145

Table 47. System profile settings (continued)

Attribute Description Supported values Supported vendors

ProcessorC1AutoDemot ion

Allows the CPU core to automatically demote to lower core idle states, when enabled.

NOTE: These attributes are read-only and cannot be edited.

Enabled or Disabled Dell

ProcessorC1AutoUnDe motion

Allows the CPU to automatically undemote from demoted C1 state, when enabled.

NOTE: These attributes are read-only and cannot be edited.

Enabled or Disabled

DynamicL1 This field only applies to the package level setting to allow dynamic entering lower power link state L1.

Enabled or Disabled

PackageCStates Enables or disables the package to transition to deeper C-states or limit to operational state.

Enabled or Disabled

SysProfile Sets the System Profile to Performance Per Watt (DAPC), Performance Per Watt (OS), Performance, Workstation Performance, or Custom mode.

When set to a mode other than Custom, BIOS sets each option accordingly.

When set to Custom, you can change setting of each option. Under Custom mode when C state is enabled, Monitor/Mwait should also be enabled.

Performance Per Watt (DAPC)

Performance Per Watt (OS)

Performance

Workstation Performance

Custom

WorkloadProfile Allows optimization of performance that is based on the workload type. The Workload Profile setting is not a 'state'. Setting a workload profile is a one-time action that in turns modifies various BIOS settings to be optimized for the requested workload type.

Not Configured

HPC Profile

Low Latency Optimized Profile

Virtualization Optimized Performance Profile

Virtualization Optimized Performance Per Watt Profile

DataBase Optimized Performance Profile

Database Optimized Performance Per Watt Profile

SDS Optimized Performance Profile

SDS Optimized Performance Per Watt Profile

Telco Optimized Profile

WorkloadConfiguration Controls the BIAS settings for energy performance, which enables the BIOS to select a configuration that improves the performance on a

NOTE: This attribute is read-only and cannot be edited.

specific workload.

Dependent on the Workload Profile selected.

Dell

AcPwrRcvry Controls the system behavior after a power failure event.

On

146 YAML schema

Table 47. System profile settings (continued)

Attribute Description Supported values Supported vendors

Set to On for the system to turn on after AC power is restored.

Set to Off for the system to stay off after AC power is restored.

Set to Last for the system to turn on if the system was on at the moment when AC power was lost. The system remains off if the system was turned off when AC power was lost. In the case of an ungraceful shutdown, the system always turns on.

Off

Last

PkgCLatNeg Controls the Package C State latency negotiation when Package C States are Enabled.

NOTE: This attribute is read-only and cannot be edited.

Enabled or Disabled

EnablePkgCriteria Enables or disables the power and system criteria for a Package C state

NOTE: This attribute is read-only and cannot be edited.

Enabled or Disabled

Table 48. System security settings

Attribute Description Supported Values Supported vendors

TpmSecurity Controls the reporting of the Trusted Platform Module (TPM) in the system. When set to On, the presence of the TPM is

reported to the OS. When set to OnPbm, the BIOS stores the Trusted

Computing Group (TCG) compliant measurements to the TPM.

When set to OnNoPbm, the BIOS bypasses most pre-boot measurements.

When set to Off, the presence of the TPM is not reported to the OS.

NOTE: For Supermicro servers, the values OnPbm and OnNoPbm are handled the same as the On value.

For Dell Servers TPM 2.0: On or Off

For Dell Servers TPM 1.2:

OnPbm

OnNoPbm

Off

For Supermicro servers:

On

Off

OnPbm

OnNoPbm

Dell, Supermicro

MemoryEncryption Enables or disables the Intel Total Memory Encryption and Multi-Tenant (Intel TME-MT). When set to Disabled, BIOS disables both TME

and TME-MT technology. When set to Single Key, BIOS enables the TME

technology. When set to Multiple Keys, BIOS enables the

TME-MT technology.

NOTE: Requires BIOS version 1.3.8 or higher

For Dell PowerEdge 15th generation servers, XR11 and XR12:

SingleKey

MultipleKeys

Disabled

Dell

PwrButton Enables or disables the power button on the front panel.

NOTE: For Supermicro, when the value is set to Disabled, pressing the power button causes

the system to turn off immediately in a legacy

Enabled or Disabled Dell

Supermicro

YAML schema 147

Table 48. System security settings (continued)

Attribute Description Supported Values Supported vendors

operating system. When the value is set to Enabled, pressing the power button for 4

seconds causes the system to turn off.

AcPwrRcvryDelay Allows staggering of power up after AC power is restored to the system. When set to Immediate, there is no delay for

power-up. When set to Random, the system creates a random

delay for power-up. When set to User-Defined, the system delays

power-up by the user-defined amount. The user- defined power-up delay is defined in the User Defined Delay field.

NOTE: You must ensure that the AcPwrRcvry value is set to On or Last in the Spec before you

can modify this attribute.

Immediate

Random

User-Defined

Dell

AcPwrRcvryUserDelay Controls the duration for which the power-on process is delayed after the AC power supply is restored. The value is only effective if the AC Power Recovery Delay is set to User-Defined.

60s to 600s

UefiVariableAccess Provides varying degrees of securing UEFI variables. When set to Standard, UEFI variables are

accessible and can be modified in the Operating System (OS) per the UEFI specification.

When set to Controlled, select UEFI variables are protected, and cannot be modified in an OS environment. New UEFI boot entries are forced to be at the end of the current boot order.

Standard or Controlled

InBandManageabilityIn terface

Enables or disables the visibility of the Management Engine's (ME) HECI devices and the IPMI devices from the operating system.

When set to Disabled, this prevents the operating system from changing the ME power capping settings, and blocks access to all in-band management tools. All management must be managed through or using out- of-band.

Enabled or Disabled

PasswordStatus Enables or disables the requirement for the system password to be changed with the use of the setup password. When set to Unlocked, the system password can

be changed without entering the setup password. This allows an administrator to maintain a setup password to protect against unauthorized BIOS Setup changes.

When set to Locked, the setup password must be entered to change the system password. This requires the setup password field to be Enabled.

Locked or Unlocked

SysPassword The system password is the password that must be entered to allow the system to boot to an operating system. Changes to the system password take effect immediately.

Alpha-numerical with a maximum of 32 characters.

148 YAML schema

Table 48. System security settings (continued)

Attribute Description Supported Values Supported vendors

NOTE: The password is read-only if the password jumper (PWRD_EN) is not installed in the system.

SetupPassword The setup password is the password that must be entered to change any BIOS settings. However, the system password can be changed without entering the correct setup password if Password Status is set to Unlocked. Changes to the setup password take effect immediately.

NOTE: The password is read-only if the password jumper (PWRD_EN) is not installed in the system.

Alpha-numerical with a maximum of 32 characters.

SHA256SystemPassw ord

SHA256 hash of the system password. Maximum of 64 characters

SHA256SystemPassw ordSalt

Salt string that is appended to the system password before hash.

Maximum of 32 characters

SHA256SetupPasswor d

SHA256 hash of the setup password. Maximum of 64 characters

SHA256SetupPasswor dSalt

Salt string that is appended to the setup password before hash.

Maximum of 32 characters

Table 49. Memory settings

Attribute Description Supported values Supported vendors

memTest Enables or disables the BIOS system memory tests during system boot.

NOTE: Enabling memory testing results in longer boot time. The increased time amount depends on the system memory size.

Enabled or Disabled Dell,

Supermicro

memOpMode Indicates the memory operating mode:

OptimizerMode DRAM controllers operate independently in 64-bit mode and provide optimized memory performance.

SingleRankSpa reMode

The memory size reported to the operating system does not include the single rank spare portion.

MirrorMode The server maintains two identical copies of data in the memory. This allows the system to continue running even during a catastrophic memory failure.

FaultResilien tMode

When Non-Uniform Memory Architecture (NUMA) is enabled, some of the installed memory in every NUMA node is configured to create a fault resilient zone. Select hypervisors use this for host virtualization resilience.

For Dell PowerEdge 14th generation servers:

OptimizerMode

SingleRankSpareMode

MirrorMode, FaultResilientMode

For Dell PowerEdge 15th generation servers:

OptimizerMode

SingleRankSpareMode

MirrorMode, FaultResilientMode

NUMAFaultResilientMode

Dell

nodeInterleave Indicates if NUMA is supported. Enabled or Disabled Dell

Supermicro

YAML schema 149

Table 49. Memory settings (continued)

Attribute Description Supported values Supported vendors

When Enabled, the system supports memory interleaving if a symmetric memory configuration is installed.

When Disabled, the system supports the NUMA asymmetric memory configuration.

This is a read-only field when SubNumaCluster is set to Enabled.

corrEccSmi Enables or disables the logging of Error Correction Code (ECC) into the Server Event Log (SEL).

NOTE: Set to Disabled to avoid latency issues.

Enabled or Disabled Dell

oppSrefEn Enables or disables the opportunistic self-refresh feature.

Enabled or Disabled

DramRefreshDelay By enabling the CPU memory controller to delay running the REFRESH commands, you can improve the performance for some workloads.

By minimizing the delay time, it is ensured that the memory controller runs the REFRESH command at regular intervals.

For Intel-based servers, this setting only affects systems that are configured with DIMMs which use 8 Gb density DRAMs.

Performance or Minimum

MemoryTraining Selects the memory training configuration. Fast: Use previously saved memory training

parameters to train the memory subsystem when memory configuration is not changed. System boot time is reduced when memory configuration is not changed. If memory configuration is changed, system automatically enables \"Retrain at Next Boot\" to force one-time full memory training steps, and then go back to \"Fast\" afterward

Retrain at Next Boot: Force one-time full memory training steps at next system power on. System boot time is slowed on next boot.

Enable: Force full memory training steps on every system power on. System boot time is slowed on every boot.

Fast

Retrain at Next Boot

Enable

CECriticalSel Enables or disables the logging of correctable memory threshold errors.

Enabled or Disabled

Table 50. Processor settings

Attribute Description Supported values Supported vendors

logicalProc Enables or disables the logical processors and displays the number of logical processors. Each processor core supports up to two logical processors.

When Enabled, the BIOS reports all logical processors.

When Disabled, the BIOS reports only one logical processor per core.

Enabled or Disabled Dell

Supermicro

150 YAML schema

Table 50. Processor settings (continued)

Attribute Description Supported values Supported vendors

procVirtualization Enables or disables the virtualization technology for the processor.

NOTE:

Enabled is the recommended setting because

disabling this setting should not impact system performance or power characteristics.

If procVirtualization is Disabled, you must

also disable proX2Apic.

Enabled or Disabled Dell

Supermicro

procAdjCacheLine Enabled optimizes the system for applications that require high utilization of sequential memory access.

Disabled optimizes the system for applications that require high utilization of random memory access.

Enabled or Disabled Dell

Supermicro

procHwPrefetcher Enables or disables the hardware prefetcher.

Enabled allows the processor to prefetch extra cache lines for every memory request.

CAUTION: This setting can affect performance, depending on the application running on the server and memory bandwidth utilization.

Enabled or Disabled Dell

Supermicro

procSwPrefetcher Enables or disables the software prefetcher.

Enabled allows the processor to prefetch extra cache lines for every memory request.

CAUTION: This setting can affect performance, depending on the application running on the server and memory bandwidth utilization.

Enabled or Disabled Dell

dcuStreamerPrefetc her

Enables or disables Data Cache Unit (DCU) streamer prefetcher. Enabled is recommended only for high performance computing applications.

CAUTION: This setting can affect performance, depending on the application running on the server.

Enabled or Disabled Dell

Supermicro

dcuIpPrefetcher Enables or disables DCU IP prefetcher. Enabled is recommended only for high performance computing applications.

CAUTION: This setting can affect performance, depending on the application running on the server.

Enabled or Disabled Dell, Supermicro

subNumaCluster Enables or disables the Sub NUMA Clustering (SNC).

SNC is a feature for breaking up the Last-level Cache (LLC) into disjointed clusters that is based on address range. Each cluster is bound to a subset of the memory controllers in the system. It improves average latency to the LLC.

This is a read-only field when NodeInterleave is Enabled.

For Dell PowerEdge 14th generation servers:

Enabled or Disabled

For Dell PowerEdge 15th generation servers:

Disabled or 2-way

Dell

Supermicro

upiPrefetch Enables or disables the start of early memory that is read on the DDR bus.

Enabled or Disabled Dell

LlcPrefetch Enables or disables the Last Level Cache Prefetch. Dell

YAML schema 151

Table 50. Processor settings (continued)

Attribute Description Supported values Supported vendors

Supermicro

dynamicCoreAllocatio n

Logical Processor Idling (LPI) is a collaborative interface between the platform and operating system that improves the energy efficiency of a system. LPI is required for power budgeting.

Disabled restricts the operating system capability to put the logical processors in idling state.

This is a read-only field when ProcPwrPerf is set to MaxPerf.

Dell

procX2Apic Enables or disable the x2APIC mode.

This is a read-only field when ProcVirtualization is Disabled.

Enabled or Disabled Dell, Supermicro

ProcessorRaplPrioriti zation

Enables or disables the Running Average Power Limiting to monitor and control the memory power in accordance to the BIOS settings.

Enabled or Disabled Dell

procCores Controls the number of enabled cores in each processor. NOTE: You may see limited performance improvements to Boost Technology and benefit from potentially larger shared caches if you reduce the number of enabled cores. Most computing environments benefit more from a larger number of processing core. So, carefully weigh the disabling of cores to gain nominal performance enhancements.

For Dell PowerEdge 14th generation servers: All, 1, 2, 4, 6, 8, 10, 12, 14, 16, 18, 20, 22

For Dell PowerEdge 15th generation servers: All, 1, 2, 4, 6, 8, 10, 12, 14, 16, 18, 20, 22, 24, and 26

Dell

Supermicro

AvxIccpPreGrantLice nse

Enables or disables the AVX ICCP Pre-Grant License. NOTE: This attribute is not available for Dell PowerEdge 14th generation servers.

Enabled or Disabled Dell

AvxIccpPreGrantLev el

When the AVX License Pre-Grant attribute is Enabled, you can use this option to select the AVX ICCP Pre- Grant license level.

NOTE: This attribute is not available for Dell PowerEdge 14th generation servers.

For Dell PowerEdge 15th generation servers: IccpHeavy128

256 Light

256 Heavy

512 Light

512 Heavy

ProcAvxP1 Selects the AVX P1 level. Normal

Level1

Level2

Dell

Supermicro

DirectoryMode Enables or disables directory mode. Enabled or Disabled Dell

MadtCoreEnumeratio n

Determines how BIOS enumerates processor cores in the ACPI MADT table. Round Robin: processor cores are enumerated in

a Round Robin order to evenly distribute interrupt controllers for the OS across all Sockets and Dies.

Linear: processor cores are enumerated across all Dies within a Socket before enumerating additional

Round Robin or Linear

152 YAML schema

Table 50. Processor settings (continued)

Attribute Description Supported values Supported vendors

Sockets for a linear distribution of interrupt controllers for the OS.

XptPrefetch XPT prefetch is a mechanism that enables the MS2IDI to take a read request that is being sent to the LLC and speculatively issue a copy of that read to the memory controller.

Enabled or Disabled

DeadLineLlcAlloc Enables or disables the filling of deadlines in LLC. Enabled or Disabled

DirectoryAtoS Enables or disables AtoS optimization, which reduces remote read latencies for repeat read accesses without intervening writes.

Enabled or Disabled

ControlledTurbo Enables or disables the turbo engagement feature. It is active when: System Profile is set to Performance System Profile is set to Custom, CPU Power

Management is set to Maximum Performance, and Turbo Boost is Enabled.

Enabled or Disabled

OptimizerMode Determines the optimization of the CPU Performance. Auto: Enables when CPU Power Management is

set to Max Performance.

Enabled: Enables regardless of the CPU Power Management setting selected.

Disabled: Turns off the feature.

Auto, Enabled, Disabled

Table 51. Serial communication settings

Attribute Description Supported values Supported vendors

serialComm Select serial communication devices in BIOS. OnNoConRedir

OnConRedirAuto

OnConRedirCom1

OnConRedirCom2, or Off

Dell

extSerialConnector Associates the extSerialConnector to Serial1, Serial2, or the RemoteAccDevice.

Serial1, Serial2, or RemoteAccDevice

serialPortAddress Sets the port address for the serial devices. NOTE: Only Com2 is used for Serial Over LAN

(SOL). To get Console Redirection over SOL, configure the same port address for Console Redirection and Serial Device.

Com1 or Com2

For Dell PowerEdge 14th generation servers, Xr11 and XR12 Dell PowerEdge servers:

Com1

For Dell PowerEdge 15th generation servers: Com2

Dell

Supermicro

failSafeBaud Specifies the failsafe baud rate for console redirection.

If the BIOS fails to determine the baud rate automatically, the specified baud rate is used.

115200

57600

19200

9600

Dell

conTermType Sets the terminal type for a remote console. Vt100Vt220 or Ansi

YAML schema 153

Table 51. Serial communication settings (continued)

Attribute Description Supported values Supported vendors

redirAfterBoot Enables or disables the BIOS console redirection when the operating system is loaded.

Enabled or Disabled

Table 52. Integrated device settings

Attribute Description Supported values Supported vendors

sriovGlobalEnable Enables or disables the BIOS configuration of SR-IOV devices.

Set to Enabled to boot to a virtualization operating system that recognizes SR-IOV devices.

Enabled or Disabled Dell

Supermicro

MmioAbove4Gb Enables or disables the allocation of PCI/PCIe MMIO to address space above 4GB.

MemoryMappedIOH Selects the MMIO base amount. NOTE: The MMIO base default is 56TB. You should not change the default value unless addressing a known issue.

When set to 12TB, the system maps the MMIO base to 12TB. Enable this feature for an OS that requires 44bit PCIe addressing.

When set to 512GB, the system maps the MMIO base to 512GB, and reduce the maximum support for memory to less than 512GB. Enable this option only for the 4 GPU DGMA issue.

12TB

56TB

512GB

Dell

UsbPorts Configure the User Accessible USB Ports. Only Back Ports On disables the front USB ports; All Ports Off disables all front and back USB ports All Ports Off (Dynamic) disables all front and back

USB ports during the POST. You can enable or disable front ports dynamically without resetting the system.

The USB keyboard and mouse still functions in certain USB ports during the boot process, depending on the selection. After the boot process is complete, the USB ports are enabled or disabled as per the setting.

All Ports On

Only Back Ports On

All Ports Off

All Ports Off (Dynamic)

UsbManagedPort iDRAC manages the iDRAC Direct USB port exclusively with no host visibility. When set to Off, iDRAC does not detect any USB devices that are installed in this managed port.

On or Off

EmbNic1Nic2Nic3Nic 4

Enables or disables the OS interface of the embedded NIC1, NIC2, NIC3 and NIC4 controller.

NOTE: If set to Disabled (OS), the embedded NICs may still be available for shared network access by the embedded management controller. This function must be configured using the NIC management utilities that are provided with your system.

Enabled or Disabled (OS)

IoatEngine Enables or disables the I/O Acceleration Technology (I/ OAT). I/OAT are DMA features that are designed to accelerate network traffic and lower CPU utilization.

NOTE: Only enable this feature if the hardware and software support I/OAT.

Enabled or Disabled

EmbVideo Enables or disables the use of the Embedded Video Controller as the primary display.

Enabled or Disabled

154 YAML schema

Table 52. Integrated device settings (continued)

Attribute Description Supported values Supported vendors

When set to Enabled, the Embedded Video Controller is the primary display even if add-in graphics cards are installed.

When set to Disabled, an add-in graphics card is used as the primary display. The BIOS output displays to both the primary add-in video and the embedded video during POST and pre-boot environment. The embedded video is disabled right before the operating system boots.

NOTE: When there are multiple add-in graphics cards that are installed in the system, the first card that is discovered during PCI enumeration is selected as the primary video. You may have to re-arrange the cards in the slots in order to control which card is the primary video controller.

SnoopHldOff Selects the number of cycles PCI I/O can withhold snoop requests, from the CPU, to allow time to complete its own write to LLC.

This setting can help improve performance on workloads where throughput and latency are critical.

256 Cycles

512 Cycles

1K Cycles

2K Cycles

4K Cycles

8K Cycles

16K Cycles

32K Cycles

64K Cycles

128K Cycles

OsWatchdogTimer If the system stops responding, this watchdog timer helps in the recovery of your operating system (OS). When set to Enabled, the OS is allowed to initialize

the timer. When it is set to Disabled, the timer has no effect on

the system.

Enabled or Disabled

PCIRootDeviceUnhid e

If set to Enabled, root ports of all the empty slots are accessible to the BIOS and OS.

Enabled or Disabled

AutoDiscovery Allows BIOS to dynamically scan for PCIe devices rather than relying strictly on system slot definitions. The Platform Default setting strictly follows the system slot definitions when configuring each PCIe slot. The Auto Discovery setting analyzes the installed PCIe cards and determines the correct configuration for each slot. This may include bifurcation of the slot for multiple devices. Manual Control allows the user to override bifurcation settings for each slot.

CAUTION: Improper configuration of PCIe slots can prevent the system from functioning properly.

Platform Default Bifurcation

Auto Discovery of Bifurcation

Manual Bifurcation Control

Slot1 Controls the configuration of PCIe cards that are installed in the specified slot. Slot disablement must be used only when the installed peripheral card is preventing booting into the operating system or causing delays or lockups in system startup.

Enabled

Disabled

Boot Driver Disabled

Slot2

Slot3

YAML schema 155

Table 52. Integrated device settings (continued)

Attribute Description Supported values Supported vendors

When set to Disabled, both the Option ROM and UEFI driver are disabled, the card is not enumerated on the PCI bus, and will not be available to the operating system.

When set to Boot Driver Disabled, the Option ROM and UEFI driver from that slot will not run during POST. As a result, the system will not boot from the card, and its pre-boot services will not be available. However, the card is available to the operating system.

NOTE: This option is not available if the slot contains a Dell PowerEdge RAID card (PERC).

NOTE: Some PCIe device manufacturers implement a main boot driver that can initialize and manage all the similar devices in the system. In this case, to make sure that the Option ROM and UEFI driver do not run, you must select Boot Driver Disabled for all the cards from the same manufacturer (including its integrated device versions such as NDCs).

Table 53. Network settings

Attribute Description Supported values Supported vendors

pxeDev1EnDis Enables or disables the device for PXE Boot selection.

For Supermicro servers, the pxeDev1EnDis attribute enables the IPv4PXESupport.

NOTE: Only pxeDev1EnDis is supported for Supermicro

Enabled or Disabled Dell

Supermicro

pxeDev2EnDis Dell

pxeDev3EnDis

pxeDev4EnDis

pxeDev1Interface Specifies the NIC interface used for each PXE device.

For Supermicro servers, the pxeDev1Interface attribute specifies the NIC interface which is used for PXE boot. For Supermicro servers only, the pxeDev1Interface attribute is supported for both Uefi and Bios mode.

The interface value can be changed only if the corresponding PXE device is enabled.

NOTE: Only pxeDev1Interface is supported for Supermicro

Available NIC Ports. For example:

"NIC.Integrated.1-1 "

Dell

Supermicro

pxeDev2Interface Dell

pxeDev3Interface

pxeDev4Interface

Table 54. SATA Settings

Attribute Description Supported values Supported vendors

EmbSata Determines the mode of the Embedded SATA. ACHI

RAID Mode

Off

Dell

SecurityFreezeLock Sends Security Freeze Lock command to the Embedded SATA drives during POST.

NOTE: This option is only applicable to AHCI mode.

Enabled or Disabled

156 YAML schema

Table 54. SATA Settings (continued)

Attribute Description Supported values Supported vendors

WriteCache Sends Enable or Disable Write Cache command to the Embedded SATA drives during POST.

NOTE: This option is only applicable to AHCI mode.

Enabled or Disabled

Table 55. Redundant OS control settings

Attribute Description Supported values Supported vendors

RedundantOsLocation Specifies the backup device for the Redundant OS Control feature.

When Redundant OS Boot is set to Enabled, the BIOS boots to this device. SD Card Port, Internal USB Port, M.2 cards: If a

device is set as the Redundant OS Location, then the corresponding device setting is set based on the Redundant OS state and not be available to be changed in Integrated Devices.

Embedded SATA: must be set to anything other than Off for SATA ports to show up as optional backup devices.

SATA Port A or NONE Dell

Table 56. Miscellaneous settings

Attribute Description Supported values Suported vendors

Numlock Determines whether the system boots with Num Lock enabled or disabled. This does not apply to 84- key keyboards. When On, the rightmost keys on the keyboard

function like those on a numeric calculator. When Off, they function as cursor-control keys.

On or Off Dell

ErrPrompt Determines whether the BIOS stops and displays a prompt when certain types of errors occur during POST. When Enabled, the BIOS displays the prompt. When Disabled, the BIOS continues through

POST and attempts to boot an operating system.

Enabled or Disabled

ForceInt10 In UEFI Boot Mode, this field determines whether the system BIOS loads the legacy video (INT 10h) option ROM from the video controller.

This may be required in order to install older Operating Systems. Setting this field to Enable may fix the OS installation issue of a blank screen.

This field has no effect when Boot Mode is set to BIOS. This field cannot be set to Enabled when Boot Mode is UEFI and Secure Boot is enabled.

Enabled or Disabled

DellWyseP25BIOSAccess Enables or disables Remote user to access BIOS Setup using the Dell Wyse P25/P45 Portal.

If P25/P45 BIOS Access is turned off, it cannot be turned back on remotely from the P25/P45. Turning this feature off prevents the keyboard and mouse access to Diagnostics, Boot Options, and other Pre- OS functionality.

Enabled or Disabled

YAML schema 157

Table 56. Miscellaneous settings (continued)

Attribute Description Supported values Suported vendors

PowerCycleRequest Specifies how the system reacts when the system transitions to S5 state. When set to None, the transition to S5 is normal. When set to Full Power Cycle, the system will

temporarily be forced into a lower power state, similar to removing and replacing AC.

None or FullPowerCycle

BMC attribute definitions

A short list of BMC attributes are supported for operating system deployments:

rfsIgnoreCertWarning serialRedirectEnable

Table 57. DNS settings

Attribute Description Supported values Supported vendors

DNSFromDHCP Enables or disables DHCP. Enabled or Disabled Dell

nameServers DNS server IP address. You can configure up to two DNS servers.

For Supermicro, you must configure one DNS server only.

For HPE iLO servers, this field is read-only.

For example:

11.11.11.11

Dell

Supermicro

HPE iLO

DNSDomainName DNS Domain name For example:

dell.com

Dell

DNSRacName The name of the server. The default format is: SERVER- .

For example:

SERVER-D2T5MH3

Dell, Supermicro

Table 58. NTP settings

Attribute Description Supported values Supported vendors

protocolEnabled Enables or disables the NTP server on the BMC. NOTE: This configuration overwrites the existing NTP configuration.

True or False Dell

Supermicro

HPE iLO ntpServers NTP serverIPv4 IP address. You can configure up to three

NTP servers. NOTE: For HPE iLO servers, set the protocolEnabled attribute to true to enable the supported NTP

servers. You can configure a maximum of two NTP servers for HPE iLO and Supermicro servers.

For example:

10.10.10.10

Table 59. Connectivity settings

Attribute Description Supported values Supported vendors

topologyLLDP Enables or disables the LLDP topology information. Enabled or Disabled Dell

osBmcPassThroughSt ate

Manages the IMC administrative state.

158 YAML schema

Table 59. Connectivity settings (continued)

Attribute Description Supported values Supported vendors

ipmiLanEnable Enables or disables the BMC IPMI over LAN interface.

vlanEnable Enables or disables the BMC VLAN capabilities.

vlanID Specifies the VLAN ID for the network VLAN configuration.

CAUTION: You can lose BMC access if you change this field. This action impacts network connectivity.

1 to 4094

VirtualConsolePluginT ype

Specifies the virtual console plugin type.

To update this attribute on Supermicro servers, the virtual console needs to be disabled first. The virtual console plugin type cannot be changed when there is an active virtual console session.

NOTE: For Supermicro servers, the supported values are Java or HTML5.

ActiveX

Java

HTML5

eHTML5

Dell, Supermicro

Table 60. Service settings

Attribute Description Supported values Supported vendors

snmpAgentEnable Enables or disables the Simple Network Management Protocol (SNMP) agent on the BMC.

Enabled or Disabled Dell

snmpAgentCommuni tyName

Specifies the SNMP community name to be used for SNMP Agents.

The name can have up to 31 non-blank characters.

For example:

Public

snmpProtocol SNMP protocol. All or SNMPv3

snmpDiscoveryPortN umber

SNMP agent port on the BMC. 1 to 65535; except 22, 80, and 443

timeZone Select the time zone from the drop-down list. The time zone can have up to 32 characters.

For example:

US/Central, Universal, UCT, and so on

Dell

Supermicro

HPE iLO

Table 61. BMC user account settings

Attribute Description Supported values Supported vendors

userName A unique username. NOTE: Special characters cannot be entered in the user name.

For example:

Root

Dell

Supermicro

HPE iLO password Password for the user account. For example:

Root

roleId The group privilege level that is assigned to the BMC user.

For example, user privilege levels for an iDRAC are as follows:

Administrator - Log in to iDRAC, Configure iDRAC, Configure Users, Clear Logs, Control and Configure . System, Access Virtual Console, Access Virtual Media, Test Alerts, and Execute Debug Commands.

iDRAC example:

Administrator

Operator

Read Only

YAML schema 159

Table 61. BMC user account settings (continued)

Attribute Description Supported values Supported vendors

Operator - Log in to iDRAC, Configure iDRAC, Control and Configure System, Access Virtual Console, Access Virtual Media, and Execute Debug Commands.

Read Only - Log in to iDRAC.

None

enabled Enables or disables user privileges based on the role. True or False Dell

resetPassword Indicates whether a password change is required for the user.

Dell

Supermicro

HPE iLO

Table 62. Ignore certificate warning message setting

Attribute Description Supported values

rfsIgnoreCertWarning Ignore certificate warning message. Yes or No

Table 63. Serial redirect setting

Attribute Description Supported values

serialRedirectEnable Enables or disables serial console redirection. Enabled or Disabled

Table 64. Network settings

Attribute Description Supported values Supported vendors

address IP address that is associated with the BMC (not the managed system).

NOTE: Updating the IP address also updates the BMC endpoint.

IP address Dell

HPE iLO

gateway Default network gateway IP address configured for the BMC.

subnetMask TCP/IP subnet mask that is configured for the BMC. It identifies the parts of the IP address that are the Extended Network Prefix and the Host Number.

TCP/IP subnet mask

CAUTION:

Changing any of the network settings results in losing BMC access, which impacts network connectivity.

Boot attribute definitions

Table 65. Boot settings

Attribute Description Supported values Supported vendors

bootOrder Specifies a list of FQDDs and boot sources that represent the boot list to be applied on the next boot.

The system attempts to boot to devices starting with the first item in the boot order. If the boot attempt fails, the system goes to the next item in the boot order until the boot is successful, or no more boot options are found.

Before updating the bootOrder in the Server YAML file, you can view the current bootOrder in the Server status, under the

Examples:

Disk.Bay.22:Enclosure.Internal .0-1:PCIeExtender.Slot.1

NIC.PxeDevice.1-1

Dell

Supermicro

HPE iLO

160 YAML schema

Table 65. Boot settings (continued)

Attribute Description Supported values Supported vendors

boot section. Update the bootOrder in the Spec section to change the order of the boot sources.

NOTE: The bootOrder can be modified on HPE and Supermicro servers when the boot mode is in UEFi or

BIOS mode.

For Supermicro servers, you can provide shortcut keywords to specify the network and hard disk boot options. For example, in BIOS boot mode:

"Hard Disk "Network"

In UEFI boot mode:

"UEFI Hard Disk" "UEFI Network"

HddOrder Specifies a list of hard drives to be applied in order of priority, on the next boot.

You can view the current HddOrder in the Server status, under the boot section, if the current boot mode is in Bios mode. To update the HddOrder, edit the HddOrder field under the Boot settings, in the Spec section of the Server YAML file. You can only modify the HddOrder setting on a server when the bootMode is in Bios mode.

NOTE: For Supermicro servers, you can set one or more of the HddOrder options to Disabled.

Examples:

sSATA P1: INTEL SSDSC2KB480G8 (SATA,Port:1)

sSATA P0: INTEL SSDSC2KB480G8 (SATA,Port:0)

Dell

Supermicro

Hardware profile apply and preview definitions

The following table describes the attribute field definitions used to apply the hardware profile to servers and to preview the server configuration status.

Table 66. Hardware profile apply and preview definitions

Attribute Description Supported values

apply Apply the configuration settings of the hardware profile to the targeted servers.

Servers can be targeted using either selectors and labels or by listing the server names directly in the hardware profile.

true or false

preview Collect status information for the servers that the hardware profile targets. Server status is shown in the status section of the hardware profile when you run bmo describe hardwareprofile -f to describe the hardware profile.

Targeted servers that are in a non-ready state are shown under failedList.

The hardware profile configuration is only applied to the targeted servers when the apply attribute is set to true.

NOTE: You cannot set both the apply and preview attributes to true at

the same time in the hardware profile.

true or false

YAML schema 161

Hardware profile targeting attribute definitions

The following table describes the field definitions for the Hardware profile attributes used to target specific servers for configuration.

Table 67. Hardware profile serverList definitions

Attribute Description Supported values

serverList A list of servers that you want the hardware profile to specifically target for configuration.

Add the serverList attribute to the spec section of the hardware profile, then list the server name and namespace for each server to target. For example:

serverList: - name: server22 namespace: metalweaver - name: server21 namespace: metalweaver - name: server30 namespace: metalweaver

The maximum character limit for server name is 51. The first and last character must be alphanumeric.

NOTE: Hardware profiles that are created using the Bare Metal Orchestrator Web UI already have a default selector called profileName: profile.

You can add custom selectors, but do not modify the default selector.

Alphanumeric characters (a to z, 0 to 9), dash (-), and period (.)

selectors User-defined selectors are added in the spec section of the hardware profile and are used to target specific servers for configuration. You can specify one or multiple selectors and their value. For example:

spec: selectors: hwprofile: hw-config001

The hardware profile settings are applied to servers that have a label with matching values.

The maximum character limit is 63. The first and last character must be alphanumeric.

CAUTION: Do not name the selector profile. This name is reserved

for internal operations.

Alphanumeric (a to z, A to Z, 0 to 9), dash (-), underscore (_), period (.), or can be left empty.

Server provisioning status

The following figure illustrates different provisioning states that the server transitions through:

162 YAML schema

The following table describes the provisioning status of a server:

Table 68. Server provisioning status

Status Description

Ready A server goes into the Ready state after a successful command execution. It also indicates that Bare Metal Orchestrator is ready to run the next command in sequence. For example, if Initialize is complete, the next command CollectingInventory starts. The state changes back to Busy when the command execution is in progress. For more information about the commands that run during server provisioning, see Server command executing status.

Busy Indicates that command execution is in progress.

Failed Indicates a failure in the command execution even after maximum retries. This can happen in several scenarios: There is a configuration mismatch between the specification and the status in server profiles. During retry, the state changes to Busy. However, the command execution starts only after a reconciliation

trigger.

NOTE: The provisioning states described are applicable for servers and switches.

Server command executing status

The command executing status indicates the commands that run during server provisioning in Bare Metal Orchestrator. Use the status to track the progress of a server at a granular level.

The command executing status is useful in the following scenarios:

Day-to-day operational tasks. Diagnosing problems and planning corrective actions.

The following table describes the server command states and are listed in the order in which they are run when onboarding a server.

Table 69. Server command executing states

Server command status Description

Initialize To initialize server settings.

CollectingMetrics To collect metrics.

FactoryReset Resets server to the default factory settings.

CollectingInventory To collect inventory.

CollecctingTelemetryInventory Collects telemetry inventory if telemetry is enabled.

StackDeploy To deploy stacks.

YAML schema 163

Table 69. Server command executing states (continued)

Server command status Description

UpdateBMCIPv4Settings To update server IPv4 settings.

UpdateBMCAttributes To update BMC attributes.

UpdateBMCDNSAttributes To update BMC DNS attributes.

BMCUserOperations To perform BMC user CRUD operations.

RAIDOperations To perform RAID operations.

BossRAIDOperations To perform BOSS RAID operations to create RAID1 type volume.

UpdatingBootSettings To update Boot settings.

UpdatingBIOSAttributes To update BIOS attributes.

UpdatingFirmware To update Firmware.

UpdateNICAttributes To update NIC adapter settings.

UpdatingBMCNTPSettings To update BMC NTP settings.

OSInstall To install ESXi, RHEL, and WR OS.

OSUpgrade To upgrade ESXi

UpdatingLocation Updating the location

Decommission To decommission a server by deleting all the physical drives in the server.

EnablingTelemetry To enable telemetry on servers.

ConfiguringMetrics To configure telemetry metrics.

PowerState To power on or power off a server.

RAID attribute definitions

The following table describes the RAID attributes and their supported values.

Table 70. RAID attribute definitions

Attribute Description Supported values

deleteNonMatchingVol umes

Bare Metal Orchestrator checks to see if the RAID configuration (volume names) mentioned in the .yaml file matches the RAID configuration of the server or not.

If the configuration matches, no changes are made in the server.

If the configuration does not match and the value for deleteNonMatchingVolumes is defined as:

true, the non-matching RAID volumes are deleted.

false, the non-matching RAID volumes are retained but Bare Metal Orchestrator does not monitor the non-matching RAID volumes.

The default value is false.

true or false

raidVolumes List of RAID volumes. Not applicable

name: A unique descriptive name for the RAID volume. This is a mandatory field.

raidType: RAID type for the virtual disks. This is a mandatory field. RAID0

RAID1

164 YAML schema

Table 70. RAID attribute definitions (continued)

Attribute Description Supported values

RAID5

RAID10

minCapacityBytes: The minimum size in bytes that Bare Metal Orchestrator requires to create RAID volumes. This is a mandatory field.

numberofDrives: The minimum number of drives required for RAID configuration. The valid values depend on the selected RAID type.

RAID 0-2

RAID 1-2

RAID 5-3

RAID 10-4

mediaType: The physical disk type present in the system.

The default value is HDD.

Solid-state Drive (SSD) or Hard Disk Drive (HDD)

Raid: Specifies whether to create the Raid Volume with a Software Raid or a Hardware Raid. If the Raid value is empty, any available Raid storage controller is used. Yes: Creates the Raid Volume with a Software Raid.

No: Creates the Raid Volume with a Hardware Raid.

A Software Raid Volume and a Hardware Raid Volume cannot be present on the same server. You must select one or the other.

NOTE: The Raid attribute is supported only for RHEL.

Yes or No

Network adapter attribute definitions

The following table describes the network adapter attributes and their supported values. SR-IOV configuration can be enabled or disabled in the network adapter settings.

Table 71. Network adapter attribute definitions

Attribute Description Supported values Supported vendors

nic Displays a list of the network adapter IDs and their settings.

Not applicable Dell

networkAdapterID Displays the network adapter ID. Not applicable Dell

HPE iLOnetworkAdapterSettings Displays the configuration settings for the network adapter.

Not applicable

Table 72. Nic settings attribute definitions

Attribute Description Supported values Supported servers

virtualizationMode Enter SRIOV to enable the port, which is configured for SR-IOV. Enter NONE to disable the port configured for SR-IOV.

SRIOV or NONE

blnkLeds NIC Interface Blink LEDs NOTE: This is a read-only field and cannot be edited.

Not applicable

numberVFAdvertised NIC Interface PCI Virtual Functions Advertised NOTE: This is a read-only field and cannot be edited.

1 to 64 with increments of 8 XR11

YAML schema 165

Table 72. Nic settings attribute definitions (continued)

Attribute Description Supported values Supported servers

MaxPfMsixVectors NIC Interface Maximum Number of PF MSI-X Vectors

0 to 512 inclusive

autodetectSpeedExclude Mask

NIC Interface Autodetect Speed Exclude Mask NOTE: This is a read-only field and cannot be edited.

0 to 4095 inclusive

adapterErrorRecovery NIC Interface Adapter Error Recovery Enabled or Disabled

hideSetupPrompt NIC Interface Hide Setup Prompt Read only in 14G with value Int19h

XR11

XR12

15G

setupKey NIC Interface Setup Key Stroke Broadcom_SetupKeyCtrlS

Broadcom_SetupKeyCtrlB

XR11

XR12

bannerMessageTimeout NIC Interface Banner Message Timeout 0 to 14 inclusive

Table 73. Network Port attribute definitions

Attribute Description Supported values Supported servers

rDMANICModeOnPort NIC interface and RDMA Mode Enabled or Disabled

MsixVectorsPerVf NIC Interface Number of MSI-X Vectors per VF

0 to 128 inclusive

forwardErrorCorrection NIC Interface Link FEC Broadcom_ForwardErrorCorrectionCL74

Broadcom_ForwardErrorCorrectionCL91

Broadcom_ForwardErrorCorrectionCL74CL 91Both

Disabled

operationalLnkSpeed NIC Interface Operational Link Speed AutoNeg

10Gbps

25Gbps

dCBX NIC Interface DCBX Mode Disabled

Enabled_IEEE

Enabled_CEE

Enabled_Both_IEEE_CEE

aNProtocol NIC Interface Auto-negotiation Protocol Broadcom_ANProtocolIEEEandBAM

Broadcom_ANProtocolIEEEandConsortium

Broadcom_ANProtocolIEEE8023by

Broadcom_ANProtocolBAMOnly

Broadcom_ANProtocolConsortiumOnly

mediaAutoDetect NIC Interface Media Auto Detect Enabled or Disabled

defaultEVBMode NIC Interface Default eVB Mode VEB

166 YAML schema

Table 73. Network Port attribute definitions (continued)

Attribute Description Supported values Supported servers

VEPA

None

portLinkTraining NIC Interface Port Link Training Enabled or Disabled XR11

bootOptionROM NIC Interface Option ROM Enabled or Disabled XR11

XR12

15G

legacyBootProto NIC Interface Legacy Boot Protocol PXE, NONE All

bootStrapType NIC Interface Boot Strap Type NOTE: Read-only in 14G with value Int19h

AutoDetect

BBS

Int18h

Int19h

wakeOnLan NIC Interface Wake On Lan Enabled or Disabled

vLanMode NIC Interface Virtual Lan Mode Enabled or Disabled

bootRetryCnt NIC Interface Boot Retry Count NoRetry

1Retry through to 6Retries

IndefiniteRetries

permitTotalPortShutdo wn

NIC Interface Permit Total Port Shutdown

Enabled or Disabled

Metric attribute definitions

The following table describes the metric attributes that are collected for inclusion in the metrics report. The attributes selected determine which statistics are collected for the metrics report.

Table 74. Metric collection attribute definitions

Attribute Description Supported vendors

pollFrequencyMins Statistics are collected every 15 minutes when metrics collection is configured for Bare Metal Orchestrator. Minimum value is 15.

Dell

HPE iLO CPUUtilization Bare Metal Orchestrator collects the CPU utilization statistics for all servers as a

percentage.

MemoryUtilization Bare Metal Orchestrator collects system memory usage statistics as a percentage. Not all platforms support collection of this data.

PowerConsumption Bare Metal Orchestrator collects the power consumption statistics for all CPUs, DIMMs, system input, and system output as watts.

Temperature Bare Metal Orchestrator collects device temperature sensor metrics in degrees Celsius.

Reinitialize attribute definition

The following table describes the reInitialize attribute and supported values.

YAML schema 167

Table 75. Reinitialize attribute definition

Attribute Description Supported values

reInitialize Bare Metal Orchestrator reinitializes and reinstates the server (or servers).

When a server is not in a failed state, Bare Metal Orchestrator does the following:

1. Reruns inventory against the server. 2. Reconciles the server. 3. Reapplies any configuration profile that targets the server and reinstates

the server.

For a server that is in the failed state, Bare Metal Orchestrator takes the server out of the failed state before reinitializing the server.

When set to "false", no action is taken.

The reInitialize attribute is automatically removed from the YAML file after it has run.

true or false

Server decommissioning field definitions

The following table contains definition and supported values for fields specific to baseline profiles used to decommission a server.

Table 76. Server decommissioning field definitions

Field Description Supported values

selectors A default baseline profile selector called profileName: profile is used to target specific servers for decommission.

The baseline profile settings are applied to servers that have a label with the matching value.

For example:

selectors: profileName: profile

the server label must be:

labels: profileName: profile

Multiple, user-defined selectors are supported. You can add them in the spec section of the baseline profile to help target specific servers. However, don't modify the default selector.

Alphanumeric characters (a to z, 0 to 9), dash (-), and period (.)

SecureEraseDrives Erases all Secure Erase or cryptographic erasure capable disks. This field applies to physical disks including disks used in RAID volumes.

CAUTION: All information is completely and permanently erased.

NOTE: SD card erasure is not supported.

true or false

iDRAC factory default setting field definitions

The following table contains definition and supported values for fields specific to reset certain iDRAC system components to factory default.

NOTE:

168 YAML schema

After the factory reset, wait at least five minutes before you onboard a server.

Table 77. iDRAC factory default setting field definitions

Field Description Supported values Supported vendors

factoryResetBMC Reset BMC attributes to factory defaults. If set to true, resets to the value specified in bmcResetType.

true or false Dell

Supermicro

bmcResetType Defines the type of BMC settings reset. Supported reset types are:

Default: Discard all the settings, but preserve user and network settings.

ResetAllWithRootDefaults: Discard all the settings, and reset the default username to root and password to shipping value.

All: Discard all settings and reset to default credentials.

Default

ResetAllWithRootDefaults

All

factoryResetBIOS If set to true, resets BIOS attributes to factory default. true or false

factoryResetStora ge

If set to true, securely erases server disks. true or false Dell

Server spec metadata field definitions

The following table describes the server spec metadata fields and their supported values.

Table 78. Server spec metadata field definitions

Field Description Supported values

metadata id: The Common Language Equipment Identifier (CLEI) code. For example:

SNPWBBC7AA

Tags: Define text strings that are used for tagging and grouping network devices based on attributes such as capability, and other defined parameters.

NOTE: The tags field is optional.

For example:

cpu

memory

Node field definitions

The following table contains definitions and supported values for the fields in the node.

Table 79. Node field definitions

Field Description

Name The name of the node. For the Global Controller node, the default node name is bmo-manager-1. For remote worker nodes, the node name is user configurable.

For example:

worker1, worker2, and so forth.

On-boarded site The name of the site created on the node. For the Global Controller node, the default site name is gc. For remote worker nodes, the site name is user configurable.

For example:

austin, miami, and so forth.

"--" indicates no site is created on the node.

YAML schema 169

Table 79. Node field definitions (continued)

Field Description

Age The length of time since the node object was created.

For example: 10d

Internal-IP The IP address of the node.

Telemetry field definitions

This table contains definitions for the fields in the server telemetry and profile telemetry YAML files.

For more information about telemetry, telemetry metric reports, and attributes (fields), see Telemetry streaming basics and Telemetry metric report definitions.

Table 80. Server and profile telemetry field definitions

Field Description Supported values

Rsys Log: Remote syslog implements the basic syslog protocol, and extends it with content-based filtering, rich filtering capabilities, and flexible configuration options.

rsyslogServer1 Remote syslog server 1 address IPv4, IPV6, or FQDN IP address

rsyslogServer1Port Remote syslog server 1 port Port number

rsyslogServer2 Remote syslog server 2 address IPv4, IPV6, or FQDN IP address

rsyslogServer2Port Remote syslog server 2 port Port number

Supported telemetry reports:

AggregationMetrics Contains base metric values for power, temperature, and CUPS (CPU, Memory, IO, System).

Not applicable

CPUMemMetrics Contains CPU Memory metrics

CPURegisters On Intel platform the report represents the MSR registers and on AMD platform the report represents the MCA registers. The CPU Register dump is platform specific.

FCPortStatistics Contains Fibre Channel Port statistics

FCSensor Contains FC temperature reading

FPGASensor Contains Field Programmable Gate Arrays (FPGA) temperature reading.

FanSensor Contains RPM reading

GPUMetrics Conatins Graphics Processing Unit Health metrics

GPUStatistics Contains Graphics Processing Unit Frame Buffer and Graphic Device (GR) memory ECC(Error-correcting code) statistics data.

MemorySensor Contains memory temperature reading

NICSensor Conatins Network Card temperature reading

NICStatistics Contains NIC Port and Partition Statistics

NVMeSMARTData Contains NVMe SMART Health record

PSUMetrics Contains power supply metrics

PowerMetrics Contains power consumption for all CPUs, DIMMs, System Input and System Output.

PowerStatistics Contains system power consumption statistics

170 YAML schema

Table 80. Server and profile telemetry field definitions (continued)

Field Description Supported values

Sensor Contains all IPMI reading

SerialLog SerialLog Report (Server serial logs)

StorageDiskSMARTData Contains SSSD SMART information

StorageSensor Contains temperature information for the storage internal drives

SystemUsage Contains system usage in percentage. This report is platform- dependent, and the data may not be available on all platforms.

ThermalMetrics Contains thermal metrics

ThermalSensor Contains temperature reading

Telemetry report attributes:

metricReportState Enables metric report definition Enabled or disabled

metricReportType Specifies the type of metric report Periodic

onChange

onRequest

reportActions Specifies what occurs when a report is generated as per the metricReportType.

Example:

LogToMetricReportsColle ction

RedfishEvent

reportUpdates Specifies what to do with subsequent metric reports when a metric report exists.

AppendStopsWhenFull

AppendWrapsWhenFull

NewReport

Overwrite

suppressRepeatedMetricValue Suppresses the repeated metric value Enabled or disabled

metricReportHeartbeatInterval Periodically forces a report that contains at least one value for every currently valid metric.

This property is a Redfish duration and should always be greater than or equal to the recurrence Interval.

Example:

PT0H0M0S

recurrenceInterval Specifies a Redfish duration string. This property is only valid for Periodic reports.

Example:

PT0H5M0S

reportTimeSpan Specifies the duration of the report Example:

PT0H5M0S

Switch field definitions

The following sections describe switch fields in YAML files that are required for various operations: Switch operating system field definitions Switch connectivity field definitions SDNController field definitions Cisco switch field definitions Switch port configuration field definitions Switch common field definitions

YAML schema 171

Switch status fields

A sample switch YAML file is available at Sample switch YAML file.

For information about the switch command executing status attribute in the Bare Metal Orchestrator CLI, see Switch command executing status.

Switch operating system field definitions

This table contains definitions and supported values for the following fields in the switch YAML file.

Table 81. Switch operating system field definitions

Field Description Supported values

operatingsystemname The name of the operating system media. This name must match the metadata name value in the media object.

Example:

nosmedia

overwriteInstallation Performs an operating system upgrade on a switch. True or False

Switch connectivity field definitions

This table contains definitions and supported values for the following fields in the switch YAML file.

Table 82. Switch connectivity field definitions

Field Description

ONIE

ipaddress IP address of the switch in ONIE mode

username ONIE username

password ONIE password is optional. Set it to None.

NOS

ipaddress IP address of the switch in NOS mode

username NOS username

password NOS password

SDNController field definitions

This table contains definitions and supported values for attributes in the SDNController YAML file.

These attributes are required to onboard a Cisco switch in Bare Metal Orchestrator.

Table 83. SDNController field definitions

Field Description Supported values

name Name which describes the SDNController object. Example:

nso3

ipaddress The NSO IP address. IP address

username The NSO username. NSO username

password The NSO password. NSO password

172 YAML schema

Cisco switch field definitions

This table contains definitions and supported values for attributes in the switch YAML file.

These attributes are required to onboard a Cisco switch in Bare Metal Orchestrator.

Table 84. Cisco switch field definitions

Field Description Supported values

devicename The name of the Cisco switch being onboarded. Example:

cisco-nexus

mgmtipaddress The IP address of the management interface that connects to the NSO instance.

IP address

sdncontroller The name of the sdncontroller instance that is registered with Bare Metal Orchestrator.

Example:

nso3

nedid ID of a Network element driver deployed in an NSO instance to connect to the switch.

Example:

cisco-nx-cli-5.22:cisco-nx- cli-5.22

authgroup Contains credential information that is required to connect to a remote device such as a Cisco switch.

Example:

myauthgroup

Switch port configuration field definitions

This table contains definitions and supported values for attributes in the switchportconfig YAML file.

These attributes are required to configure Layer 2 VLAN, Layer 3 VLAN, and Ethernet interface settings on a Cisco switch.

Table 85. Switch port configuration field definitions

Field Description Supported values

L2VlanList

vlanID Specifies the VLAN ID. Example: 999

shutdown Disables Layer 2 switching of the VLAN on the switch. True or False

L3VlanList

mtu Specifies the largest data packet in maximum transmission unit (MTU) that a network connected device accepts.

Example: 9216

ipaddress VLAN IP address . IP address

redirects Enables redirecting. If the attribute is enabled, it redirects to an interface configured for the switch.

True or False

interfaceConfig

name Name of the Ethernet interface. Example: 2/10

switchport Applies switch port configuration. True or False

mode Specifies the port mode. Example: Trunk

trunkVlan Specifies the VLAN ID for the port when the switch port mode is trunk. Example: 149

accessVlan Specifies the VLAN ID for the port when the switch port mode is access. Example: 109

YAML schema 173

Switch common field definitions

The following table contains the definition and supported values for some of the common fields in the switch YAML file.

Table 86. Switch field definitions

Field Description Supported values

systemmode Mode in which the switch is onboarded. ONIE

NOS

NSO

mgmtipaddress IP address that is assigned to the network switch management interface.

IP address

username Username to log in to the network switch management interface. Username

password Password to log in to the network switch management interface. Password

reInitialize Reinitializes a switch on recovery from a failure. True or False

enableRestConf Enables restconf in a switch. True or False

model Model of the switch. PowerSwitch Z9264F-ON

vendor Name of the switch manufacturer. Dell

Switch status fields

The status section in the switch YAML file displays read-only fields. Some of the fields are described below:

Table 87. Switch status fields

Field Description

InitializationCompleted Displays if the switch initialization has been completed.

OnieInventoryCompleted Displays if the ONIE inventory details have been collected.

NosInventoryCompleted Displays if the NOS inventory details have been collected.

Inventorydata Displays inventory details that are collected.

Nosinventorydata Displays the NOS inventory details that are collected for a switch.

Onieinventorydata Displays the ONIE inventory details that are collected for a switch.

Default boot Displays the default boot mode of the switch.

ONIE mode Displays the IP address and credentials of the switch in ONIE mode.

Operatingsystemname Displays the operating system name of the switch.

State Displays the current state of the switch.

Switch command executing status

The command executing status indicates various operations that are performed on a switch in Bare Metal Orchestrator. Use the status to track the progress of a switch at a granular level.

The following table provides information about the switch command executing states.

Table 88. Switch command executing states

Switch command status Description

CollectOnieInventory To collect ONIE inventory details.

174 YAML schema

Table 88. Switch command executing states (continued)

Switch command status Description

CollectNosInventory To collect NOS inventory details.

Initialize To initialize Dell switch settings.

OsInstall To install Dell OS10 operating system on a Dell switch.

OsUpgrade To upgrade Dell OS10 operating system on a Dell switch.

UpdateRestConf To enable or disable restconf service on a switch.

UpdateFirmware To update Firmware on a Dell switch.

InitializeNso To initialize Cisco switch settings.

AddSDNSwitch To onboard a Cisco switch on NSO.

AddSwitchPortConfig To add port configuration details for a Cisco switch.

Media field definitions

The following table contains definitions and supported values for media fields.

Table 89. Media field definitions

Field Description Supported values

osfilename Name of the ISO or BIN file that is uploaded to Bare Metal Orchestrator.

Example:

VMware-VMvisor- Installer-6.7.0.update03-14320 388.x86_64.iso"

type Specifies the type of managed device.

To install an operating system on a server, enter: server. For other managed devices, enter network.

server

switch

network

vendor Optional user-defined name identifying the vendor of the ISO or BIN image.

For ESXi, a generic ISO image vendor is labeled vmware. If it is a Dell customized image, label the vendor as dell.

Examples:

dell

opensuse

redhat

vmware

windriver

osname Specifies the name of the ISO. The operating system name and the ISO file that is referenced in osfilename must match.

esxi

rhel

wr

suse

osversion Optional version number of the operating system. Version must take the form X.Y.Z, where X is the major version, Y is the minor version, and Z is the patch version.

Example: 6.7u3

externalIPAddr Optionally provide the external IP address of the VM that is running Bare Metal Orchestrator, which is the location of the OVA file. If the worker node for the site has an IP address that is not directly accessible from the BMC, enter the external IP address of the Bare Metal Orchestrator VM here.

Example: 10.100.1.0

YAML schema 175

Driver media field definitions

The following table contains definitions and supported values for the driver media fields.

Table 90. Driver media field definitions

Field Description

filePath For servers, the path to the device driver .zip file in the web server. The file name must be included.

Supported values:

For example, http:// :81/data/driver/Intel- icen_1.7.3.0-1OEM.670.0.0.8169922-18990249.zip.

where is the private IP from which the PXE InBand VLAN is configured. The device drivers are available on HTTP: Port 81 for the Bare Metal Orchestrator's web server.

Type The driver category.

version The driver version.

User field definitions

The following table details the definitions and supported values for the user profile.

Table 91. User field definitions

Field Description Supported values

name Name of the user. Alphanumeric characters are supported. Example: JohnSmith

email Email address of the user. Example: user@email.com

country Country Name (2 letter code) Example: US

city Locality Name (for example, city) Example: Brooklyn

organization Organization Name (for example, company) Example: Brooklyn Company

orgUnit Organizational Unit Name (for example, section) Example: Technology Division

province State or Province Name (full name) Example: New York

roles User role. NOTE:

This field is required only for creating users with a Global Admin or Global Reader role.

global-admin or global-reader

Firmware media field definitions

The following table contains definitions and supported values for the firmware media fields.

Table 92. Firmware media field definitions

Field Description

vendor The name of the vendor.

model The model name of the server or the switch.

firmwareName The name to identify the firmware.

category The category of the firmware.

Supported values:

176 YAML schema

Table 92. Firmware media field definitions (continued)

Field Description

BIOS, BMC, Network, CPLD, Chipset. Diagnostics, OSDriverPack, EnterpriseSolutions, FiberChannel, Memory, Power, SASDrive, SASNonRaid, SASRaid, SecureSystemManagement, SerialATA, SolidStateStorage, SystemManagement, DeviceFirmware, IdentityModule, and Other.

version The version of the firmware to be updated to.

imagefilename For servers, the path to the firmware image in the web server.

For example:

" iDRAC-with-Lifecycle-Controller_Firmware_7CH5T_WN64_5.00.10.00_A00.EXE"

For switches, the firmware image in the web server. For example, firmware.bin.

externalIPAddr Optional. Provide the external IP address of the VM that is running Bare Metal Orchestrator, which is the location of the OVA. If the worker node for the site has an IP address that is not directly accessible from the BMC, enter the external IP address of the Bare Metal Orchestrator VM here.

Tenant field definitions

The following table contains definitions and supported values for the tenant fields.

Table 93. Tenant field definitions

Field Description Supported values

tenantAdmin The name of the user who is a tenant admin. For example: Ryan

requestResource The servers or switches that you want to associate with the given tenant. Bare Metal Orchestrator transfers the listed servers or switches from the default tenant to the given tenant.

For example:

server1

server2

switch1

releaseResource The servers or switches that you want to disassociate from the given tenant.

Bare Metal Orchestrator transfers the servers or switches from the given tenant to the default tenant.

For example:

server1

server2

switch1

reInitialize A value of "true" reinitializes and updates the status of the tenant.

When set to "false", no action is taken.

true or false

Event field definitions

The following table contains definitions and supported values for the event fields.

Table 94. Event field definitions

Field Description Supported values

Http sink attributes

httpSinkUrl The end point URL of http sink connector. For example: http:// httpsink.metalweaver.svc.cluster.local:5556/ events

Kafka attributes

YAML schema 177

Table 94. Event field definitions (continued)

Field Description Supported values

KafkaBrokers The file-based URL of Kafka server. For example: my-cluster-kafka-external-bootstrap.my- kafkaproject.svc.cluster.local:9094"

kafkatopic Name of the Kafka topic. For example: my-topic

async Specify to send events from Kafka Producer to the Kafka Server synchronously or asynchronously.

If the field is set to false, event messages are sent synchronously, which means a new message is sent only after completing the previous message or transaction.

If the field is set to true, event messages are sent asynchronously without any interruption or stoppage of their transmission to the Kafka server.

true or false

Common attributes

unsubscribe Subscribe or unsubscribe the event generated for a resource.

true or false

subscribedEventTypes Specify the type of the event to be generated.

Normal: An event that is just informational and that indicates a state change of a resource.

Warning: An event that indicates a significant problem. For example, if a server fails while on- boarding, a warning event is logged.

Normal or Warning

subscribedObjects Specifies the component for which events are subscribed.

Server

HardwareProfile

Tenant

Site

Stack field definitions

This section provides the stack deployment field definitions and supported values for VMWare TCP, TKG, and Wind River Cloud Platform deployments.

The following table lists the configurable VMWare TCP operating system deployment settings.

Table 95. Stack field definitions for VMWare TCP

Field Description Example supported values

stackType The type of cloud stack to be deployed. VMWare_TCP

stackVersion The version number of the stack to be deployed. 2.0

stackInstallerConfig Top-level field for the stack installer. Not applicable

installerIp IP address of the installer server. 1.2.3.4

installerUserName User name for the installer server.

installerPassword Password for the installer server.

configFile Name of the installer configuration file. InstallerConfig.json

stackConfig Name of the TCP configuration file. TCPConfig.json

178 YAML schema

Table 95. Stack field definitions for VMWare TCP (continued)

Field Description Example supported values

stackHostAdditionConfig Name of the add hosts configuration file. AddHosts.json

VlanId Specifies which VLAN the server is on. 20

Domain Specifies which domain the server is on. dellnfv.com

dnsList Specifies which DNS list the server is on. 1.2.3.0

serverForDeployment Top-level field for the server used to deploy the stack. Not applicable

ip IP address of the server used to deploy the stack. 1.2.3.4

username User name for the server used to deploy the stack.

password Password for the server used to deploy the stack.

address The ESXi host name. esxi10

name The Bare Metal Orchestrator server name. server1

reInitialize Flag that restarts the stack deployment from a failure point.

When set to "false", no action is taken.

true or false

The following table lists the configurable TKG template settings.

Table 96. Stack field definitions for TKG template

Field Description Example supported values

name The name of the TKG template. management-template, shared-service-template, workload-template

clusterType The type of the cluster to be deployed. MANAGEMENT, SHAREDSERVICE, WORKLOAD

description Brief description about the template.

templateJson The name of the TKG template in .json format. The name must match the used for creating the configuration files.

tkg-management- template.json, tkg- sharedservice-template.json, tkg-workload-template.json

The following table lists the configurable TKG cluster deployment settings.

Table 97. Stack field definitions for TKG cluster deployment

Field Description Example supported values

name Unique name of the cluster. management-cluster, shared- service-cluster, workload- cluster

clusterType The type of the cluster to be deployed. MANAGEMENT, SHAREDSERVICE, WORKLOAD

templateName The template that is used to deploy the cluster. management-template, shared-service-template, workload-template

targetDomainName The name of the domain where the stack is deployed. ndc or rdc

clusterPassword The password of the TKG cluster. The cluster password must: 1. not contain any space. 2. contain at least one digit (0-9).

YAML schema 179

Table 97. Stack field definitions for TKG cluster deployment (continued)

Field Description Example supported values

3. contain minimum eight characters and maximum 20 characters.

4. contain at least one lower-case letter (a-z). 5. contain at least one upper-case letter (A-Z). 6. contain at least one special character (@#$%^&+=!*).

endpointIP Unique end point IP address of the cluster. The IP must be a part of the network subnet.

100.100.10.100

managementClusterName The name of the management cluster. Required only if the clusterType is SHAREDSERVICE or WORKLOAD.

management-cluster

The following table lists the configurable Wind River Cloud Platform stack deployment settings.

Table 98. Stack field definitions for Wind River Cloud Platform deployment

Field Description Example supported values

stackType The type of cloud stack to be deployed. Windriver

stackVersion The version number of the stack to be deployed. 21.05

stackInstallerConfig Top-level field for the stack installer. Not applicable

installerIp IP address of each cloud central and sub-cloud edge server. 1.2.3.4

installerUserName User name for the cloud central server. i.e. the controller-0 server.

installerPassword Password for the cloud central server. i.e. the controller-0 server.

configFile Name of the installer configuration file. installer_config.yaml

domainName Specifies which domain the cloud central server is on. centralcloud

stackConfig Name of the Wind River Cloud Platform stack deployment configuration file.

deployment_config.yaml

dnsList Specifies which DNS list the server is on. 1.2.3.0

serverForDeployment Top-level field for the server used to deploy the components of the Central Cloud.

Not applicable

name The Bare Metal Orchestrator server name.

Specify the name, domain, and type for the mandatory controller-0 and controller-1 components.

To add optional worker components, specify the name, domain, and type for each worker you are deploying.

controller-0

controller-1

worker-0

domain Specifies which domain the cloud cluster component is on. For example:

centralcloud

type Specifies the type of cloud cluster component you are deploying on the Central Cloud: controller-0, controller 1-n, or worker 0-n.

controller-0

controller 1

worker 0

reInitialize This must be set to false. Reinitializing the Wind River Cloud Platform stack is not supported.

false

180 YAML schema

YAML status fields The status section in the server.yaml file displays a number of read-only fields. Some of the fields are described below:

Table 99. YAML status fields

Field Description

Processor Displays processor inventory.

Memory Displays memory module inventory.

Storage Displays storage controllers, disks, and volumes inventory.

SDCard Displays SD memory cards inventory.

System Displays the system inventory.

NIC Displays network adapter inventory.

BIOS Displays a short list of the most common BIOS attributes.

CompleteBIOS Displays all possible BIOS attributes.

Firmware Displays firmware inventory.

PCIeDevice Displays PCIeDevice inventory.

Power Displays power supply inventory.

BMC Displays a short list of the most common BMC attributes.

CompleteBMC Displays all possible BMC attributes.

Boot Displays boot order related inventory.

EthernetInterface Displays ethernet interface related inventory.

FirmwareNames Displays the firmware media names.

Metric Displays metric inventory.

Decommission Displays the decommission status.

SerialNumber Displays the serial number of the system.

PartNumber Displays the manufacturer-defined part number for the system.

Model Displays the model number of the system.

AssetTag Displays the asset tag of the system.

Manufacturer Displays the manufacturer details of the system.

PowerState Displays the power state of the server.

Status Displays the server statuscritical, warning, or ready.

State Displays the current state of the server.

UUID Displays the Universal Unique Identifier (UUID) number of the system.

SKU Displays the Stock Keeping Unit (SKU) for the system.

Location Displays the location information of the server.

OSDetails Displays the details of the operating system, including the IP address, hostname, and driver details.

YAML schema 181

Stack status fields The status section in the displays a number of read-only fields. Some of the fields are described below:

Table 100. Stack status fields

Field Description

tkgClusterRes Displays the TKG cluster details. The status field indicates the deployment status of the cluster.

tkgTemplateRes Displays the TKG template details. The value for tkgID is auto-generated upon successful TKG template creation.

182 YAML schema

Tenant profile YAML file sample

Topics:

Sample tenant YAML file

Sample tenant YAML file The following is an example tenant.yaml file.

apiVersion: mw.dell.com/v1 kind: Tenant metadata: name: tenant-sample spec: tenantAdmin: - Ryan requestResource: servers: - server1 - server2 switches: - switch1 releaseResource: servers: - server3 reInitialize: false

B

Tenant profile YAML file sample 183

Switch YAML file sample

Topics:

Sample switch YAML file

Sample switch YAML file Sample switch YAML files for Dell switches.

The following is an example to onboard a switch in ONIE mode:

apiVersion: mw.dell.com/v1 kind: Switch metadata: name: labels: site: spec: vendor: Dell EMC model: onie: ipaddress: mac: username: password:

The following is an example to onboard a switch in NOS mode:

apiVersion: mw.dell.com/v1 kind: Switch metadata: name: labels: site: spec: vendor: Dell EMC model: username: password: mgmtipaddress: mac: mode: nos

C

184 Switch YAML file sample

Server and hardware profile YAML file samples

Topics:

Server and hardware profile YAML file samples Sample server YAML file Sample hardware profile YAML file Sample operating system deployment YAML files - ESXi Sample operating system deployment YAML files - openSUSE Sample operating system deployment YAML files - Red Hat Enterprise Linux Sample operating system YAML files - Wind River Cloud Platform Sample baseline profile YAML file

Server and hardware profile YAML file samples

Sample YAML files in this appendix show the common server and hardware profile objects and attributes. Operating system attributes are shown in separate sample YAML files. For a complete list of the configurable attribute values, see Server and hardware profile field definitions.

The following sample YAML files are provided:

Sample server YAML file Sample hardware profile YAML file Sample operating system deployment YAML files - ESXi Sample operating system deployment YAML files - openSUSE Sample operating system deployment YAML files - Red Hat Enterprise Linux Sample operating system YAML files - Wind River Cloud Platform

For an example DHCP YAML file, see Sample DHCP configuration YAML file.

Sample server YAML file The following is an example .yaml file.

This example YAML file consolidates most of the available configurable attributes into one file and includes the optional profile label. For an example of operating system related attributes that you can set when installing an operating system on a server, see the sample YAML file for the specific operating system.

NOTE: This file is only for reference. You must use the sample files that are provided with Bare Metal Orchestrator

deployment.

apiVersion: mw.dell.com/v1 kind: Server metadata: name: server-tag labels: site: durham spec: metadata: tags: name: server_tagname cpu: sample_cpu memory: sample_size

D

Server and hardware profile YAML file samples 185

bmcEndPoint: "https://" userName: root password: powerstate: "On" raid: deleteNonMatchingVolumes: true raidVolumes: - name: TestVolume3 raidType: RAID1 minCapacityBytes: 100000000000 numberOfDrives: 2 mediaType: HDD swRaid: "No" boot: bootOrder: - "USB Hard Disk" - "USB CD/DVD" bios: attributes: logicalProc: Enabled procVirtualization: Enabled setBootOrderFqdd1: "*.*.*" setBootOrderFqdd2: "NIC.*.*" setBootOrderFqdd3: "Optical.*.*" setBootOrderFqdd4: "Floppy.*.*" procAdjCacheLine: Enabled procHwPrefetcher: Enabled procSwPrefetcher: Enabled dcuStreamerPrefetcher: Enabled dcuIpPrefetcher: Enabled #subNumaCluster: Enabled upiPrefetch: Enabled #dynamicCoreAllocation: Enabled procX2Apic: Enabled procCores: All memTest: Enabled memOpMode: OptimizerMode procPwrPerf: MaxPerf memFrequency: MaxPerf procTurboMode: Enabled procC1E: Enabled #nodeInterleave: Disabled corrEccSmi: Enabled oppSrefEn: Enabled #monitorMwait: Enabled cpuInterconnectBusLinkPower: Enabled pcieAspmL1: Enabled uncoreFrequency: DynamicUFS energyPerformanceBias: MaxPower proc1TurboCoreNum: All proc2TurboCoreNum: All memRefreshRate: 1x memPatrolScrub: Extended procCStates: Enabled writeDataCrc: Enabled sriovGlobalEnable: Enabled serialPortAddress: Com1 conTermType: Vt100Vt220 extSerialConnector: Serial1 redirAfterBoot: Disabled serialComm: OnConRedirCom1 failSafeBaud : 19200< nic: - networkAdapterId: attributes: virtualizationMode: SRIOV bannerMessageTimeout: 7 setupKey: Broadcom_SetupKeyCtrlB hideSetupPrompt: Disabled adapterErrorRecovery: Enabled maxPfMsixVectors: 256 nicPorts: - id:

186 Server and hardware profile YAML file samples

attributes: forwardErrorCorrection: Disabled portLinkTraining: Disabled legacyBootProto: PXE rDMANICModeOnPort: Enabled msixVectorsPerVf: 128 operationalLnkSpeed: "10Gbps" dCBX: Disabled aNProtocol: Broadcom_ANProtocolIEEEandBAM mediaAutoDetect: Disabled defaultEVBMode: VEB bootOptionROM: Disabled bootStrapType: AutoDetect wakeOnLan: Disabled vLanMode: Disabled bootRetryCnt: NoRetry permitTotalPortShutdown: Disabled

Sample hardware profile YAML file The following is an example .yaml file.

This example YAML file consolidates most of the available configurable attributes into one file and includes the optional profile selector. For an example of operating system related attributes that you can set when installing an operating system on a server, see the sample YAML file for the specific operating system.

NOTE: This file is only for reference. You must use the sample files provided with Bare Metal Orchestrator deployment.

apiVersion: mw.dell.com/v1 kind: HardwareProfile metadata: name: hardwareprofile-dell labels: site: gc spec: # Add fields here apply: false preview: true server: bios: attributes: logicalProc: Enabled procVirtualization: Enabled setBootOrderFqdd1: "*.*.*" setBootOrderFqdd2: "NIC.*.*" setBootOrderFqdd3: "Optical.*.*" setBootOrderFqdd4: "Floppy.*.*" procAdjCacheLine: Enabled procHwPrefetcher: Enabled procSwPrefetcher: Enabled dcuStreamerPrefetcher: Enabled dcuIpPrefetcher: Enabled #subNumaCluster: Enabled upiPrefetch: Enabled #dynamicCoreAllocation: Enabled procX2Apic: Enabled procCores: All memTest: Enabled memOpMode: OptimizerMode procPwrPerf: MaxPerf memFrequency: MaxPerf procTurboMode: Enabled procC1E: Enabled #nodeInterleave: Enabled corrEccSmi: Enabled oppSrefEn: Enabled #monitorMwait: Enabled cpuInterconnectBusLinkPower: Enabled pcieAspmL1: Enabled

Server and hardware profile YAML file samples 187

uncoreFrequency: DynamicUFS energyPerformanceBias: MaxPower proc1TurboCoreNum: All proc2TurboCoreNum: All memRefreshRate: 1x memPatrolScrub: Extended procCStates: Enabled writeDataCrc: Enabled sriovGlobalEnable: Enabled serialPortAddress: Com1 conTermType: Vt100Vt220 extSerialConnector: Serial1 redirAfterBoot: Disabled serialComm: OnConRedirCom1 failSafeBaud : 19200 nic: - networkAdapterId: attributes: virtualizationMode: SRIOV bannerMessageTimeout: 7 setupKey: Broadcom_SetupKeyCtrlB hideSetupPrompt: Disabled adapterErrorRecovery: Enabled maxPfMsixVectors: 256 nicPorts: - id: attributes: forwardErrorCorrection: Disabled portLinkTraining: Disabled legacyBootProto: PXE rDMANICModeOnPort: Enabled msixVectorsPerVf: 128 operationalLnkSpeed: "10Gbps" dCBX: Disabled aNProtocol: Broadcom_ANProtocolIEEEandBAM mediaAutoDetect: Disabled defaultEVBMode: VEB bootOptionROM: Disabled bootStrapType: AutoDetect wakeOnLan: Disabled vLanMode: Disabled bootRetryCnt: NoRetry permitTotalPortShutdown: Disabled selectors: model: dell

Sample operating system deployment YAML files - ESXi You can deploy the ESXi operating system on a server using a server YAML file or a hardware profile.

The following sample YAML files show the attributes and values for ESXi deployment on Dell PowerEdge R650 and R750 servers.

NOTE:

These files are only for reference. You must use the sample files provided with Bare Metal Orchestrator deployment.

The comments in the YAML file start with a hash character (#) and is followed by a text or the name of the attribute.

You can remove # to un-comment and edit the attribute value.

Replace what appears between italicized, bold chevrons (< >) with user-supplied content. For example:

password:

Sample server YAML file for ESXi deployment

apiVersion: mw.dell.com/v1 kind: Server

188 Server and hardware profile YAML file samples

metadata: name: server1 labels: site: malibu spec: bmcEndPoint: "https://" userName: root password: bios: attributes: procVirtualization: Enabled bootMode: Uefi serialPortAddress: Com2 bmc: - attributes: rfsIgnoreCertWarning: "Yes" serialRedirectEnable: Enabled operatingsystemname: "esxi-media" # set overwriteInstallation to true while editing existing servers to overwrite existing OS and to trigger a fresh installation overwriteInstallation: false operatingsystemconfig: autoConfigureBoss: true osDriver: - icen-media - ibbd-media #installVolumeID: "Disk.Virtual.0:RAID.Slot.2-1" networkingDetails: hostName: esxi-hostname ntpServer: - "127.0.0.1" dnsSearch: - "dell.com" dnsServer: - "127.0.0.1" installVolumeTypeOrder: - type: BOSS - type: SDCARD - type: NVME - type: HBA - type: RAID name: "Virtual Disk 1" configtype: "preseed" configdata: | # Accept the VMware End User License Agreement vmaccepteula

# Set the root password for the DCUI and Tech Support Mode rootpw

# Specifies another installation script to parse %include /tmp/sks.cfg

# Reboot the machine after scripted installation is complete reboot

# Specifies the NW address - obtain the NW settings from DHCP or static, IP address, Gateway, Subnet Mask, # Nameserver, Hostname, VLAN ID and Device MAC address or device name network --bootproto=static --ip=192.168.20.10 --gateway=192.168.20.254 -- netmask=255.255.255.0 --nameserver="192.168.20.250" --device="MAC" -- hostname=esxi1.dev.dell.com --vlanid=10

######################################################################################### ########## # Section below this should not be edited for a successful ESXi installation ######################################################################################### ##########

# Creates an init script that runs only during the first boot. It has no effect on subsequent boots.

Server and hardware profile YAML file samples 189

%firstboot --interpreter=busybox

# Set the hostname - using the input given in the spec.operatingsystemconfig.networkingDetails.hostname OSHOSTNAME={{.OSNetworkingDetails.HostName}} if [[ $OSHOSTNAME != "" ]]; then esxcli system hostname set --host=$OSHOSTNAME fi

# Set NTP setting NTPList={{.NTPServer}} if [[ ${#NTPList[@]} != 0 ]]; then NTPServer="" for ntp in $NTPList do NTPServer="${NTPServer} -s ${ntp}" done esxcli system ntp set -e=0 esxcli system ntp set $NTPServer esxcli system ntp set -e=1 fi

# Set DNS Search Setting DNSList={{.DNSSearch}} if [[ ${#DNSList[@]} != 0 ]]; then for dns in $DNSList do esxcli network ip dns search add -d $dns done

fi # Set DNS Server Setting DNSServerList={{.DNSServer}} if [[ ${#DNSServerList[@]} != 0 ]]; then for server in $DNSServerList do esxcli network ip dns server add -s $server done fi

# Set boot script to echo onto serial device sed -i '$ d' /etc/rc.local.d/local.sh echo 'echo sol_verify_complete > /dev/klog' >> /etc/rc.local.d/local.sh echo 'sleep 5m' >> /etc/rc.local.d/local.sh echo "esxcli network ip interface ipv4 get | awk 'BEGIN {print \"bmo_ip_details_delimiter\"} {if (NR>2) printf(\"%s:%s\n\", \$1, \$2)} END { print \"bmo_ip_details_delimiter\" }' >> /dev/klog" >> /etc/rc.local.d/local.sh echo "echo \" webServer outbound tcp dst 81 true true \" > /etc/vmware/firewall/webServer.xml" >> /etc/rc.local.d/local.sh

echo 'localcli network firewall refresh' >> /etc/rc.local.d/local.sh

# install network driver DEVICEDRIVERS={{.DeviceDriver}} if [[ ${#DEVICEDRIVERS[@]} != 0 ]]; then echo "esxcli system maintenanceMode set -e true" >> /etc/rc.local.d/local.sh for DEVICEDRIVER in $DEVICEDRIVERS do echo "wget $DEVICEDRIVER -O /tmp/driver.zip" >> /etc/rc.local.d/local.sh echo "unzip /tmp/driver.zip -d /tmp/ -o" >> /etc/rc.local.d/local.sh echo "rm -f /tmp/driver.zip" >> /etc/rc.local.d/local.sh echo "localcli software vib install -d /tmp/*.zip" >> /etc/rc.local.d/ local.sh echo "rm -f /tmp/*.zip" >> /etc/rc.local.d/local.sh done echo "esxcli system maintenanceMode set -e false" >> /etc/rc.local.d/local.sh fi echo "esxcli software vib list | awk 'BEGIN {print \"bmo_driver_details\"} {if (NR>2) printf(\"%s:%s\n\", \$1, \$2)} END {}' >> /dev/klog" >> /etc/rc.local.d/local.sh echo "esxcli software vib list --rebooting-image | awk 'BEGIN {} {if (NR>2)

190 Server and hardware profile YAML file samples

printf(\"%s:%s\n\", \$1, \$2)} END { print \"bmo_driver_details\" }' >> /dev/klog" >> / etc/rc.local.d/local.sh echo "esxcli network ip interface ipv4 get | awk 'BEGIN {print \"bmo_ip_details_delimiter\"} {if (NR>2) printf(\"%s:%s\n\", \$1, \$2)} END { print \"bmo_ip_details_delimiter\" }' >> /dev/klog" >> /etc/rc.local.d/local.sh echo 'exit 0' >> /etc/rc.local.d/local.sh # Send vmkernel log messages to the serial port localcli system settings advanced set -o /Misc/LogToSerial -i 1 # Send vmkernel debug log messages to the serial port localcli system settings advanced set -o /Misc/DebugLogToSerial -i 1 # Set rate for COM2 port to 115200 localcli system settings kernel set -s com2_baud -v 115200 # Set name of serial port to use for logging to COM2 localcli system settings advanced set -o /Misc/LogPort -s COM2 # Create a script to run before kickstart configuration is evaluated, this is used to generate files for the kickstart file to include %pre --interpreter=busybox # Retrieving the Device UID for all types of Volumes supported and using it for partitioning and installing ESXi PICKFIRSTVOLUME={{.PickFirstVolume}} SASADDRESS={{.SASAddress}} TARGET={{.Target}} TARGET=`expr $TARGET % 128` SERIALNUMBER={{.SerialNumber}} BOSSDISKTYPE={{.BossDiskType}} DEVICETYPE={{.DeviceType}} DEVICENAME="" if [[ $DEVICETYPE == "nvme" ]]; then nvmeDevices=$(localcli nvme device list | awk '{print $1}') for nvmeDevice in $nvmeDevices do if [[ $(localcli nvme device get -A $nvmeDevice | grep -c -i $SERIALNUMBER) == 1 ]]; then DEVICENAME=$(localcli storage core adapter device list | awk '{ if($1 == "'$nvmeDevice'") print $2}') fi done echo "install --disk=$DEVICENAME --overwritevmfs" >> /tmp/sks.cfg elif [[ $DEVICETYPE == "raid" ]]; then if [[ $PICKFIRSTVOLUME == "Yes" ]]; then DEVICENAME=$(esxcfg-mpath -L | awk '{ if($11 == "'$SASADDRESS'") print $3}' | head -1 | tail -1 | awk '{print $1}') echo "install --disk=$DEVICENAME --overwritevmfs" >> /tmp/sks.cfg else DEVICENAME=$(esxcfg-mpath -L | awk '{ if($11 == "'$SASADDRESS'" && $6 == "'$TARGET'") print $3}') echo "install --disk=$DEVICENAME --overwritevmfs" >> /tmp/sks.cfg fi elif [[ $DEVICETYPE == "hba" ]]; then TARGETLIST=$(esxcfg-mpath -L | grep $SASADDRESS | awk '{ print $6 }' | sort -n) for TGT in $TARGETLIST do DEVICENAME=$(esxcfg-mpath -L | awk '{ if($11 == "'$SASADDRESS'" && $6 == "'$TGT'") print $3}') DISPLAYNAME=$(esxcfg-mpath -l | grep -E ".*Display Name.*Disk.*$DEVICENAME" | cut -d":" -f2) if [[ -z "$DISPLAYNAME" ]]; then continue else break fi done echo "install --disk=$DEVICENAME --overwritevmfs" >> /tmp/sks.cfg elif [[ $DEVICETYPE == "usb" ]]; then echo "install --ignoressd --firstdisk=usb --overwritevmfs --novmfsondisk" >> / tmp/sks.cfg

Server and hardware profile YAML file samples 191

elif [[ $DEVICETYPE == "boss" ]]; then if [[$BOSSDISKTYPE == "Virtual"]]; then DEVICENAME=$(esxcfg-mpath -L | awk '{ if($3 ~ "'ATA'" && $3 ~ "'VD'") print $3}' | awk 'NR==1') echo "install --disk=$DEVICENAME --overwritevmfs" >> /tmp/sks.cfg fi if [[ -z $DEVICENAME ]]; then DEVICENAME=$(esxcfg-mpath -L | awk '{ if($3 ~ "'ATA'") print $3}' | awk 'NR==1') echo "install --disk=$DEVICENAME --overwritevmfs" >> /tmp/sks.cfg fi elif [[ $DEVICETYPE == "firstdisk" ]]; then echo "install --firstdisk --overwritevmfs --novmfsondisk" >> /tmp/sks.cfg fi

Sample hardware profile YAML file for ESXi deployment

apiVersion: mw.dell.com/v1 kind: HardwareProfile metadata: name: hwp-os-install labels: site: gc spec: apply: false preview: true selectors: model: dell-R750 # Add fields here server: bios: attributes: procVirtualization: Enabled bootMode: Uefi serialPortAddress: Com2 bmc: - attributes: rfsIgnoreCertWarning: "Yes" serialRedirectEnable: Enabled operatingsystemname: "esxi-media" # set overwriteInstallation to true while editing existing servers to overwrite existing OS and to trigger a fresh installation overwriteInstallation: false operatingsystemconfig: autoConfigureBoss: false networkingDetails: hostName: esxi-hostname ntpServer: - "127.0.0.1" dnsSearch: - "dell.com" dnsServer: - "127.0.0.1" osDriver: - ibbd - icen #installVolumeID: "Disk.Virtual.0:RAID.Slot.2-1" installVolumeTypeOrder: - type: BOSS - type: SDCARD - type: NVME - type: HBA - type: RAID name: "Virtual Disk 1" configtype: "preseed" configdata: | # Accept the VMware End User License Agreement vmaccepteula # Set the root password for the DCUI and Tech Support Mode rootpw

192 Server and hardware profile YAML file samples

# Specifies another installation script to parse %include /tmp/sks.cfg # Reboot the machine after scripted installation is complete reboot # Specifies the NW address - obtain the NW settings from DHCP or static, IP address, Gateway, Subnet Mask, # Nameserver, Hostname, VLAN ID and Device MAC address or device name network --bootproto=dhcp

######################################################################################### ########## # Section below this should not be edited for a successful ESXi installation ######################################################################################### ##########

# Creates an init script that runs only during the first boot. It has no effect on subsequent boots. %firstboot --interpreter=busybox

# Set the hostname - using the input given in the spec.operatingsystemconfig.networkingDetails.hostname OSHOSTNAME={{.OSNetworkingDetails.HostName}} if [[ $OSHOSTNAME != "" ]]; then esxcli system hostname set --host=$OSHOSTNAME fi

# Set NTP setting NTPList={{.NTPServer}} if [[ ${#NTPList[@]} != 0 ]]; then NTPServer="" for ntp in $NTPList do NTPServer="${NTPServer} -s ${ntp}" done esxcli system ntp set -e=0 esxcli system ntp set $NTPServer esxcli system ntp set -e=1 fi # Set DNS Search Setting DNSList={{.DNSSearch}} if [[ ${#DNSList[@]} != 0 ]]; then for dns in $DNSList do esxcli network ip dns search add -d $dns done fi # Set DNS Server Setting DNSServerList={{.DNSServer}} if [[ ${#DNSServerList[@]} != 0 ]]; then for server in $DNSServerList do esxcli network ip dns server add -s $server done fi

# Set boot script to echo onto serial device sed -i '$ d' /etc/rc.local.d/local.sh echo 'echo sol_verify_complete > /dev/klog' >> /etc/rc.local.d/local.sh echo 'sleep 5m' >> /etc/rc.local.d/local.sh echo "esxcli network ip interface ipv4 get | awk 'BEGIN {print \"bmo_ip_details_delimiter\"} {if (NR>2) printf(\"%s:%s\n\", \$1, \$2)} END { print \"bmo_ip_details_delimiter\" }' >> /dev/klog" >> /etc/rc.local.d/local.sh echo 'exit 0' >> /etc/rc.local.d/local.sh # install network driver DEVICEDRIVERS={{.DeviceDriver}} if [[ ${#DEVICEDRIVERS[@]} != 0 ]]; then echo "esxcli system maintenanceMode set -e true" >> /etc/rc.local.d/local.sh for DEVICEDRIVER in $DEVICEDRIVERS

Server and hardware profile YAML file samples 193

do echo "wget $DEVICEDRIVER -O /tmp/driver.zip" >> /etc/rc.local.d/local.sh echo "unzip /tmp/driver.zip -d /tmp/ -o" >> /etc/rc.local.d/local.sh echo "rm -f /tmp/driver.zip" >> /etc/rc.local.d/local.sh echo "localcli software vib install -d /tmp/*.zip" >> /etc/rc.local.d/ local.sh echo "rm -f /tmp/*.zip" >> /etc/rc.local.d/local.sh done echo "esxcli system maintenanceMode set -e false" >> /etc/rc.local.d/local.sh fi echo "esxcli software vib list | awk 'BEGIN {print \"bmo_driver_details\"} {if (NR>2) printf(\"%s:%s\n\", \$1, \$2)} END {}' >> /dev/klog" >> /etc/rc.local.d/local.sh echo "esxcli software vib list --rebooting-image | awk 'BEGIN {} {if (NR>2) printf(\"%s:%s\n\", \$1, \$2)} END { print \"bmo_driver_details\" }' >> /dev/klog" >> / etc/rc.local.d/local.sh echo "esxcli network ip interface ipv4 get | awk 'BEGIN {print \"bmo_ip_details_delimiter\"} {if (NR>2) printf(\"%s:%s\n\", \$1, \$2)} END { print \"bmo_ip_details_delimiter\" }' >> /dev/klog" >> /etc/rc.local.d/local.sh echo 'exit 0' >> /etc/rc.local.d/local.sh # Send vmkernel log messages to the serial port localcli system settings advanced set -o /Misc/LogToSerial -i 1 # Send vmkernel debug log messages to the serial port localcli system settings advanced set -o /Misc/DebugLogToSerial -i 1 # Set rate for COM2 port to 115200 localcli system settings kernel set -s com2_baud -v 115200 # Set name of serial port to use for logging to COM2 localcli system settings advanced set -o /Misc/LogPort -s COM2 # Create a script to run before kickstart configuration is evaluated, this is used to generate files for the kickstart file to include %pre --interpreter=busybox # Retrieving the Device UID for all types of Volumes supported and using it for partitioning and installing ESXi PICKFIRSTVOLUME={{.PickFirstVolume}} SASADDRESS={{.SASAddress}} TARGET={{.Target}} TARGET=`expr $TARGET % 128` SERIALNUMBER={{.SerialNumber}} BOSSDISKTYPE={{.BossDiskType}} DEVICETYPE={{.DeviceType}} DEVICENAME="" if [[ $DEVICETYPE == "nvme" ]]; then nvmeDevices=$(localcli nvme device list | awk '{print $1}') for nvmeDevice in $nvmeDevices do if [[ $(localcli nvme device get -A $nvmeDevice | grep -c -i $SERIALNUMBER) == 1 ]]; then DEVICENAME=$(localcli storage core adapter device list | awk '{ if($1 == "'$nvmeDevice'") print $2}') fi done

echo "install --disk=$DEVICENAME --overwritevmfs" >> /tmp/sks.cfg elif [[ $DEVICETYPE == "raid" ]]; then if [[ $PICKFIRSTVOLUME == "Yes" ]]; then DEVICENAME=$(esxcfg-mpath -L | awk '{ if($11 == "'$SASADDRESS'") print $3}' | head -1 | tail -1 | awk '{print $1}') echo "install --disk=$DEVICENAME --overwritevmfs" >> /tmp/sks.cfg else DEVICENAME=$(esxcfg-mpath -L | awk '{ if($11 == "'$SASADDRESS'" && $6 == "'$TARGET'") print $3}') echo "install --disk=$DEVICENAME --overwritevmfs" >> /tmp/sks.cfg fi elif [[ $DEVICETYPE == "hba" ]]; then TARGETLIST=$(esxcfg-mpath -L | grep $SASADDRESS | awk '{ print $6 }' | sort -n) for TGT in $TARGETLIST do

194 Server and hardware profile YAML file samples

DEVICENAME=$(esxcfg-mpath -L | awk '{ if($11 == "'$SASADDRESS'" && $6 == "'$TGT'") print $3}') DISPLAYNAME=$(esxcfg-mpath -l | grep -E ".*Display Name.*Disk.*$DEVICENAME" | cut -d":" -f2) if [[ -z "$DISPLAYNAME" ]]; then continue else break fi done echo "install --disk=$DEVICENAME --overwritevmfs" >> /tmp/sks.cfg elif [[ $DEVICETYPE == "usb" ]]; then echo "install --ignoressd --firstdisk=usb --overwritevmfs --novmfsondisk" >> /tmp/sks.cfg elif [[ $DEVICETYPE == "boss" ]]; then if [[$BOSSDISKTYPE == "Virtual"]]; then DEVICENAME=$(esxcfg-mpath -L | awk '{ if($3 ~ "'ATA'" && $3 ~ "'VD'") print $3}' | awk 'NR==1') echo "install --disk=$DEVICENAME --overwritevmfs" >> /tmp/sks.cfg fi if [[ -z $DEVICENAME ]]; then DEVICENAME=$(esxcfg-mpath -L | awk '{ if($3 ~ "'ATA'") print $3}' | awk 'NR==1') echo "install --disk=$DEVICENAME --overwritevmfs" >> /tmp/sks.cfg fi elif [[ $DEVICETYPE == "firstdisk" ]]; then echo "install --firstdisk --overwritevmfs --novmfsondisk" >> /tmp/sks.cfg fi

Sample operating system deployment YAML files - openSUSE You can deploy the openSUSE operating system on a server using a server YAML file or a hardware profile.

The following sample YAML files show the attributes and values for openSUSE deployment on Dell PowerEdge R650 and R750 servers.

The autoyast configdata contains sections of XML code. Valid XML elements require a start and end tag. PCDATA that you enter between the start and end tags is parsed. Some but not all elements have attributes associated with them.

NOTE:

These files are only for reference. You must use the sample files provided with Bare Metal Orchestrator deployment.

Comments in the YAML file start with a hash character (#) and is followed by a text or the name of the attribute. You

can remove # to un-comment and edit the attribute value.

Comments in the XML sections of the autoyast configdata use the following format:

Replace what appears between italicized, bold chevrons (< >) with user-supplied content. For example:

password:

In the XML sections, chevrons are omitted from user-supplied content fields. For example:

REPLACE_THIS

Sample server YAML file for openSUSE deployment

apiVersion: mw.dell.com/v1 kind: Server metadata: name: opensuse-server1 labels: site: gc spec:

Server and hardware profile YAML file samples 195

bmcEndPoint: "https://" userName: root password: bios: attributes: bootMode: Uefi serialPortAddress: Com2 bmc: - attributes: rfsIgnoreCertWarning: "Yes" serialRedirectEnable: Enabled operatingsystemname: "opensuse15.3" # set overwriteInstallation to true while editing existing servers to overwrite existing OS and to trigger a fresh installation overwriteInstallation: false operatingsystemconfig: autoConfigureBoss: false #installVolumeID: ""

installVolumeTypeOrder: - type: BOSS - type: SDCARD - type: NVME - type: HBA - type: RAID name: "" configtype: "autoyast" configdata: | false false UTC REPLACE_THIS true REPLACE_THIS REPLACE_THIS static REPLACE_THIS REPLACE_THIS autoneg on REPLACE_THIS REPLACE_THIS onboot default REPLACE_THIS REPLACE_THIS sshd true autoyast2-installation autoyast2 openssh vim-data zypper iputils vim bash curl base all /dev/sda true true / max false REPLACE_THIS dell true REPLACE_THIS root

Sample hardware profile YAML file for openSUSE deployment

apiVersion: mw.dell.com/v1 kind: HardwareProfile metadata: name: hwp-suse-os-install labels: site: gc spec: apply: false preview: true selectors: model: dell-R750 # Add fields here server: bios: attributes: bootMode: Uefi serialPortAddress: Com2 bmc: - attributes: rfsIgnoreCertWarning: "Yes" serialRedirectEnable: Enabled operatingsystemname: "opensuse15.3" # set overwriteInstallation to true while editing existing servers to overwrite existing OS and to trigger a fresh installation overwriteInstallation: false operatingsystemconfig: autoConfigureBoss: true #installVolumeID: "" installVolumeTypeOrder: - type: BOSS - type: SDCARD - type: NVME - type: HBA - type: RAID name: "" configtype: "autoyast" configdata: |

Server and hardware profile YAML file samples 199

false false UTC REPLACE_THIS true REPLACE_THIS REPLACE_THIS static REPLACE_THIS REPLACE_THIS autoneg on REPLACE_THIS REPLACE_THIS onboot default REPLACE_THIS REPLACE_THIS

200 Server and hardware profile YAML file samples

sshd true autoyast2-installation autoyast2 openssh vim-data zypper iputils vim bash curl base all /dev/sda true true / max false REPLACE_THIS dell true REPLACE_THIS root

202 Server and hardware profile YAML file samples

Sample operating system deployment YAML files - Red Hat Enterprise Linux You can deploy the Red Hat Enterprise Linux operating system on a server using a server YAML file or a hardware profile.

The following sample YAML files shows the attributes and values for Red Hat Enterprise Linux deployment on Dell PowerEdge 15th generation servers.

NOTE:

These files are only for reference. You must use the sample files provided with Bare Metal Orchestrator deployment.

The comments in the YAML file start with a hash character (#) and are followed by a text or the name of the attribute.

You can remove # to un-comment and edit the attribute value.

Replace what appears between italicized, bold chevrons (< >) with user-supplied content. For example:

password:

Sample server YAML file for Red Hat Enterprise Linux deployment

apiVersion: mw.dell.com/v1 kind: Server metadata: name: rhel-os labels: site: gc spec: bmcEndPoint: "https://" userName: root password: powerstate: "On" bios: attributes: bootMode: Uefi serialPortAddress: Com2 bmc: - attributes: rfsIgnoreCertWarning: "Yes" serialRedirectEnable: Enabled operatingsystemname: "rhel-media" operatingsystemconfig: autoConfigureBoss: false networkingDetails: hostName: # installVolumeID: "Disk.Virtual.0:RAID.Integrated.1-1" installVolumeTypeOrder: - type: BOSS - type: SDCARD - type: NVME - type: RAID name: "TestRaid0Vol0" - type: HBA configtype: "kickstart" configdata: |

# set language lang en_US # set keyboard layout keyboard us # set timezone timezone America/New_York --isUtc

# set root password, if --iscrypted is not used then clear text can be used

Server and hardware profile YAML file samples 203

rootpw --iscrypted # performs a reboot after installation reboot # runs text based installation instead of gui based text # installation from type cdrom, harddrive, nfs, liveimg, url cdrom

# Initializes any invalid partition tables that are found on disks and destroys all of the contents of disks with invalid partition tables. # This command is required when performing an installation on an IBM Z system with unformatted Direct Access Storage Device (DASD) disks, # otherwise the unformatted disks are not formatted and used during the installation. zerombr # Removes partitions from the system, prior to creation of new partitions. By default, no partitions are removed. clearpart --all --initlabel # Automatically creates partitions: a root (/) partition (1 GB or larger), a swap partition, # and an appropriate /boot partition for the architecture. On large enough drives (50 GB and larger), this also creates a /home partition. autopart # Configures network information for the target system and activates network devices in the installation environment. # The device specified in the first network command is activated automatically. network --device= -- hostname={{.OSNetworkingDetails.HostName}} --bootproto=static -- ip= --netmask= -- gateway= # System authorization information auth --passalgo=sha512 --useshadow # Sets the state of SELinux on the installed system. The default SELinux policy is enforcing. selinux --disable # Specify the firewall configuration for the installed system. firewall --enabled # If skipx is present, X-Server is not configured on the installed system. skipx # Determine whether the Initial Setup application starts the first time the system is booted. # If enabled, the initial-setup package must be installed. firstboot --enable ######################################################################################### ########## # Section below this should not be edited for a successful RHEL installation ######################################################################################### ########## %pre #!/bin/sh touch /tmp/rhel-install SASADDRESS={{.SASAddress}} TARGET={{.Target}} SERIALNUMBER={{.SerialNumber}} DEVICETYPE={{.DeviceType}} DEVICENAME="" OSHOSTNAME={{.OSNetworkingDetails.HostName}} GROUP="$(vgs --noheadings | awk '{print $1}')" # removing volume group if one exists if ! [ -z "$GROUP" ]; then

204 Server and hardware profile YAML file samples

vgremove -f -y $GROUP fi # wipe drives section # clearpart cannot clear existing bios raid configurations. # adding wipefs -a will remove that configuration DISKS="$(lsblk | grep disk | awk '{print $1}')" for DISK in $DISK; do echo "wiping signature from disk: $DISK" wipefs -a /dev/$DISK done case $DEVICETYPE in "nvme") DEVICENAME="$(ls -al /dev/disk/by-id/ | grep $SERIALNUMBER | awk '{print $11}' | cut -c 7- | head -n 1)" echo "ignoredisk --only-use=$DEVICENAME" >> /tmp/rhel-install ;; "raid") DEVICENAME="$(smartctl --scan | awk '{print $1}' | head -n 1)" echo "ignoredisk --only-use=$DEVICENAME" >> /tmp/rhel-install ;; "usb") DEVICENAME="$(ls -al /dev/disk/by-id | grep usb | awk '{print $11}' | cut -c 7- | head -n 1)" echo "ignoredisk --only-use=$DEVICENAME" >> /tmp/rhel-install ;; "hba") PCI="$(lspci | grep -i sas | awk '{print $1}')" DEVICENAME="$(ls -al /sys/block | grep $PCI | head -n 1 | awk '{print $9}' )" echo "ignoredisk --only-use=$DEVICENAME" >> /tmp/rhel-install ;; "boss") DEVICENAME="$(ls -al /dev/disk/by-id/ | grep -i ata | awk '{print $11}' | cut -c 7- | head -n 1)" echo "ignoredisk --only-use=$DEVICENAME" >> /tmp/rhel-install ;; esac %end %include /tmp/rhel-install %post /usr/bin/sed -i 's/rhgb quiet/console=tty0 console=ttyS1,115200/gI' /etc/default/ grub /usr/sbin/grub2-mkconfig -o /boot/efi/EFI/redhat/grub.cfg cat > /usr/lib/systemd/system/install_complete.service << EOF

hostnamectl set-hostname {{.OSNetworkingDetails.HostName}} [Unit] Description=Install Complete After=systemd-firstboot.target systemd-journald.service [Service]

OSHOSTNAME={{.OSNetworkingDetails.HostName}} Type=oneshot User=root RemainAfterExit=No ExecStart=/usr/bin/sh -c 'echo "sol_verify_complete" > /dev/kmsg' ExecStart=/usr/bin/sh -c 'sleep 5m' ExecStart=/usr/bin/sh -c 'printf "bmo_ip_details_delimiter " >> /dev/kmsg' ExecStart=/usr/bin/sh -c 'ip -4 addr |egrep "en[a-z][0-9]+|eth[0-9]+" | grep "inet" | cut -d " " -f 12 >> /dev/kmsg' ExecStart=/usr/bin/sh -c 'printf ":" >> /dev/kmsg' ExecStart=/usr/bin/sh -c 'hostname -I|cut -d" " -f 1 >> /dev/kmsg' ExecStart=/usr/bin/sh -c 'printf " bmo_ip_details_delimiter" >> /dev/kmsg'

Server and hardware profile YAML file samples 205

ExecStart=/usr/bin/sh -c 'sudo hostnamectl set-hostname $OSHOSTNAME ' ExecStart=/usr/bin/sh -c 'cat $OSHOSTNAME >> /etc/hostname'

EOF /usr/bin/ln -sf /usr/lib/systemd/system/install_complete.service /usr/lib/systemd/ system/default.target.wants/install_complete.service %end %packages @^minimal-environment kexec-tools %end

Sample hardware profile YAML file for Red Hat Enterprise Linux deployment

apiVersion: mw.dell.com/v1 kind: HardwareProfile metadata: name: hwp-dell labels: site: gc spec: apply: false preview: true selectors: model: dell-R750 # Add fields here server: powerState: "On" bios: attributes: bootMode: Uefi serialPortAddress: Com2 bmc: - attributes: serialRedirectEnable: Enabled rfsIgnoreCertWarning: "Yes" operatingsystemname: "rhel-media" operatingsystemconfig: autoConfigureBoss: true #installVolumeID: "Disk.Virtual.0:RAID.Slot.2-1" installVolumeTypeOrder: - type: BOSS - type: SDCARD - type: NVME - type: RAID name: "NAME_OF_VIRTUAL_DISK" - type: HBA configtype: "kickstart" configdata: |

lang en_US keyboard us timezone America/New_York --isUtc # Set the root password for the DCUI and Tech Support Mode rootpw --iscrypted # Reboot the machine after scripted installation is complete reboot text cdrom

206 Server and hardware profile YAML file samples

zerombr clearpart --all --initlabel network --bootproto=dhcp auth --passalgo=sha512 --useshadow selinux --disable firewall --enabled skipx firstboot --enable %pre #!/bin/sh touch /tmp/rhel-install SASADDRESS={{.SASAddress}} TARGET={{.Target}} SERIALNUMBER={{.SerialNumber}} DEVICETYPE={{.DeviceType}} DEVICENAME="" GROUP="$(vgs --noheadings | awk '{print $1}')" # removing volume group if one exists if ! [ -z "$GROUP" ]; then vgremove -f -y $GROUP fi # wipe drives section # clearpart cannot clear existing bios raid configurations. # adding wipefs -a will remove that configuration DISKS="$(lsblk | grep disk | awk '{print $1}')" for DISK in $DISK; do echo "wiping signature from disk: $DISK" wipefs -a /dev/$DISK done case $DEVICETYPE in "nvme") DEVICENAME="$(ls -al /dev/disk/by-id/ | grep $SERIALNUMBER | awk '{print $11}' | cut -c 7- | head -n 1)" echo "ignoredisk --only-use=$DEVICENAME" >> /tmp/rhel-install ;; "raid") DEVICENAME="$(smartctl --scan | awk '{print $1}' | head -n 1)" echo "ignoredisk --only-use=$DEVICENAME" >> /tmp/rhel-install ;; "usb") DEVICENAME="$(ls -al /dev/disk/by-id | grep usb | awk '{print $11}' | cut -c 7- | head -n 1)" echo "ignoredisk --only-use=$DEVICENAME" >> /tmp/rhel-install ;; "hba") PCI="$(lspci | grep -i sas | awk '{print $1}')" DEVICENAME="$(ls -al /sys/block | grep $PCI | head -n 1 | awk '{print $9}' )" echo "ignoredisk --only-use=$DEVICENAME" >> /tmp/rhel-install ;; "boss") DEVICENAME="$(ls -al /dev/disk/by-id/ | grep -i ata | awk '{print $11}' | cut -c 7- | head -n 1)" echo "ignoredisk --only-use=$DEVICENAME" >> /tmp/rhel-install ;; esac %end %include /tmp/rhel-install %post /usr/bin/sed -i 's/rhgb quiet/console=tty0 console=ttyS1,115200/gI' /etc/default/ grub

/usr/sbin/grub2-mkconfig -o /boot/efi/EFI/redhat/grub.cfg

Server and hardware profile YAML file samples 207

cat > /usr/lib/systemd/system/install_complete.service << EOF

[Unit] Description=Install Complete After=systemd-firstboot.target systemd-journald.service [Service] Type=oneshot User=root RemainAfterExit=No ExecStart=/usr/bin/sh -c 'echo "sol_verify_complete; bmo_ip_details_delimiter TBD bmo_ip_details_delimiter" > /dev/kmsg' EOF /usr/bin/ln -sf /usr/lib/systemd/system/install_complete.service /usr/lib/ systemd/system/default.target.wants/install_complete.service %end %packages @^minimal-environment kexec-tools %end

Sample operating system YAML files - Wind River Cloud Platform You can deploy the Wind River Cloud Platform operating system on a server using a server YAML file.

The following sample YAML file shows the attributes and values for deployment on Dell PowerEdge 15th generation servers.

NOTE:

These files are only for reference. You must use the sample files provided with Bare Metal Orchestrator deployment.

The comments in the YAML file start with a hash character (#) and are followed by a text or the name of the attribute.

You can remove # to un-comment and edit the attribute value.

Replace what appears between italicized, bold chevrons (< >) with user-supplied content. For example:

password:

Sample server YAML file for Wind River Cloud Platform operating system deployment

apiVersion: mw.dell.com/v1 kind: Server metadata: name: wr-controller labels: model: dell site: gc spec: bmcEndPoint: "https://" userName: "root" password: "" powerstate: "On" bios: attributes:

208 Server and hardware profile YAML file samples

bootMode: Uefi serialPortAddress: Com2 bmc: - attributes: rfsIgnoreCertWarning: "Yes" serialRedirectEnable: Enabled operatingsystemname: "wrmedia" operatingsystemconfig: networkingDetails: hostName: "wr-hostname" # installVolumeID: "Disk.Virtual.0:RAID.Slot.2-1" bootMenuOption: "2" minimumDiskSize: 500 // size in GB installVolumeTypeOrder: - type: NVME - type: BOSS - type: RAID name: "NAME_OF_VIRTUAL_DISK" - type: HBA configtype: "kickstart" configdata: | OAM_DEV=enp94s0f0 OAM_VLAN=33 OSHOSTNAME={{.OSNetworkingDetails.HostName}} cat << EOF > /etc/sysconfig/network-scripts/ifcfg-$OAM_DEV DEVICE=$OAM_DEV BOOTPROTO=none ONBOOT=yes LINKDELAY=20 EOF cat << EOF > /etc/sysconfig/network-scripts/ifcfg-$OAM_DEV.$OAM_VLAN DEVICE=$OAM_DEV.$OAM_VLAN BOOTPROTO=none IPADDR=192.168.33.10 PREFIX=24 GATEWAY=192.168.33.100 ONBOOT=yes VLAN=yes LINKDELAY=20 HOSTNAME=$OSHOSTNAME EOF cat > /usr/lib/systemd/system/install_complete.service << EOF [Unit] Description=Install Complete After=systemd-firstboot.target systemd-journald.service [Service]

OSHOSTNAME={{.OSNetworkingDetails.HostName}} Type=oneshot User=root RemainAfterExit=No ExecStart=/usr/bin/sh -c 'echo "sol_verify_complete" > /dev/ttyS1'

ExecStart=/usr/bin/sh -c 'sleep 5m' ExecStart=/usr/bin/sh -c 'printf "bmo_ip_details_delimiter " >> /dev/ttyS1' ExecStart=/usr/bin/sh -c 'ip -4 addr |egrep "en[a-z][0-9]+|eth[0-9]+" | grep "inet" | cut -d " " -f 11 >> /dev/ttyS1' ExecStart=/usr/bin/sh -c 'printf ":" >> /dev/ttyS1' ExecStart=/usr/bin/sh -c 'hostname -I|cut -d" " -f 1 >> /dev/ttyS1' ExecStart=/usr/bin/sh -c 'printf " bmo_ip_details_delimiter" >> /dev/ttyS1' ExecStart=/usr/bin/sh -c 'sudo hostnamectl set-hostname $OSHOSTNAME ' ExecStart=/usr/bin/sh -c 'cat $OSHOSTNAME >> /etc/hostname'

Server and hardware profile YAML file samples 209

EOF /usr/bin/ln -sf /usr/lib/systemd/system/install_complete.service /usr/lib/systemd/ system/default.target.wants/install_complete.service

Sample baseline profile YAML file The following is an example .yaml file.

This example YAML file shows the editable attributes that you need to define before you can use it to decommission a server. The profileName selector is used to target servers to be decommissioned. The server must have a matching profileName label configured.

You can edit every field in this YAML file, but you cannot delete fields.

NOTE: This example file is only for reference. Use the sample files that are provided with the Bare Metal Orchestrator

deployment.

apiVersion: mw.dell.com/v1 kind: HardwareProfile metadata: finalizers: - baseline-profile name: baseline-profile labels: site: gc namespace: metalweaver spec: apply: false preview: true selectors: #Please update the vendor label value vendor: " " profileName: " " server: decommission: secureEraseDrives: true bmc: - attributes: topologyLLDP: Disabled ipmiLanEnable: Disabled osBmcPassThroughState: Disabled timeZone: CST6CDT vlanEnable: Disabled vlanID: 1 snmpAgentEnable: Enabled snmpDiscoveryPortNumber: 161 snmpAgentCommunityName: public snmpProtocol: All virtualConsolePluginType: eHTML5 serialRedirectEnable: Enabled rfsIgnoreCertWarning: "Yes" bmcUsers: bmcDeleteUsers: - userName: " " bmcCreateUsers: - userName: " " password: " " roleId: "Operator" enabled: True bmcUpdateUsers: - userName: " " password: " " roleId: "Administrator"

210 Server and hardware profile YAML file samples

bios: attributes: procVirtualization: Enabled bootMode: Uefi serialPortAddress: Com2 logicalProc: Enabled setBootOrderFqdd1: "*.*.*" setBootOrderFqdd2: "NIC.*.*" setBootOrderFqdd3: "Optical.*.*" setBootOrderFqdd4: "Floppy.*.*" procAdjCacheLine: Enabled procHwPrefetcher: Enabled procSwPrefetcher: Enabled dcuStreamerPrefetcher: Enabled dcuIpPrefetcher: Enabled subNumaCluster: Disabled upiPrefetch: Enabled dynamicCoreAllocation: Disabled procX2Apic: Enabled procCores: All # can be 1 memTest: Disabled memOpMode: OptimizerMode # can be FaultResilientMode procPwrPerf: SysDbpm memFrequency: MaxPerf procTurboMode: Enabled procC1E: Enabled nodeInterleave: Disabled corrEccSmi: Enabled oppSrefEn: Disabled

monitorMwait: Enabled cpuInterconnectBusLinkPower: Enabled pcieAspmL1: Enabled uncoreFrequency: DynamicUFS energyPerformanceBias: BalancedPerformance proc1TurboCoreNum: All proc2TurboCoreNum: All memRefreshRate: 1x memPatrolScrub: Standard procCStates: Enabled #Can be Autonomous writeDataCrc: Disabled sriovGlobalEnable: Disabled conTermType: Vt100Vt220 extSerialConnector: Serial1 redirAfterBoot: Enabled serialComm: OnConRedirAuto failSafeBaud : "115200"

Server and hardware profile YAML file samples 211

Server and profile telemetry YAML file samples

Topics:

Sample server telemetry YAML file Sample profile telemetry YAML file

Sample server telemetry YAML file The following is an example .yaml file:

NOTE: This file is only for reference. You must use the sample files that are provided with the Bare Metal Orchestrator

deployment.

apiVersion: mw.dell.com/v1 kind: ServerTelemetry metadata: name: server3 labels: site: gc spec: rsyslogServer1: 2.3.4.5 rsyslogServer1Port: 42 rsyslogServer2: 3.4.5.6 rsyslogServer2Port: 42 report: AggregationMetrics: metricReportState: Enabled metricReportType: Periodic reportActions: - LogToMetricReportsCollection - RedfishEvent reportUpdates: Overwrite suppressRepeatedMetricValue: Disabled metricReportHeartbeatInterval: PT0H0M0S recurrenceInterval: PT0H0M0S reportTimeSpan: PT0H0M15S CPUMemMetrics: metricReportState: Enabled metricReportType: Periodic reportActions: - LogToMetricReportsCollection - RedfishEvent reportUpdates: Overwrite suppressRepeatedMetricValue: Disabled metricReportHeartbeatInterval: PT0H0M0S recurrenceInterval: PT0H0M0S reportTimeSpan: PT0H0M15S CPURegisters: metricReportState: Enabled metricReportType: Periodic reportActions: - LogToMetricReportsCollection - RedfishEvent reportUpdates: Overwrite suppressRepeatedMetricValue: Disabled metricReportHeartbeatInterval: PT0H0M0S recurrenceInterval: PT0H0M0S reportTimeSpan: PT0H0M15S

E

212 Server and profile telemetry YAML file samples

CPUSensor: metricReportState: Enabled metricReportType: Periodic reportActions: - LogToMetricReportsCollection - RedfishEvent reportUpdates: Overwrite suppressRepeatedMetricValue: Disabled metricReportHeartbeatInterval: PT0H0M0S recurrenceInterval: PT0H0M0S reportTimeSpan: PT0H0M15S FCPortStatistics: metricReportState: Enabled metricReportType: Periodic reportActions: - LogToMetricReportsCollection - RedfishEvent reportUpdates: Overwrite suppressRepeatedMetricValue: Disabled metricReportHeartbeatInterval: PT0H0M0S recurrenceInterval: PT0H0M0S reportTimeSpan: PT0H0M15S FCSensor: metricReportState: Enabled metricReportType: Periodic reportActions: - LogToMetricReportsCollection - RedfishEvent reportUpdates: Overwrite suppressRepeatedMetricValue: Disabled metricReportHeartbeatInterval: PT0H0M0S recurrenceInterval: PT0H0M0S reportTimeSpan: PT0H0M15S FPGASensor: metricReportState: Enabled metricReportType: Periodic reportActions: - LogToMetricReportsCollection - RedfishEvent reportUpdates: Overwrite suppressRepeatedMetricValue: Disabled metricReportHeartbeatInterval: PT0H0M0S recurrenceInterval: PT0H0M0S reportTimeSpan: PT0H0M15S FanSensor: metricReportState: Enabled metricReportType: Periodic reportActions: - LogToMetricReportsCollection - RedfishEvent reportUpdates: Overwrite suppressRepeatedMetricValue: Disabled metricReportHeartbeatInterval: PT0H0M0S recurrenceInterval: PT0H0M0S reportTimeSpan: PT0H0M15S GPUMetrics: metricReportState: Enabled metricReportType: Periodic reportActions: - LogToMetricReportsCollection - RedfishEvent reportUpdates: Overwrite suppressRepeatedMetricValue: Disabled metricReportHeartbeatInterval: PT0H0M0S recurrenceInterval: PT0H0M0S reportTimeSpan: PT0H0M15S GPUStatistics: metricReportState: Enabled metricReportType: Periodic reportActions: - LogToMetricReportsCollection - RedfishEvent reportUpdates: Overwrite

Server and profile telemetry YAML file samples 213

suppressRepeatedMetricValue: Disabled metricReportHeartbeatInterval: PT0H0M0S recurrenceInterval: PT0H0M0S reportTimeSpan: PT0H0M15S MemorySensor: metricReportState: Enabled metricReportType: Periodic reportActions: - LogToMetricReportsCollection - RedfishEvent reportUpdates: Overwrite suppressRepeatedMetricValue: Disabled metricReportHeartbeatInterval: PT0H0M0S recurrenceInterval: PT0H0M0S reportTimeSpan: PT0H0M15S NICSensor: metricReportState: Enabled metricReportType: Periodic reportActions: - LogToMetricReportsCollection - RedfishEvent reportUpdates: Overwrite suppressRepeatedMetricValue: Disabled metricReportHeartbeatInterval: PT0H0M0S recurrenceInterval: PT0H0M0S reportTimeSpan: PT0H0M15S NICStatistics: metricReportState: Disabled metricReportType: Periodic reportActions: - LogToMetricReportsCollection - RedfishEvent reportUpdates: Overwrite suppressRepeatedMetricValue: Disabled metricReportHeartbeatInterval: PT0H0M0S recurrenceInterval: PT0H0M0S reportTimeSpan: PT0H0M15S NVMeSMARTData: metricReportState: Enabled metricReportType: Periodic reportActions: - LogToMetricReportsCollection - RedfishEvent reportUpdates: Overwrite suppressRepeatedMetricValue: Disabled metricReportHeartbeatInterval: PT0H0M0S recurrenceInterval: PT0H0M0S reportTimeSpan: PT0H0M15S PSUMetrics: metricReportState: Enabled metricReportType: Periodic reportActions: - LogToMetricReportsCollection - RedfishEvent reportUpdates: Overwrite suppressRepeatedMetricValue: Disabled metricReportHeartbeatInterval: PT0H0M0S recurrenceInterval: PT0H0M0S reportTimeSpan: PT0H0M15S PowerMetrics: metricReportState: Enabled metricReportType: Periodic reportActions: - LogToMetricReportsCollection - RedfishEvent reportUpdates: Overwrite suppressRepeatedMetricValue: Disabled metricReportHeartbeatInterval: PT0H0M0S recurrenceInterval: PT0H0M0S reportTimeSpan: PT0H0M15S PowerStatistics: metricReportState: Disabled metricReportType: Periodic

214 Server and profile telemetry YAML file samples

reportActions: - LogToMetricReportsCollection - RedfishEvent reportUpdates: Overwrite suppressRepeatedMetricValue: Disabled metricReportHeartbeatInterval: PT0H0M0S recurrenceInterval: PT0H0M0S reportTimeSpan: PT0H0M15S Sensor: metricReportState: Enabled metricReportType: Periodic reportActions: - LogToMetricReportsCollection - RedfishEvent reportUpdates: Overwrite suppressRepeatedMetricValue: Disabled metricReportHeartbeatInterval: PT0H0M0S recurrenceInterval: PT0H0M0S reportTimeSpan: PT0H0M15S SerialLog: metricReportState: Enabled metricReportType: Periodic reportActions: - LogToMetricReportsCollection - RedfishEvent reportUpdates: Overwrite suppressRepeatedMetricValue: Disabled metricReportHeartbeatInterval: PT0H0M0S recurrenceInterval: PT0H0M0S reportTimeSpan: PT0H0M15S StorageDiskSMARTData: metricReportState: Enabled metricReportType: Periodic reportActions: - LogToMetricReportsCollection - RedfishEvent reportUpdates: Overwrite suppressRepeatedMetricValue: Disabled metricReportHeartbeatInterval: PT0H0M0S recurrenceInterval: PT0H0M0S reportTimeSpan: PT0H0M15S StorageSensor: metricReportState: Enabled metricReportType: Periodic reportActions: - LogToMetricReportsCollection - RedfishEvent reportUpdates: Overwrite suppressRepeatedMetricValue: Disabled metricReportHeartbeatInterval: PT0H0M0S recurrenceInterval: PT0H0M0S reportTimeSpan: PT0H0M15S SystemUsage: metricReportState: Enabled metricReportType: Periodic reportActions: - LogToMetricReportsCollection - RedfishEvent reportUpdates: Overwrite suppressRepeatedMetricValue: Disabled metricReportHeartbeatInterval: PT0H0M0S recurrenceInterval: PT0H0M0S reportTimeSpan: PT0H0M15S ThermalMetrics: metricReportState: Enabled metricReportType: Periodic reportActions: - LogToMetricReportsCollection - RedfishEvent reportUpdates: Overwrite suppressRepeatedMetricValue: Disabled metricReportHeartbeatInterval: PT0H0M0S recurrenceInterval: PT0H0M0S

Server and profile telemetry YAML file samples 215

reportTimeSpan: PT0H0M15S ThermalSensor: metricReportState: Enabled metricReportType: Periodic reportActions: - LogToMetricReportsCollection - RedfishEvent reportUpdates: Overwrite suppressRepeatedMetricValue: Disabled metricReportHeartbeatInterval: PT0H0M0S recurrenceInterval: PT0H0M0S reportTimeSpan: PT0H0M15S

Sample profile telemetry YAML file The following is an example .yaml file.

NOTE: This file is only for reference. You must use the sample files that are provided with the Bare Metal Orchestrator

deployment.

apiVersion: mw.dell.com/v1 kind: profileTelemetry metadata: name: hardwareprofile-1 labels: site: gc spec: server: rsyslogServer1: 2.3.4.5 rsyslogServer1Port: 42 rsyslogServer2: 3.4.5.6 rsyslogServer2Port: 42 report: AggregationMetrics: metricReportState: Enabled metricReportType: Periodic reportActions: - LogToMetricReportsCollection - RedfishEvent reportUpdates: Overwrite suppressRepeatedMetricValue: Disabled metricReportHeartbeatInterval: PT0H0M0S recurrenceInterval: PT0H0M0S reportTimeSpan: PT0H0M15S CPUMemMetrics: metricReportState: Enabled metricReportType: Periodic reportActions: - LogToMetricReportsCollection - RedfishEvent reportUpdates: Overwrite suppressRepeatedMetricValue: Disabled metricReportHeartbeatInterval: PT0H0M0S recurrenceInterval: PT0H0M0S reportTimeSpan: PT0H0M15S CPURegisters: metricReportState: Enabled metricReportType: Periodic reportActions: - LogToMetricReportsCollection - RedfishEvent reportUpdates: Overwrite suppressRepeatedMetricValue: Disabled metricReportHeartbeatInterval: PT0H0M0S recurrenceInterval: PT0H0M0S reportTimeSpan: PT0H0M15S CPUSensor: metricReportState: Enabled metricReportType: Periodic

216 Server and profile telemetry YAML file samples

reportActions: - LogToMetricReportsCollection - RedfishEvent reportUpdates: Overwrite suppressRepeatedMetricValue: Disabled metricReportHeartbeatInterval: PT0H0M0S recurrenceInterval: PT0H0M0S reportTimeSpan: PT0H0M15S FCPortStatistics: metricReportState: Enabled metricReportType: Periodic reportActions: - LogToMetricReportsCollection - RedfishEvent reportUpdates: Overwrite suppressRepeatedMetricValue: Disabled metricReportHeartbeatInterval: PT0H0M0S recurrenceInterval: PT0H0M0S reportTimeSpan: PT0H0M15S FCSensor: metricReportState: Enabled metricReportType: Periodic reportActions: - LogToMetricReportsCollection - RedfishEvent reportUpdates: Overwrite suppressRepeatedMetricValue: Disabled metricReportHeartbeatInterval: PT0H0M0S recurrenceInterval: PT0H0M0S reportTimeSpan: PT0H0M15S FPGASensor: metricReportState: Enabled metricReportType: Periodic reportActions: - LogToMetricReportsCollection - RedfishEvent reportUpdates: Overwrite suppressRepeatedMetricValue: Disabled metricReportHeartbeatInterval: PT0H0M0S recurrenceInterval: PT0H0M0S reportTimeSpan: PT0H0M15S FanSensor: metricReportState: Enabled metricReportType: Periodic reportActions: - LogToMetricReportsCollection - RedfishEvent reportUpdates: Overwrite suppressRepeatedMetricValue: Disabled metricReportHeartbeatInterval: PT0H0M0S recurrenceInterval: PT0H0M0S reportTimeSpan: PT0H0M15S GPUMetrics: metricReportState: Enabled metricReportType: Periodic reportActions: - LogToMetricReportsCollection - RedfishEvent reportUpdates: Overwrite suppressRepeatedMetricValue: Disabled metricReportHeartbeatInterval: PT0H0M0S recurrenceInterval: PT0H0M0S reportTimeSpan: PT0H0M15S GPUStatistics: metricReportState: Enabled metricReportType: Periodic reportActions: - LogToMetricReportsCollection - RedfishEvent reportUpdates: Overwrite suppressRepeatedMetricValue: Disabled metricReportHeartbeatInterval: PT0H0M0S recurrenceInterval: PT0H0M0S

Server and profile telemetry YAML file samples 217

reportTimeSpan: PT0H0M15S MemorySensor: metricReportState: Enabled metricReportType: Periodic reportActions: - LogToMetricReportsCollection - RedfishEvent reportUpdates: Overwrite suppressRepeatedMetricValue: Disabled metricReportHeartbeatInterval: PT0H0M0S recurrenceInterval: PT0H0M0S reportTimeSpan: PT0H0M15S NICSensor: metricReportState: Enabled metricReportType: Periodic reportActions: - LogToMetricReportsCollection - RedfishEvent reportUpdates: Overwrite suppressRepeatedMetricValue: Disabled metricReportHeartbeatInterval: PT0H0M0S recurrenceInterval: PT0H0M0S reportTimeSpan: PT0H0M15S NICStatistics: metricReportState: Disabled metricReportType: Periodic reportActions: - LogToMetricReportsCollection - RedfishEvent reportUpdates: Overwrite suppressRepeatedMetricValue: Disabled metricReportHeartbeatInterval: PT0H0M0S recurrenceInterval: PT0H0M0S reportTimeSpan: PT0H0M15S NVMeSMARTData: metricReportState: Enabled metricReportType: Periodic reportActions: - LogToMetricReportsCollection - RedfishEvent reportUpdates: Overwrite suppressRepeatedMetricValue: Disabled metricReportHeartbeatInterval: PT0H0M0S recurrenceInterval: PT0H0M0S reportTimeSpan: PT0H0M15S PSUMetrics: metricReportState: Enabled metricReportType: Periodic reportActions: - LogToMetricReportsCollection - RedfishEvent reportUpdates: Overwrite suppressRepeatedMetricValue: Disabled metricReportHeartbeatInterval: PT0H0M0S recurrenceInterval: PT0H0M0S reportTimeSpan: PT0H0M15S PowerMetrics: metricReportState: Enabled metricReportType: Periodic reportActions: - LogToMetricReportsCollection - RedfishEvent reportUpdates: Overwrite suppressRepeatedMetricValue: Disabled metricReportHeartbeatInterval: PT0H0M0S recurrenceInterval: PT0H0M0S reportTimeSpan: PT0H0M15S PowerStatistics: metricReportState: Disabled metricReportType: Periodic reportActions: - LogToMetricReportsCollection - RedfishEvent

218 Server and profile telemetry YAML file samples

reportUpdates: Overwrite suppressRepeatedMetricValue: Disabled metricReportHeartbeatInterval: PT0H0M0S recurrenceInterval: PT0H0M0S reportTimeSpan: PT0H0M15S Sensor: metricReportState: Enabled metricReportType: Periodic reportActions: - LogToMetricReportsCollection - RedfishEvent reportUpdates: Overwrite suppressRepeatedMetricValue: Disabled metricReportHeartbeatInterval: PT0H0M0S recurrenceInterval: PT0H0M0S reportTimeSpan: PT0H0M15S SerialLog: metricReportState: Enabled metricReportType: Periodic reportActions: - LogToMetricReportsCollection - RedfishEvent reportUpdates: Overwrite suppressRepeatedMetricValue: Disabled metricReportHeartbeatInterval: PT0H0M0S recurrenceInterval: PT0H0M0S reportTimeSpan: PT0H0M15S StorageDiskSMARTData: metricReportState: Enabled metricReportType: Periodic reportActions: - LogToMetricReportsCollection - RedfishEvent reportUpdates: Overwrite suppressRepeatedMetricValue: Disabled metricReportHeartbeatInterval: PT0H0M0S recurrenceInterval: PT0H0M0S reportTimeSpan: PT0H0M15S StorageSensor: metricReportState: Enabled metricReportType: Periodic reportActions: - LogToMetricReportsCollection - RedfishEvent reportUpdates: Overwrite suppressRepeatedMetricValue: Disabled metricReportHeartbeatInterval: PT0H0M0S recurrenceInterval: PT0H0M0S reportTimeSpan: PT0H0M15S SystemUsage: metricReportState: Enabled metricReportType: Periodic reportActions: - LogToMetricReportsCollection - RedfishEvent reportUpdates: Overwrite suppressRepeatedMetricValue: Disabled metricReportHeartbeatInterval: PT0H0M0S recurrenceInterval: PT0H0M0S reportTimeSpan: PT0H0M15S ThermalMetrics: metricReportState: Enabled metricReportType: Periodic reportActions: - LogToMetricReportsCollection - RedfishEvent reportUpdates: Overwrite suppressRepeatedMetricValue: Disabled metricReportHeartbeatInterval: PT0H0M0S recurrenceInterval: PT0H0M0S reportTimeSpan: PT0H0M15S ThermalSensor: metricReportState: Enabled

Server and profile telemetry YAML file samples 219

metricReportType: Periodic reportActions: - LogToMetricReportsCollection - RedfishEvent reportUpdates: Overwrite suppressRepeatedMetricValue: Disabled metricReportHeartbeatInterval: PT0H0M0S recurrenceInterval: PT0H0M0S reportTimeSpan: PT0H0M15S

220 Server and profile telemetry YAML file samples

Site Configuration YAML Examples

Topics:

Sample DHCP configuration YAML file

Sample DHCP configuration YAML file The following is an example global_site.yaml file that includes DHCP settings for automatic server discovery.

--- apiVersion: mw.dell.com/v1 kind: Site metadata: name: malibu spec: # Add fields here nodeName: type: remote location: malibu autoDiscoveryMode: discoveryViaDhcp: auto dhcpDeployMode: server DhcpConfigData: dhcpSubnet: - defaultLeaseTime: 3000 maxLeaseTime: 6000 netmask: "255.255.255.0" optionBroadcastAddress: "255.255.255.0" optionRouters: "172.16.14.2" optionSubnetMask: "255.255.255.0" subnet: "172.16.14.0" dhcpPool: - allowMembers: - "iDRAC" denyMembers: endRange: "172.16.14.210" startRange: "172.16.14.199" - allowMembers: - "udhcp 1.23.1" denyMembers: endRange: "172.16.14.220" startRange: "172.16.14.211" - allowMembers: - "CPQRIB3" denyMembers: endRange: "172.16.14.230" startRange: "172.16.14.221" - defaultLeaseTime: 3000 maxLeaseTime: 6000 netmask: "255.255.255.0" optionBroadcastAddress: "255.255.255.0" optionRouters: "192.168.14.2" optionSubnetMask: "255.255.255.0" subnet: "192.168.14.0" dhcpPool: - allowMembers: denyMembers: - "iDRAC" - "udhcp 1.23.1" - "CPQRIB3" endRange: "192.168.14.210"

F

Site Configuration YAML Examples 221

startRange: "192.168.14.199" interfaces: "ens192, ens224" vendorClassIdentifier: - iDRAC - udhcp 1.23.1 - CPQRIB3 - onie_vendor:x86_64-dellemc domain: "dell.com" dns: "8.8.8.8, 8.8.4.4" defaultLeaseTime: "3000" maxLeaseTime: "6000" additionalDhcpConfig: "log-facility local7;" metadata: id: MALICFBC city: Malibu state: California address: "5450 Great America Pkwy, Malibu, CA 95054, USA" country: USA latLong: "37.404882, -121.978486"

222 Site Configuration YAML Examples

Stack deployment YAML example

Topics:

Sample VMWare TCP stack deployment YAML file Sample TKG deployment YAML file Sample Wind River Cloud Platform stack deployment YAML file

Sample VMWare TCP stack deployment YAML file The following is an example .yaml file.

NOTE: This file is only for reference. You must use the sample files that are provided with the Bare Metal Orchestrator

deployment.

apiVersion: mw.dell.com/v1 kind: Stackdeployer metadata: name: tcp-stack-1 labels: site: spec: stackType: "VMWare_TCP" stackVersion: "2.0" stackInstallerConfig: installerIp: "1.2.3.4" installerUserName: "USERNAME" installerPassword: "REPLACETHIS" configFile: "InstallerConfig.json" stackConfig: "TCPConfig.json" stackHostAdditionConfig: "AddHosts.json" VlanId: "20" Domain: "dellnfv.com" dnsList: - "1.2.3.0" serverForDeployment: - ip: "1.2.3.4" username: "root" password: REPLACE_THIS address: "esxi10" name: "server1" - ip: "1.2.3.4" username: "root" password: REPLACE_THIS address: "esxi11" name: "server2" - ip: "1.2.3.4" username: "root" password: REPLACE_THIS address: "esxi12" name: "server3" - ip: "1.2.3.4" username: "root" password: REPLACE_THIS address: "esxi13" name: "server4" - ip: "1.2.3.4" username: "root" password: REPLACE_THIS address: "esxi14" name: "server5"

G

Stack deployment YAML example 223

- ip: "1.2.3.4" username: "root" password: REPLACE_THIS address: "esxi15" name: "server6" - ip: "1.2.3.4" username: "root" password: REPLACE_THIS address: "esxi16" name: "server7" - ip: "1.2.3.4" username: "root" password: REPLACE_THIS address: "esxi17" name: "server8" reInitialize: false

Sample TKG deployment YAML file The following is an example .yaml file that is used for TKG deployments.

NOTE: This file is only for reference. You must use the sample files that are provided with the Bare Metal Orchestrator

deployment.

apiVersion: mw.dell.com/v1 kind: Stackdeployer metadata: name: tcp-stack-1 labels: model: dell site: gc spec: stackType: "VMWare_TCP" stackVersion: "2.0" stackInstallerConfig: - installerIp: "1.2.3.4" installerUserName: "USERNAME" installerPassword: "REPLACETHIS" configFile: "InstallerConfig.json" stackConfig: ["TCPConfig.json"] stackHostAdditionConfig: "AddHosts.json" VlanId: "20" Domain: "dellnfv.com" vmwareRequest: createTKGTemplateList: - name: "management-template" clusterType: "MANAGEMENT" description: "description of template" templateJson: "tkg-management-template.json" - name: "shared-service-template" clusterType: "SHAREDSERVICE" description: "description of template" templateJson: "tkg-sharedservice-template.json" - name: "workload-template" clusterType: "WORKLOAD" description: "description of template" templateJson: "tkg-workload-template.json" createTKGClusterList: - name: "management-cluster" clusterType: "MANAGEMENT" templateName: "management-template" targetDomainName: "DOMAIN-NAME" clusterPassword: "REPLACE-THIS" endpointIP: "1.2.3.10" - name: "shared-service-cluster" clusterType: "SHAREDSERVICE" templateName: "shared-service-template" targetDomainName: "DOMAIN-NAME"

224 Stack deployment YAML example

clusterPassword: "REPLACE-THIS" endpointIP: "1.2.3.11" managementClusterName: "management-cluster" - name: "workload-cluster" clusterType: "WORKLOAD" templateName: "workload-template" targetDomainName: "DOMAIN-NAME" clusterPassword: "REPLACE-THIS" endpointIP: "1.2.3.12" managementClusterName: "management-cluster" deleteTKGClusterList: - "cluster1" - "cluster2" deleteTKGTemplateList: - "template-1" - "template-2" dnsList: - "1.2.3.0" serverForDeployment: - ip: "1.2.3.4" username: "root" password: REPLACE_THIS address: "esxi10" name: "server1" - ip: "1.2.3.4" username: "root" password: REPLACE_THIS address: "esxi11" name: "server2" - ip: "1.2.3.4" username: "root" password: REPLACE_THIS address: "esxi12" name: "server3" - ip: "1.2.3.4" username: "root" password: REPLACE_THIS address: "esxi13" name: "server4" - ip: "1.2.3.4" username: "root" password: REPLACE_THIS address: "esxi14" name: "server5" - ip: "1.2.3.4" username: "root" password: REPLACE_THIS address: "esxi15" name: "server6" - ip: "1.2.3.4" username: "root" password: REPLACE_THIS address: "esxi16" name: "server7" - ip: "1.2.3.4" username: "root" password: REPLACE_THIS address: "esxi17" name: "server8" reInitialize: false

Stack deployment YAML example 225

Sample Wind River Cloud Platform stack deployment YAML file The following is an example Wind River Cloud Platform stack deployment profile .yaml file.

NOTE: This file is only for reference. You must use the sample files that are provided with the Bare Metal Orchestrator

deployment.

apiVersion: mw.dell.com/v1 kind: Stackdeployer metadata: name: wr-stack-1 labels: site: spec: stackType: "Windriver" stackVersion: "21.05" stackInstallerConfig: installerIp: "1.2.3.4" installerUserName: "USERNAME" installerPassword: "REPLACETHIS" configFile: "installer_config.yaml" domainName : "centralcloud" stackConfig: ["deployment_config.yaml"] dnsList: - "1.2.3.45" serverForDeployment: - name : "controller-0" domain: "centralcloud" type : controller-0 namespace: "metalweaver" - name : "controller-1" domain: "centralcloud" type : controller-1 namespace: "metalweaver" - name : "worker-0" domain: "centralcloud" type : worker-0 namespace: "metalweaver" reInit

Manualsnet FAQs

If you want to find out how the 1.3 Dell works, you can view and download the Dell Bare Metal Orchestrator 1.3 Software Command Line Interface User's Guide on the Manualsnet website.

Yes, we have the Command Line Interface User's Guide for Dell 1.3 as well as other Dell manuals. All you need to do is to use our search bar and find the user manual that you are looking for.

The Command Line Interface User's Guide should include all the details that are needed to use a Dell 1.3. Full manuals and user guide PDFs can be downloaded from Manualsnet.com.

The best way to navigate the Dell Bare Metal Orchestrator 1.3 Software Command Line Interface User's Guide is by checking the Table of Contents at the top of the page where available. This allows you to navigate a manual by jumping to the section you are looking for.

This Dell Bare Metal Orchestrator 1.3 Software Command Line Interface User's Guide consists of sections like Table of Contents, to name a few. For easier navigation, use the Table of Contents in the upper left corner.

You can download Dell Bare Metal Orchestrator 1.3 Software Command Line Interface User's Guide free of charge simply by clicking the “download” button in the upper right corner of any manuals page. This feature allows you to download any manual in a couple of seconds and is generally in PDF format. You can also save a manual for later by adding it to your saved documents in the user profile.

To be able to print Dell Bare Metal Orchestrator 1.3 Software Command Line Interface User's Guide, simply download the document to your computer. Once downloaded, open the PDF file and print the Dell Bare Metal Orchestrator 1.3 Software Command Line Interface User's Guide as you would any other document. This can usually be achieved by clicking on “File” and then “Print” from the menu bar.