LOC-A Core Framework Software
“
Specifications
The LOC-A Core Framework is designed for professional services
engineers and end users to deploy and manage cloud clusters and
bare metal systems in Datacenters, staging, and edge
environments.
Supported Server Types and Cloud Flavors
- ThinkSystem SE350 (MT: 7Z46)
- ThinkSystem SR630 (MT: 7X01/7X02)
- ThinkSystem SR630 V2 (MT: 7Z70/7Z71)
- ThinkSystem SR630 V3 (MT: 7D72/7D73/7D74)
- ThinkSystem SR630 V4
- ThinkSystem SR650 (MT: 7X06)
- ThinkSystem SR650 V2 (MT: 7Z72/7Z73/7D15)
- ThinkSystem SR650 V3 (MT: 7D75/7D76/7D77)
- ThinkSystem SR650 V4
- ThinkEdge SE450 (MT: 7D8T)
- ThinkEdge SE360 V2 (MT: 7DAM)
- ThinkEdge SE350 V2 (MT: 7DA9)
- ThinkEdge SE455 V3 (MT: 7DBY)
- ThinkEdge SE100 (MT: 7DGR)
Supported OS Flavors
- Ubuntu 22.04.4, 22.04.5
- Red Hat OpenShift Container Platform
- ESXi 8.0.2c, 8.0.3e
Product Usage Instructions
Deployment of LOC-A Core Framework
To deploy the LOC-A Core Framework, follow these steps:
- Download the latest version of the LOC-A Core Framework.
- Run the installation wizard and follow the on-screen
instructions. - Configure the framework settings based on your
requirements.
Managing Cloud Clusters and Bare Metal Systems
To manage cloud clusters and bare metal systems using the LOC-A
Core Framework:
- Access the dashboard of the LOC-A Core Framework.
- Create a new deployment project for your cloud cluster or bare
metal system. - Monitor the deployment progress and manage resources as
needed.
Frequently Asked Questions (FAQ)
Q: What are the supported server types for the LOC-A Core
Framework?
A: The supported server types include ThinkSystem SE350,
ThinkSystem SR630, ThinkSystem SR650, ThinkEdge SE450, and more.
Refer to the specifications section for a detailed list.
Q: How can I upgrade the LOC-A Core Framework to a newer
version?
A: To upgrade the LOC-A Core Framework, download the latest
version from the official website and follow the upgrade
instructions provided in the documentation.
Q: Can I deploy Red Hat OpenShift using the LOC-A Core
Framework?
A: Yes, Red Hat OpenShift Container Platform is supported by the
LOC-A Core Framework. Refer to the supported OS flavors section for
more details.
“`
LOC-A Core Framework User Guide (Version 3.5)
Date: 2025-6-10
LOC-A Core Framework User Guide
Page | 1
Table of Contents
Summary of Statement………………………………………………………………………………………………………………………………..4 LOC-A Core Framework Overview …………………………………………………………………………………………………………………5 Installation and Upgrade ……………………………………………………………………………………………………………………………..7
Installation and configuration …………………………………………………………………………………………………………………..7 Environment requirements …………………………………………………………………………………………………………………..7 Sample network configuration ………………………………………………………………………………………………………………8 Step-by-step LOC-A Core Framework appliance installation………………………………………………………………………9 Firewall requirements…………………………………………………………………………………………………………………………15
Upgrade LOC-A Appliance……………………………………………………………………………………………………………………….16 Before you start …………………………………………………………………………………………………………………………………17 Upgrade the appliance to a higher version (supported since release 3.2) ………………………………………………….17 Upgrade appliance from 3.1 to higher version……………………………………………………………………………………….20
Functional User Guide ……………………………………………………………………………………………………………………………….21 Cloud setup…………………………………………………………………………………………………………………………………………..21 Sites …………………………………………………………………………………………………………………………………………………22 IP ranges …………………………………………………………………………………………………………………………………………..27 Network services ……………………………………………………………………………………………………………………………….33 Cloud services ……………………………………………………………………………………………………………………………………38 Credential policy ……………………………………………………………………………………………………………………………………48 Device profiles ………………………………………………………………………………………………………………………………………52 Generate LOC-A registration packages……………………………………………………………………………………………………..56 Generate USB type package ………………………………………………………………………………………………………………..56 Generate near-Zero Touch Provisioning type package…………………………………………………………………………….57 Download Lenovo Open Cloud Automation Utility …………………………………………………………………………………59 Register devices …………………………………………………………………………………………………………………………………….59 Register devices via Lenovo Open Cloud Automation Utility ……………………………………………………………………59 Register devices via USB key………………………………………………………………………………………………………………..67 Add devices by Discovery ……………………………………………………………………………………………………………………71 Add device by BMC IP …………………………………………………………………………………………………………………………77 Upload device Excel file ………………………………………………………………………………………………………………………79 Adding devices into external hardware management tools……………………………………………………………………..80 Continuous devices discovery………………………………………………………………………………………………………………81 Repository management ………………………………………………………………………………………………………………………..88 Vault secrets management……………………………………………………………………………………………………………………..92 Create a cluster template ……………………………………………………………………………………………………………………….98 Update a cloud template ………………………………………………………………………………………………………………………106
Page | 2
LOC-A Core Framework User Guide
Cluster deployment ……………………………………………………………………………………………………………………………..107 Cloud expansion ………………………………………………………………………………………………………………………………….109 Instance deletion …………………………………………………………………………………………………………………………………113 Create an OS template………………………………………………………………………………………………………………………….113 Update an OS template…………………………………………………………………………………………………………………………121 Bare metal OS deployment……………………………………………………………………………………………………………………121 Automatic instance creation………………………………………………………………………………………………………………….122 Deployment Analytics Dashboard ………………………………………………………………………………………………………….127 OS Image sideloading …………………………………………………………………………………………………………………………..129 View tasks …………………………………………………………………………………………………………………………………………..132 License management……………………………………………………………………………………………………………………………133
Before you begin………………………………………………………………………………………………………………………………133 View licenses …………………………………………………………………………………………………………………………………..134 Install licenses using the Features on Demand web portal …………………………………………………………………….135 Delete licenses…………………………………………………………………………………………………………………………………136 Export licenses …………………………………………………………………………………………………………………………………137 Get help ………………………………………………………………………………………………………………………………………….137 Administration ………………………………………………………………………………………………………………………………………..138 User management ……………………………………………………………………………………………………………………………….138 Role-based Access Control (RBAC)………………………………………………………………………………………………………138 Enable LDAP authentication ………………………………………………………………………………………………………………139 Certificate management ……………………………………………………………………………………………………………………….142 Backup and Restore ……………………………………………………………………………………………………………………………..146 Troubleshooting ……………………………………………………………………………………………………………………………………..149 Log collection………………………………………………………………………………………………………………………………………149 Debug shell enablement……………………………………………………………………………………………………………………….149 Known Issues and Limitations …………………………………………………………………………………………………………………..153 Appendix ……………………………………………………………………………………………………………………………………………….. 154 A. End User License Agreement (EULA) ……………………………………………………………………………………………….154 B. Entitlement ………………………………………………………………………………………………………………………………….158 C. License and Image Download …………………………………………………………………………………………………………159
LOC-A Core Framework User Guide
Page | 3
Summary of Statement
This document is intended for both professional services engineers and end users. It describes how to deploy the LOC-A Core Framework and use the LOC-A Core Framework to deploy and manage cloud clusters and bare metal systems in Datacenters, staging, and edge environments.
· The cloud flavors (cloud types) supported by the LOC-A Core Framework appliance are: o VMware ThinkAgile VX Cluster(vSAN) o Red Hat OpenShift Container Platform (RHOCP)
· The LOC-A Core Framework also supports Bare Metal OS deployment of several operating systems: o Ubuntu o ESXi
The server types and supported cloud flavors matrix is as follows:
ThinkSystem SE350 (MT: 7Z46)
ThinkSystem SR630 (MT: 7X01/7X02)
ThinkSystem SR630 V2 (MT: 7Z70/7Z71) ThinkSystem SR630 V3 (MT: 7D72/7D73/7D74) ThinkSystem SR630 V4
VMware ThinkAgile VX Cluster(vSAN) Yes Yes Yes
N/A
Yes
Red Hat OpenShift Container Platform (RHOCP) Yes Yes Yes
N/A
N/A
(MT:
7DG8/7DG9/7DK1/7DLM/7DGA/7DGB)
ThinkSystem SR650 (MT: 7X06)
Yes
Yes
ThinkSystem SR650 V2 (MT:
N/A
N/A
7Z72/7Z73/7D15)
ThinkSystem SR650 V3 (MT:
N/A
N/A
7D75/7D76/7D77)
ThinkSystem SR650 V4
Yes
N/A
(MT:
7DGD/7DGC/7DLN/7DK2/7DGE/7DGF)
ThinkEdge SE450 (MT: 7D8T)
N/A
Yes
ThinkEdge SE360 V2 (MT:7DAM)
N/A
Yes
ThinkEdge SE350 V2 (MT: 7DA9)
N/A
Yes
ThinkEdge SE455 V3
N/A
Yes
(MT: 7DBY)
ThinkEdge SE100
(MT: 7DGR)
Table 1: Cloud flavors support matrix
The server types and supported OS flavors version matrix is:
Page | 4
LOC-A Core Framework User Guide
ThinkSystem SE350 (MT: 7Z46) ThinkSystem SR630 (MT: 7X01/7X02)
Ubuntu 22.04.4,22.04.5 22.04.4,22.04.5
ThinkSystem SR630 V2 (MT: 7Z70/7Z71) ThinkSystem SR630 V3 (MT: 7D72/7D73/7D74)
22.04.4,22.04.5, 24.04.1,24.04.2 22.04.4,22.04.5, 24.04.1,24.04.2
ThinkSystem SR630 V4
24.04.1,24.04.2
ESXi N/A 8.0.2c, 8.0.3e 8.0.2c, 8.0.3e
8.0.2c, 8.0.3e 8.0.3e
(MT: 7DG8/7DG9/7DK1/7DLM/7DGA/7DGB) ThinkSystem SR650 (MT: 7X06)
22.04.4,22.04.5
ThinkSystem SR650 V2 (MT: 7Z72/7Z73/7D15) ThinkSystem SR650 V3 (MT: 7D75/7D76/7D77)
22.04.4,22.04.5, 24.04.1,24.04.2 22.04.4,22.04.5, 24.04.1,24.04.2
ThinkSystem SR650 V4
24.04.1,24.04.2
8.0.2c, 8.0.3e 8.0.2c, 8.0.3e
8.0.2c, 8.0.3e 8.0.3e
(MT: 7DGD/7DGC/7DLN/7DK2/7DGE/7DGF) ThinkEdge SE450 (MT: 7D8T)
22.04.4,22.04.5,24.04.1,24.04.2
ThinkEdge SE360 V2 (MT:7DAM)
22.04.4,22.04.5, 24.04.1,24.04.2
ThinkEdge SE350 V2 (MT: 7DA9)
22.04.4,22.04.5,24.04.1,24.04.2
ThinkEdge SE455 V3 (MT: 7DBY) ThinkEdge SE100 (MT: 7DGR)
22.04.4,22.04.5, 24.04.1,24.04.2 24.04.1,24.04.2 Table 2: OS flavors support matrix
8.0.2c, 8.0.3e 8.0.2c, 8.0.3e 8.0.2c, 8.0.3e 8.0.2c, 8.0.3e N/A
Through collaboration with Microsoft, and with the Lenovo ThinkAgile MX team, Lenovo Open Cloud Automation now supports deploying ThinkAgile MX Premier Solutions for both MX455v3 Edge Premier and MX650v3 Premier solutions. ThinkAgile MX Premier solutions offer a seamless experience for both edge and datacenter customers and use Lenovo Open Cloud Automation for the server bootstrap and deployment. To find out more about how the process works, you can read the LOC-A for Microsoft Premier Solution User Guide.
LOC-A Core Framework Overview
Lenovo Open Cloud Automation (LOC-A) Core Framework is a modular automation framework designed to enable Lenovo’s customers to easily deploy and manage bare-metal OS and on-prem cloud solutions on Lenovo and other RedFish enabled hardware. It is intended to be:
· An OPEN, lightweight automatic lifecycle management engine that can be extended to support various on-prem cloud offerings.
· An Enterprise solution for Datacenter and Edge on-prem cloud life cycle management.
LOC-A Core Framework User Guide
Page | 5
The LOC-A Core Framework appliance is a self-contained image, for quick installation, that includes all the services required to do the automated on-prem cloud deployment and lifecycle management for IT infrastructure. The services within the image run as services on top of a built-in K3S cluster. The following components are included:
· Inventory Service (LIS) The Inventory service is the source-of-truth for the infrastructure that handles planning data and edge site resources, including sites, IP addresses and VLANs, cloud services, network services, and the cloud objects, such as tenants and clusters. The metadata for resources can be imported or created by users in the planning phase.
· Configuration Service (LCS) The Configuration service is an execution orchestrator built on AWX. LOC-A LCS is configured with predefined automation workflows and job templates that make managing the infrastructure lifecycle easy and efficient.
· Hardware Management Service (LMS) The Hardware Management service helps to provision hardware and performs hardware configuration operations during the lifecycle of Lenovo servers. LOC-A includes Confluent and Lenovo OneCli as components of its Hardware Management Service. LMS is responsible for: o Server inventory o Server power operations (as part of the Lifecycle Management processes) o Server operating system deployment o Server firmware updates o Server configuration
Page | 6
LOC-A Core Framework User Guide
Installation and Upgrade
Installation and configuration
Environment requirements
The following requirements need to be met to deploy LOC-A Core Framework and use it to deploy on-prem cloud clusters to datacenter or edge locations.
· An ESXi host must be available to run the LOC-A Core Framework software appliance. The following resources are required by the virtual machine: o 8 CPU cores o 32 GB memory o 300 GB disks
· Make sure that you have vCenter installed to manage this ESXi host.
· Two networks are essential for LOC-A to be able to deploy and manage cloud clusters: o OOB Management Network (BMC/XCC). An Out-of-band management network for the BMC(XCC) of each server in the cluster, and optionally, switch discovery and management
o Cluster/OS Networks (Management). In-band cluster-specific data and management networks. The cluster network topology may vary for different cluster types that LOC-A supports. Among cluster networks, an operating system (OS)/management network is mandatory for in-band OS deployment and configuration.
Note: The Management network is the OS/Cluster management network that is essential to central management of all cloud platform flavors.
· The LOC-A Core Framework appliance must have layer 3 access to the out-of-band (OOB) network used to access the BMCs of the edge-site nodes. It also must have layer 3 access to the OS/Cloud management network for the configuration and deployment of the target edge-site nodes. In case of Datacenter or Staging environments layer 2 access to the BMC and OS Management can also be used.
· Secured and reliable connectivity between the LOC-A Core Framework appliance and the edge sites must exist. OOB and OS/Cloud management networks for the edge sites must be global layer 3 networks; network address translation (NAT) is assumed not to be used. For Datacenter or Staging environments, a private network can be used.
· Each target node must have appropriate licensing to support the attachment of remote media. For Legacy servers, ensure that the following two licenses are enabled on the target nodes: o Lenovo xClarity Controller Enterprise Upgrade o Lenovo xClarity Controller Advanced Upgrade For XCC2-based servers, ensure that the following license is enabled on the target node: o Lenovo XClarity Controller 2 Platinum Upgrade For XCC3-based servers, ensure that the following license is enabled on the target node: o Lenovo XClarity XCC3 Premier
Redfish support must be enabled on the target systems for the deployment to work.
LOC-A Core Framework User Guide
Page | 7
Note: On systems shipped from the factory, this is enabled by default
See the Release Notes for a full list of supported cluster types. See Cluster deployment for more requirements and details on each supported cluster type.
Sample network configuration
Figure 1 shows the typical network topology for the LOC-A Core Framework appliance in edge sites. LOC-A core framework appliance is deployed in the corporate datacenter and has L3 connectivity to the edge sites over site VPN networks.
Figure 1: LOC-A Network topology for edge sites
Figure 2 shows the typical network topology for the LOC-A Core Framework appliance in datacenter or staging environments. The LOC-A core framework appliance is usually deployed in the same L2 network with servers, network services and cloud services. In this context, the concept of a ‘site’ is logical, representing a collection of resources associated with a user’s cloud clusters. Users can allocate resources from within a data center to different sites.
Page | 8
LOC-A Core Framework User Guide
Figure 2: LOC-A Network topology for datacenter and staging environments
The LOC-A Core Framework supports either a dedicated OOB network separated from cloud networks, or a layer 3 network on which OOB and cloud networks can be shared.
Step-by-step LOC-A Core Framework appliance installation
1. Prepare the network of the ESXi host that will be used to host the LOC-A Core Framework appliance. A network is required to access the OS/cloud management network. If your OOB and OS/cloud management networks are separated by VLANs, you will also need to create a BMC port group for LOC-A Core Framework to access the target network.
LOC-A Core Framework User Guide
Page | 9
Figure 3: ESXi host network setting
2. Follow the steps in section C. License and Image Download to download the LOC-A Core Framework software appliance image from Lenovo to a system that can access the target vCenter vSphere client for your environment.
3. Deploy the OVA to the ESXi host: a. From vSphere, go to VMs and Templates. Then right click on the Datacenter of the target ESXi host and click Deploy OVF Template. b. Click Local file and then UPLOAD FILES to select the OVA file that was downloaded from Lenovo. Click Next. c. Give the virtual machine a name and a folder. Click Next. d. Choose the ESXi host for the compute resource and click Next. e. Review the template details and click Next. f. Choose the type of disk provisioning and click Next. g. Ensure that the network mappings are configured properly. · The external network should correspond to the network to access the OS/cloud management network. · The XCC network should correspond to the dedicated BMC(XCC) network. If the XCC network is shared, you can specify the same network as the first network.
Page | 10
LOC-A Core Framework User Guide
Figure 4: Example of network selection
h. In Customize Template, enter the network configuration of the LOC-A Core Framework appliance. Table 1 lists the parameters and descriptions.
Parameter Hostname
Mandatory Description
Yes
Hostname of the LOC-A appliance.
Sample Value Loca
External
Yes
Network IP
Hostname must respect the following rules:
· Must be 253 characters or less.
· Can only contain letters(az,A-Z), digits(0-9), hyphen(`-‘) and dots(`.’).
· Cannot start or end with a dot or hyphen.
External IPv4 address of the LOC-A appliance portal. You can then access the portal GUI via https://[External Network IP]
30.0.0.168
External
Yes
Network
Netmask
External
Yes
Network
Gateway
LOC-A Core Framework User Guide
This is also the interface for the appliance to access the DNS servers and vCenters in OS/cloud management network for the infrastructure. Netmask of the subnet for external network interface.
255.255.255.0
The gateway of the external network 30.0.0.1 interface.
Page | 11
Parameter
Mandatory
XCC Network IP No
Description
If the nodes’ BMC(XCC) network is not accessible through an external network IP address, you MUST specify the XCC network interface with its IPv4 address. This is used for server management.
Sample Value 192.168.0.10
XCC Network Netmask XCC Network Gateway OS management Network IP
OS management Network Netmask OS management Network Gateway DNS Server #1
DNS Server #2
If the nodes’ XCC network is accessible
through external network IP, you
MUST NOT specify the IP and the
netmask/gateway of XCC network
interface.
No
Netmask of the subnet for XCC
255.255.255.0
network interface.
No
The gateway of the XCC network
192.168.0.1
interface.
Yes
An extra IPv4 address in the OS/cloud 30.0.0.169
management network for LOC-A to
perform OS deployment. This IP
address is usually in the same subnet
of the External Network IP address,
and it needs to be a different IP from
the External Network IP.
Yes
Netmask of the subnet for the
255.255.255.0
OS/cloud management network
interface.
Yes
The gateway of the OS/cloud
30.0.0.1
management network interface.
Yes
Primary DNS server for the appliance.
Note: This does not need to be the
DNS server used by the workload
servers to be deployed. You can plan
and import the settings for the DNS
servers for the infrastructure later
through the LOC-A portal web
interface.
No
Secondary DNS server for the
appliance.
Table 3: LOC-A deployment properties
8.8.8.8 114.114.114.114
Figure 5 and Figure 6 show two examples of the input for a dedicated XCC network and a shared XCC network:
Page | 12
LOC-A Core Framework User Guide
Figure 5: Deployment properties for dedicated XCC network
LOC-A Core Framework User Guide
Page | 13
Figure 6: Deployment properties for shared network
i. Click Next to complete template customization. j. Review and accept the OVA installation by clicking Finish on the `Ready to complete’ screen. The
OVA installation can take quite some time depending on the speed of your network. k. After the installation of the OVA completes, ensure that the VM starts successfully.
It will take several minutes for LOC-A services to start up after the VM is booted. You will be able to access the LOC-A Core Framework web portal through:
https://[External Network IP] .
The default credential is: username: admin password: Lenovo@123
Page | 14
LOC-A Core Framework User Guide
Figure 7: LOC-A Core Framework web portal
Note: After you log in, you are forced to change the initial password for the default admin user. You can also add new users later through Setup Users. More details may be seen in the User management section of this document.
Firewall requirements
The LOC-A VM appliance has two network interface cards. One is the External-Network, which is configured with External Network IP and OS management Network IP.
The other one is the XCC-Network, which is configured with XCC Network IP. XCC-Network is only needed when the customer environment has a separate BMC management network and OS network.
Below are the required infrastructure firewall requirements base on the two network topology options:
– Converged BMC management network and OS network:
Both BMC management network and OS network are converged, LOC-A appliance accesses this network through the External-Network NIC.
Action Allow
Allow
Source
Customer GUI clients External Network IP
Allow Allow Allow
External Network IP External Network IP XCC Network Devices
Destination
External Network IP Appliance DNS server, DNS network services in metadata Host Device OS IPs Cloud services in metadata XCC network IP
Service TCP TCP/UDP
TCP TCP UDP
Port 443 53
Specific to cloud flavors* Specific to cloud services** 427, 1900
Appliance NIC External-Network External-Network
External-Network External-Network XCC-Network
LOC-A Core Framework User Guide
Page | 15
Allow Allow
Allow
XCC Network Devices OS management Network IP Host Device OS IPs
XCC network IP TCP
13001
Host Device XCC TCP
443
IPs
OS management TCP
443
Network IP
Table 4: Firewall requirement for converged network
XCC-Network External-Network
External-Network
– Separate BMC management network and OS network:
The BMC management network and OS network are isolated, the LOC-A appliance accesses the OS network through the External-Network NIC, and access the BMC network through the XCC-Network NIC in a dedicated way.
Action Allow
Allow
Source
Customer GUI clients External Network IP
Allow Allow Allow Allow Allow Allow
External Network IP External Network IP XCC Network Devices XCC Network Devices XCC Network IP
Host Device OS IPs
Destination
External Network IP Appliance DNS server, DNS network services in metadata Host Device OS IPs Cloud services in metadata XCC network IP
Service TCP TCP/UDP
TCP TCP UDP
Port 443 53
Specific to cloud flavors* Specific to cloud services** 427, 1900
XCC network IP TCP
13001
Devices XCC IPs TCP
443
OS management TCP
443
Network IP
Table 5: Firewall requirement for separate network
Appliance NIC External-Network External-Network
External-Network External-Network XCC-Network XCC-Network XCC-Network External-Network
Note:
*: For ESXi, VMware vSAN Cluster deployment, Host Device OS IPs need to have port 443 accessible. For other cloud/OS flavors, no specific requirements are needed.
**: For VMware vSAN Cluster deployment, the vCenter service needs to have port 443 accessibility. For RedHat OpenShift Container Platform deployment, the Assisted Installer service needs to have port 8080 accessibility.
For hardware management functionalities, Lenovo LXCA, Lenovo LXCO, and Lenovo Management Hub services need to have port 443 accessibility.
Upgrade LOC-A Appliance
LOC-A supports in-place upgrades using a patch since release 3.2. It allows users to upgrade LOC-A from the current version to a higher version. LOC-A also provide a CLI for the upgrade from 3.1 to a newer version.
Note:
Page | 16
LOC-A Core Framework User Guide
· LOC-A doesn’t support in-place upgrade from version 3.1/3.2/3.3/3.3.1 upgrade to version 3.4 due to a MongoDB upgrade. To upgrade to version 3.4, you will need to use the back-up export from a current LOC-A Appliance and import the backup into the new 3.4 LOC-A Appliance. Upgrade from 3.4 to 3.5 is supported.
Before you start
You must first check for available upgrade patches. In the case that there are upgrade patches available, download and apply the upgrade patch. To check if there are upgrade patches available, please visit https://commercial.lenovo.com/. To check for/download a patch the steps are:
· Log in to the website with your account. · Go to the tab `ESD Licensed software’. Note that this may be hidden under the `hamburger button’ on
the left side of the screen. · Click the button `GO TO DOWNLOADS’. · Find the `Lenovo Open Cloud Automation’ section (Note that depending on the number of entitlements
you have this may require some scrolling or you can search for `LOC-A’.)
Once you have the new release or upgrade patch, follow these steps to prepare the upgrade:
1. Download the upgrade patch from Lenovo. The patch contains all resources needed for an upgrade. 2. Unpack the upgrade patch. After unpacking the patch, we will get these files:
a. README.md b. changelog c. updatePackageSigned.tar 3. Take a snapshot of the existing LOC-A appliance. The snapshot may be used in the case that any issues are encountered during the upgrade. Users can revert the appliance to the previous snapshot to recover from any errors encountered.
Upgrade the appliance to a higher version (supported since release 3.2)
Notes:
· First, you need to make sure there are no running tasks or operations before entering maintenance mode. An error message will pop up if you try to enter maintenance when there are running tasks and operations.
· The patch must be applied under maintenance mode. · If there are any issues encountered during upgrade, you can revert the appliance to the previous snapshot
taken before upgrade. · The LECP flavor is no longer supported as of 3.2. After upgrading, it is not possible to create new LECP
flavor type templates and instances. The historical data will still be shown after the upgrade. · When the upgrade is completed, please clear the Browser’s cache to make sure everything displays
correctly.
Follow these steps to upgrade the LOC-A appliance:
Step 1. Upload upgrade patch.
a) From the LOC-A web interface, click Maintenance – Patches Upload/Apply.
b) Click the upload button . c) Click Browse to find the patch file that you downloaded. d) Click Upload to upload the patch.
LOC-A Core Framework User Guide
Page | 17
Figure 8: Upload upgrade package
Step 2. Set LOC-A to maintenance mode a) Click where it says `Maintenance Mode: Off’ at the top of the screen. b) Click the “On” button to set maintenance mode.
Page | 18
Figure 9: Set maintenance mode
LOC-A Core Framework User Guide
Figure 10: Maintenance mode
Step 3. Apply the patch a) Click the >>> Patches Upload/Apply button. b) Select a patch and click the Run icon .
LOC-A Core Framework User Guide
Page | 19
Figure 11: Apply patch
Note:
· Applying the patch will take about 15 minutes. You can click the refresh icon to check the real time status of patch application during the upgrade.
· The patch has possible statuses of not applied, applying, failed and applied. The web page needs to be refreshed after applying a patch.
Upgrade appliance from 3.1 to higher version
Since there is no web interface implemented for 3.1, you can only use a CLI called “ladm” to do the upgrade from 3.1 to a newer version. Contact the Lenovo support team to get the ladm tool. Note:
· Debug shell must be enabled before performing a CLI based upgrade. · The LECP flavor is no longer supported as of 3.2. After upgrading, it is not possible to create new LECP
flavor type templates and instances. The historical data will still be in the portal.
Following these steps to upgrade the LOC-A appliance from 3.1: Step 1. Copy ladm and the upgrade package to the LOC-A appliance of 3.1 through the debug shell. Note: It is recommended to copy the upgrade package to the folder “/tmp”. Step 2. Login into the 3.1 LOC-A appliance through the debug shell Step 3. Run the following command inside the LOC-A appliance “./ladm upgrade -f <your file path>/updatePackageSigned.tar” to start the upgrade
Page | 20
LOC-A Core Framework User Guide
Figure 12: Apply patch for 3.1 appliance
Note:
· Refresh the web page after applying the patch. · Because the device profile function is optimized when upgrading from version 3.1 or 3.2 to version 3.3, the
previous device profile will be replaced by the new device profile. The new device profile defines different best recipes for different flavors and model combinations. This behavior affects the device profile, template, and instance functions.
Functional User Guide
Cloud setup
Cloud Setup is where LOC-A manages all the cloud cluster resources. In Cloud Setup, users can create plans for the locations by defining sites, IP ranges, network services, and cloud services required for cloud cluster deployment.
Cluster Software lifecycle management supported by LOC-A are:
Cloud Offering
Supported Versions
VMware ThinkAgile VX cluster (vSAN)
8.0
RedHat OpenShift Container Platform (OCP)
4.12 ~ 4.15
Table 6: Cloud flavors supported by LOC-A
Minimum Nodes 3 3
Furthermore, LOC-A supports bare-metal OS deployment on ThinkSystem and ThinkEdge servers. LOC-A supports the following OS types:
OS Family Ubuntu
ESXi
Supported Versions 22.04.4, 22.04.5, 24.04.1, 24.04.2 8.0.2, 8.0.3 Table 7: OS types supported by LOC-A
Minimum Nodes 1
1
LOC-A supports importing details about the required resources in batches via an Excel file.
LOC-A Core Framework User Guide
Page | 21
Follow these steps to prepare planning data:
a) From the LOC-A web interface, click SetupUpload Metadata. b) Click Download metadata file template to get the sample Excel file
“Cloud_Setup_Standard_Template.xlsx”. c) Follow the embedded instructions to fill in the file with planning data for your site(s). d) Click Browse to find the file that you updated. e) Click Upload metadata to upload the template.
Figure 13: Uploading Excel file to Setup
LOC-A will process the Excel worksheets and create the sites and resources entered in the LOC-A system. It will take several seconds or minutes for the task to complete, depending on the number of resources defined. Click Tasks to check the progress of the task. When the task is completed, a notification is shown on the page.
Note: Excel files can be uploaded multiple times, and resources are imported incrementally. If the resources (sites, IP ranges, cloud services, network services) defined in the Excel file already exist in LOC-A with the same name, they will be updated with the new information. If the resource does not exist, it will be created. However, to delete a resource (such as an IP range), you will need to delete it from the LOC-A portal. After planning metadata is uploaded, you can view the resources details in their corresponding tabs in the Setup page.
Sites
A site is typically several nodes geographically located at a building or a campus. Figure 14 shows an example page that lists all the sites. You can view the site name, site code, and the geographical region it belongs to. The typical hierarchy of sites is:
Geo Country/Region -> State/Province City/Town Site Servers Site name is the name that identifies a site. In addition, you can specify a site code for the site. Note: The site name and site code must be unique within the LOC-A system.
Page | 22
LOC-A Core Framework User Guide
Figure 14: Sites list
Deployment Readiness:
LOC-A performs a deployment readiness check for the site metadata and displays the result in the Deployment Readiness Status column. If a site has all metadata validated for deployment, it will be shown as Ready. Otherwise, the value is shown as Not Ready. Hover your mouse over the field to display a message with a detailed explanation for the issue, such as a mandatory service missing, or the planned IP range is not valid. The figure below shows an example of the detailed explanations that can be shown.
Figure 15: Deployment Readiness details When you correct the corresponding metadata by editing it on the web page, or by importing the Excel file again with corrected metadata, the deployment readiness status is updated to reflect the latest check result.
View a site’s details:
Click a site to view more details, such as IP address ranges, cloud services, network services (NTP and DNS), that are planned for this site.
LOC-A Core Framework User Guide
Page | 23
Figure 16: Site details
Create a site:
Starting with LOC-A version 3.3, you can click the Create button to create a site, it will pop up a page to guide you through the creation process.
Page | 24
LOC-A Core Framework User Guide
Figure 17: Create a site
Fill in the fields for site creation. These typically include:
· Name*: Enter the name of the site. · Code*: Enter a unique code for the new site. · Geo*: Provide the geographical location information. · Country/Region*: Select the country or region where the site is located. · State/Province*: Enter the state or province. · City/Town*: Enter the city or town. · Address: Provide the detailed address of the site. · Post Code: Enter the postal code. · GPS Coordinates: Enter the GPS coordinates if available. · Time zone: Select the appropriate time zone. · Flavor*: Choose the flavor to be supported at that site.
The fields marked with an asterisk (*) are mandatory. Fill in any optional fields according to requirements. These might involve extra site-specific details or configurations. Check the entered information to guarantee its
LOC-A Core Framework User Guide
Page | 25
correctness. Once the Create button is clicked, the system will handle the request and create the new site, bind the IP ranges, and assign services to the site.
Note:
· The Site name must be globally unique. · Ensure that all required fields are filled out before attempting to create the site. · If there are any validation errors, the site will not be created, and you will need to correct the errors
before proceeding. · After the site is successfully created, it may take some time for the system to fully configure and display
the new site in relevant lists or dashboards.
Update a site:
Starting with LOC-A version 3.4, you can click the Edit button to update a site, it will pop up a page to guide you through the update process. It is similar with the Creation operation.
Page | 26
Figure 18: Update a site
LOC-A Core Framework User Guide
Note:
If devices have already been registered at this site, modifying the name is not allowed to be modified. If there are already instances on this site, the flavor is not allowed to be modified. During instance planning and onboarding, it is not recommended to modify the site and its related metadata resources to prevent failures in subsequent processes. Modifying the site will not affect the already created instances. The content of instances will not change with the change of site information.
Delete a site:
To delete one or more sites, select the sites to be deleted, and click Delete. The deletion may take several seconds to clean up site resources. After the deletion is complete the page will be automatically refreshed to show the updated results.
You are not allowed to delete a site that has existing cloud clusters deployed. To delete a site with clusters, you must remove the cluster first.
Note: A site cannot be deleted if there are devices registered to it. You must delete the devices that are registered to the site first. When a site is deleted, all resources (IP ranges, networks services, cloud services) that were planned to the site are also deleted.
IP ranges
IP ranges are IP resources that can be used by a site. The IP range is identified using an IP range name; the IP range name must be unique within LOC-A, and the IP range should not overlap with any other IP ranges.
For each specific cloud flavor, you can define multiple IP ranges for a site to differentiate the purpose or role of the network. An IP range can be dedicated for a site, or it can be common to all sites (labeled as any in the Site column), depending on the network role.
IP ranges will be associated to the site in the order of affinity. An IP range dedicated to a site has a higher affinity than an IP range designated for any site. For example:
· range1 of the vSAN-vSAN role is defined for siteA · range2 of the vSAN-vMotion role is defined as any
In this scenario, siteA will use range1 as its IP pool for the vMotion network.
LOC-A Core Framework User Guide
Figure 19: IP ranges list
Page | 27
IP ranges are essential resources to deploy and manage an on-prem cloud cluster. Different cloud flavors might have specific roles of IP ranges defined for cloud deployment.
Table 8 shows the IP ranges required for a LOC-A site for on-prem cloud deployment based on different cloud offerings:
Cloud or Bare Metal OS offering VMware vSAN
RedHat OCP
Bare Metal OS (Ubuntu, ESXi)
IP range role
Description
Mandatory
Management
Node OS/management network Yes
vSAN-vSAN
Node vSAN network
Yes
vSAN-vMotion
Node vMotion network
Yes
BMC
XCC (BMC) management
Yes
network
Management
Node OS/management network Yes
BMC
XCC (BMC) management
Yes
network
Management
Node OS/management network Yes
BMC
XCC (BMC) management
Yes
network
Table 8: Cloud cluster IP range requirement
Can be common to all sites No Yes Yes No
No No
No No
Gateway required
Yes No No Yes
Yes Yes
Yes Yes
Note:
1. 10.42.0.0/15 is the network CIDR reserved by LOC-A. Make sure that you do not have overlapping IP ranges defined. · If this address range is in use within your network and is accessible by the LOC-A Core Framework appliance or the systems being deployed this may also cause an inconsistent OS deployment experience.
2. For RedHat OpenShift Container Platform: · The last two IP addresses of the Management IP range will be assigned for API VIP and Ingress VIP of the cluster. As a result, you will need to make sure that your Management IP range contains at least N+2 valid IP addresses, where N is the number of nodes in the cluster.
For more details about network requirements, please refer to the official documentation of the cloud offering.
View an IP range’s details:
You can view an IP range’s details by clicking on one IP range.
Page | 28
LOC-A Core Framework User Guide
Figure 20: IP range detail
Create an IP range:
Starting with LOC-A version of 3.3, you can click the Create button to create an IP range, it will pop up a page to guide the user through the creation process.
LOC-A Core Framework User Guide
Page | 29
Figure 21: Create an IP range
Fill in the fields for IP range creation. These typically include:
· Name*: Enter the name of the IP range. · Associated Sites*: Select the associated sites. · Role*: Select the network role · Prefix*: Enter the prefix value. · IP Start: Enter the start IP address. · IP End: Enter the end IP address. · Default Gateway: Enter the gateway address. · IP Allocation Strategy: Select the allocation strategy.
LOC-A provides two strategies, the first is LOC-A allocated and the second is User allocated. LOC-A allocated for BMC means that LOC-A selects and allocates an IP address to the BMC using the user’s planned IP range. User allocated means that the BMC IP address of the user has been allocated in advance and LOC-A will not allocate an IP again. For the IP allocation strategy of the management network type, please refer to Known Issues And Limitations.
The fields marked with an asterisk (*) are mandatory. Fill in any optional fields according to your requirements. These might involve extra IP range-specific details or configurations. Check the entered information to guarantee
Page | 30
LOC-A Core Framework User Guide
its correctness. Once the Create button is clicked, the system will handle the request and create the new IP range. Meanwhile binding it to associated sites and update the Deployment Readiness Status in the Sites page.
Note:
· If the Start/End IP addresses are not defined, they are automatically assigned based on the prefix. · If the ‘IP Allocation Strategy’ option is set to ‘User allocated’, users should allocate and configure the IP
manually either statically or dynamically, before device registration. If the ‘IP Allocation Strategy’ option is set to ‘LOC-A allocated’, LOC-A will allocate and configure the IPs automatically during device registration. · Ensure that all required fields are filled out before attempting to create the IP range. · If there are any validation errors, the IP range will not be created, and you need to correct the errors before proceeding. · After the IP range is successfully created, it may take some time for the system to fully configure and display the new IP range in relevant lists or dashboards.
Update an IP range:
Starting with LOC-A version of 3.4, you can click the Edit button to update an IP range, it will pop up a page to guide the update process. It is similar with Creation operation.
LOC-A Core Framework User Guide
Page | 31
Figure 22: Update an IP range
Note:
If this IP range is already in use, the newly set IP range must encompass the IPs that are already being used. If this IP range has already been used by an instance or a device, the Role cannot be modified, and the Associated Sites must include the site where the instance is located. When performing instance planning/onboarding and device registration, it is recommended not to modify the IP range to avoid failures in subsequent processes. Modifying the IP range will not affect the already created instances. The content of the already created instances will not change with the change of IP range information.
Delete an IP range:
To delete one or more IP ranges, select the IP range(s) and click Delete. The deletion may take several seconds. After the deletion is complete, the page will be automatically refreshed to show the updated results.
Page | 32
LOC-A Core Framework User Guide
Note: If a mandatory IP range is deleted, a site will be not eligible for cloud deployment, and the deployment readiness status will display notReady.
Network services
Network services are the essential external services for cloud deployment, including NTP and DNS servers. You can also define customized network services that may be involved in the cloud deployment and lifecycle management. LOC-A supports an automated connectivity check for network services during the server registration process (Near Zero Touch Provisioning or nZTP). The network service name must be unique within LOC-A.
A network service can be allocated for one or multiple sites. You can specify a site list separated by commas. You can also specify any, which means the network service can be allocated for all sites.
Network services will be associated to the site in the order of affinity. For example,
· dns1 is defined for siteA, siteB · dns2 is defined for siteA · dns3 is defined for any
In this scenario, the DNS servers for siteA and siteB are:
· siteA: dns2 (primary), dns1 (secondary) · siteB: dns1 (primary), dns3 (secondary)
If Check Connectivity is checked, this network service will be checked for connectivity during nZTP server registration.
For VMware vSAN cluster deployment, mandatory network services required for each site are:
· Two DNS servers · One NTP server
For RedHat OCP cluster, mandatory network services required for each site are:
· One DNS server · One NTP server
For Ubuntu bare-metal OS deployment, one DNS server is required. For other bare-metal OS deployments, network services are optional. If DNS or NTP servers are planned for a site, LOC-A automatically configures the deployed OS with the expected network settings when doing bare metal OS deployment.
Figure 23 shows an example page that lists network services:
LOC-A Core Framework User Guide
Page | 33
Figure 23: Network services list
View a network service’s details:
You can view a network service’s details by clicking on one network service.
Page | 34
Figure 24: Network services detail
LOC-A Core Framework User Guide
Create a network service:
Starting with LOC-A version of 3.3, you can click the Create button to create a network service, it will pop up a page to guide the creation process.
Figure 25: Create a network service
Fill in the fields for network service creation. These typically include:
· Name*: Enter the name of the network service. · Role*: Select the network service role. · Associated Sites*: Select the associated sites. · IP/FQDN/URI*: Specify the service’s access address. · Check Connectivity*: Used for connectivity check. · Connectivity Check Protocol: Specify the protocol for connectivity checks. · Connectivity Check Port: Specify the port for the connectivity check. · Number of Retries: Specify the number of times the connectivity check should retry in the case of
a failure.
LOC-A Core Framework User Guide
Page | 35
The fields marked with an asterisk (*) are mandatory. Fill in any optional fields according to your requirements. These might involve extra network service specific details or configurations. Check the entered information to guarantee its correctness. Once the Create button is clicked to submit the form, the system will handle the request and create the new network service. Meanwhile binding it to associated sites and updating the Deployment Readiness Status in the sites page.
Note:
· If the Check Connectivity option is set to true, please ensure that the Connectivity Check Protocol field is filled with the appropriate supported protocol (TCP, DNS, NTP, HTTP, HTTPS, SSH, PING, SOCKS). If a specific port is required, include the port information (e.g., HTTPS, Port 443), otherwise, the default port for the specified protocol will be used.
· If the Check Connectivity option is set to true, please ensure that the Number of Retries field is populated with a numeric value between 1 and 10, indicating the desired number of retry attempts.
· Ensure that all required fields are filled out before attempting to create the network service. · If there are any validation errors, the network service will not be created, and you will need to correct the
errors before proceeding. · After the network service is successfully created, it may take some time for the system to fully configure
and display the new network service in relevant lists or dashboards.
Update a network service:
Starting with LOC-A version of 3.4, you can click the Edit button to update a network service, it will pop up a page to guide the update process. It is similar to the Creation operation.
Page | 36
LOC-A Core Framework User Guide
Figure 26: Update a network service
Note:
If this network service is being used by an instance that is currently being deployed, modification of it will be prohibited.
If this network service has already been used by an instance, the Role cannot be modified, and the Associated Sites must include the site where the instance is located.
When performing instance planning/onboarding and device registration, it is recommended not to modify the network service to avoid failure in subsequent processes.
Modifying the network service will not affect the already created instances. The content of the instances will not change with the change of network service information.
Delete a network service:
LOC-A Core Framework User Guide
Page | 37
To delete one or more network services, select the network services to be deleted and click Delete. The deletion may take several seconds. After the deletion is complete, the page will be automatically refreshed with the updated results.
Note: If a mandatory network service is deleted, a site will not be eligible for cloud deployment.
Cloud services
Cloud services are the essential cloud-specific services for cloud deployment, such as vCenter for a VMware vSAN cluster deployment. You also need to provide credentials of the cloud services for LOC-A to perform automated tasks. LOC-A supports an automated connectivity check for cloud services during server nZTP registration process. The cloud service name needs to be unique within LOC-A.
A cloud service can be allocated for one or more sites. You can specify a site list separated by commas. You can also specify any, which means the cloud service will be allocated for all sites.
Cloud services will be associated to the site in the order of affinity. For example,
· vCenter1 is defined for siteA, siteB, · vCenter2 is defined for siteA · vCenter3 is defined for any
In this scenario, the vCenter server planned for siteA and siteB are:
· siteA: vCenter2 · siteB: vCenter1
If Check Connectivity is checked, this cloud service is checked for connectivity during nZTP server registration. The number of retries parameter is used to determine the number of times to check for cloud service connectivity.
Starting from the LOC-A 3.1 release, Site deployment readiness check will also check for the sanity of cloud service credentials. Sites with cloud services that don’t have required credential information provided will appear notReady until you fix the metadata. On the other hand, it’s also not valid if you provide wrong credentials to cloud services that don’t support them.
LOC-A supports the following cloud service types:
Cloud Service Role Lenovo LXCA
Lenovo LXCO
Platform Type Hardware management
Hardware management
Credential Required Yes (no readiness check enforced, but you may fail to add/remove devices)
Yes (no readiness check enforced, but you may fail to add/remove devices)
Description
Lenovo xClarity Administrator (LXCA) is Lenovo’s system hardware management solution that runs as a virtual appliance. LOC-A supports synchronizing devices to external hardware management tools like LXCA. If you have the LXCA service defined for one or more sites, LOC-A will automatically add the devices that are registered to LOC-A into the LXCA instance. See the section – Adding devices into external hardware management tools for more information. Lenovo xClarity Orchestrator (LXCO) is a Lenovo system hardware management solution that provides centralized monitoring, management, provisioning, and analytics for environments with large numbers of devices. LOC-A supports synchronizing devices to an external LXCO instance. If you have the LXCO service defined for one or more sites, LOC-A will
Page | 38
LOC-A Core Framework User Guide
Lenovo Management Hub Lenovo LXCI
vCenter
Hardware management
VMware ThinkAgile VX Cluster(vSAN)
Yes (no readiness check enforced, but you may fail to add/remove devices) Yes, username must be “admin”
VMware ThinkAgile VX Cluster(vSAN)
Yes, user must be administrator role. Username should follow the format administrator @your_domain_ name, where your_domain_n ame is the Single Sign-On (SSO) domain you specified during vCenter Server deployment
automatically add the devices that are registered to LOC-A into the LXCO instance. Note that at least a Lenovo Management Hub (for ThinkEdge Client devices) or Lenovo LXCA (for Lenovo servers) instance must exist for the LXCO instance as a connected resource manager, so that devices can be added into LXCO. See the section – Adding devices into external hardware management tools for more information. Lenovo xClarity Management Hub is the LXCO resource manager that manages, monitors, and provisions ThinkEdge Client devices.
Lenovo XClarity Integrator for VMware vCenter provides IT administrators with the ability to integrate the management features of Lenovo XClarity Administrator and ThinkSystem, Flex System, System x and BladeCenter systems with VMware vCenter. Lenovo expands the virtualization management capabilities of VMware vCenter with Lenovo ThinkSystem hardware management functionality, providing affordable foundational, basic management of physical and virtual environments to reduce the time and effort required for routine system administration. It provides the discovery, configuration, monitoring, event management, and power monitoring needed to reduce cost and complexity through server consolidation and simplified management. Adding devices into external hardware management tools The VMware vCenter appliance is mandatory for the vSAN cluster. You must provide vCenter management credentials so that LOC-A can add nodes into the vCenter instance and create a vSAN cluster. One vCenter instance can be shared for multiple sites. Refer to the VMware documentation on how to setup a vCenter instance, and the maximum number of clusters and nodes that can be managed by one vCenter instance. vCenter selection policy during a new vSAN cluster deployment: 1. User can specify any external vCenter for vSAN cluster deployment. In this case it’s the user’s responsibility to install the vCenter and upload vCenter info with an “active” status with cloud setup metadata before deployment. 2. If the user needs LOC-A to deploy a vCenter for a vSAN cluster. The vCenter info should be uploaded in cloud setup metadata with the vCenter status as “inventory”. Then the installation will be automatically triggered during the vSAN cluster deployment. LOC-A will deploy the vCenter instance
LOC-A Core Framework User Guide
Page | 39
on one of the vSAN clusters that will be managed by this vCenter.
AssistedInstaller
RedHat
No
An instance of RedHat OpenShift Container Platform
OpenShift
Assisted Installer (AI) is mandatory for OCP cluster
Container
deployment. One AI instance can be used to deploy
Platform
multiple site clusters.
(OCP)
Refer to RedHat documentation on how to setup an
AI instance.
Note:
There are three options for setting the connection
address of the AI:
1. In the IP/FQDN/URI field, specify the URI. The
protocol and port number are required. For example:
https://x.x.x.x:443.
2. In the IP/FQDN/URI field, specify the IP or FQDN.
Meanwhile, set the Check Connectivity field to true,
and fill in the protocol and port number in
Connectivity Check Protocol and Connectivity Check
Port respectively.
3. In the IP/FQDN/URI field, specify the IP or FQDN
without performing a connectivity check. By default,
the http protocol and port 80 will be used by LOC-A.
If you deployed AssistedInstaller with default port
8080, please make sure you specify the right port in
IP/FQDN/URI field. For example: http://x.x.x.x:8080.
Table 9: Cloud Service Types supported by LOC-A
Figure 27 shows the listing of cloud services on the Cloud Services page.
Figure 27: Cloud services list
View a cloud service’s details:
You can view a cloud service’s details by clicking on one cloud service.
Page | 40
LOC-A Core Framework User Guide
Figure 28: Cloud service detail
Create a cloud service:
Starting with LOC-A version of 3.3, you can click the Create button to create a cloud service, it will pop up a page to guide you through the creation process.
LOC-A Core Framework User Guide
Page | 41
Figure 29: Create a cloud service
Fill in the required fields. These typically include:
· Name*: Enter the name of the cloud service. · Platform Type*: Select the platform type. · Role*: Select the network service role, it must be a role that is defined for the platform type. · Software Version: Specify the software version of the cloud service.
Page | 42
LOC-A Core Framework User Guide
· Associated Sites*: Select the associated sites. · IP/FQDN/URI*: Specify the service’s access address. · Admin User: Specify the admin user. · Admin Password: Specify the admin password. · Check Connectivity*: Used for connectivity check. · Connectivity Check Protocol: Specify the protocol for the connectivity check. · Connectivity Check Port: Specify the port for the connectivity check. · Number of Retries: Specify the number of retries. · Status*: Select the status from the list, inventory or active.
If the service role has the configuration requirements for Service Settings, and Status is inventory, this part will be automatically added to the page, as shown in the figure above. The fields for Service Settings are specific to the service role.
For vCenter role, the Service Settings fields are:
· Root Password*: Specify the expected root password for the vCenter to be deployed. · Install Site*: Specify the expected site for the vCenter to be deployed. · Management IP*: Specify the expected management IP for the vCenter to be deployed.
For LXCI role, the Service Settings fields are:
· Management IP*: Specify the expected management IP for the LXCI to be deployed. · BMC IP: Specify the expected BMC IP for the LXCI to be deployed.
The fields marked with an asterisk (*) are mandatory. Fill in any optional fields according to your requirements. These might involve extra cloud service specific details or configurations. Check the entered information to guarantee its correctness. Once the Create button is clicked to submit the form, the system will handle the request and create the new cloud service. This includes binding it to associated sites and updating the Deployment Readiness Status in the sites page.
Note:
· The cloud services you input may include sensitive data such as admin credentials. Please make sure you protect this document and keep it in a secured location. Once you create the cloud service, LOC-A will extract the data and encrypt the credentials in the LOC-A DCIM system at rest.
· If the Check Connectivity option is set to true, please ensure that the Connectivity Check Protocol field is filled with the appropriate supported protocol (TCP, DNS, NTP, HTTP, HTTPS, SSH, PING, SOCKS). If a specific port is required, include the port information (e.g., HTTPS, Port 443), otherwise, the default port for the specified protocol will be used.
· If the Check Connectivity option is set to true, please ensure that the Number of Retries field is populated with a numeric value between 1 and 10, indicating the desired number of retry attempts.
· If the status of vCenter/Lenovo LXCI is set to active, the Service Settings field must be empty. · If the status of Lenovo LXCI is set to inventory, the Service Settings field needs to be input with
Management IP, BMC IP is optional. · The vCenter/Lenovo LXCI cannot be updated when the status is staged or active. · The Lenovo LXCI is a vCenter plugin, so the Lenovo LXCI status cannot be active when the vCenter is not
active. · Ensure that all required fields are filled out before attempting to create the cloud service. · If there are any validation errors, the form will not submit, and you will need to correct the errors before
proceeding. · After the cloud service is successfully created, it may take some time for the system to fully configure and
display the new cloud service in relevant lists or dashboards.
LOC-A Core Framework User Guide
Page | 43
Edit a cloud service:
LOC-A also supports editing an imported cloud service in the GUI. To edit a cloud service, the service needs to meet the conditions documented below. If the conditions cannot be met, the corresponding field cannot be edited.
Conditions of cloud service editing:
Cloud Service Status Inventory
Active
Active
Is deployed by Used by
Instance status Editable fields
LOC-A
Instance
Yes, No
No
Any value
Site List, IP/FQDN/URI, Check
Connectivity, Number of Retries,
Protocol, Port, Credentials, Service
Settings
No
No
Any value
Site List, IP/FQDN/URI, Check
Connectivity, Number of Retries,
Protocol, Port, Credentials, Service
Settings
Yes
Yes
Onboarded, IP/FQDN/URI, Check Connectivity,
Failed
Number of Retries, Protocol, Port,
Credentials, Service Settings
Table 10: Conditions of cloud service editing
Complete the following steps for editing the imported metadata of a cloud service: 1. Go to Setup page then click Cloud Services. Select a cloud service and click the Edit icon.
Figure 30: Cloud service edit Note: Edit will be disabled when you select multiple cloud services. 2. After clicking the Edit icon, the Cloud Service editing page pops up.
Page | 44
LOC-A Core Framework User Guide
Figure 31: Cloud service editing page 3. Edit Site List: click on the Site List dropdown menu and select one or more sites.
Figure 32: Site list of the cloud service
Note: You can click the X button to clear selected sites. 4. Edit IP/FQDN/URI:
Figure 33: IP/FQDN/URI of the cloud service Note: IP/FQDN/URI is a mandatory field. IPv4, IPv6, FQDN, or URI formats are allowed. 5. Edit Check Connectivity:
LOC-A Core Framework User Guide
Page | 45
Figure 34: Check the Connectivity of the cloud service Note: Check Connectivity is a mandatory field. If the Check Connectivity is true, The Number of Retries, Protocol and Port can be edited. 6. Edit Number of Retries for connectivity check:
Figure 35: Number of Retries of the cloud service Note: Number of Retries is a mandatory field if Check Connectivity is true and the input limit is 1 to 10. 7. Edit Protocol for connectivity check:
Figure 36: Protocol of the cloud service
Note: Protocol is a mandatory field if Check Connectivity is true. Click the X button to clear the selected protocol.
8. Edit Port:
Figure 37: Port of the cloud service Note: Port is a mandatory field if Check Connectivity is true. The range of ports must be 0 to 65535. 9. Edit Credentials:
Page | 46
LOC-A Core Framework User Guide
Figure 38: Credentials of the cloud service a. You will only be allowed to edit credentials for the type supported by this cloud service. Click the
input of the Account field to edit the Account for the specified credential. b. Click the input of the Password field to edit the Password for the specified credential. (Note: click the
eye button to show and hide the password). Note:
· For security purposes, you will not be able to view the existing plaintext password value in the Password field. You can modify the current password by inputting the new password value. If the password is specified through an external vault system, you can view the secret path value with format @@@VaultName@@@SecretPath in the Password field. You can modify the secret path value if it’s a read-only Vault Instance. You can also modify it to use a password string instead.
· User cannot remove the username or password for credentials entries from the GUI. In order to remove the credential, you will have to upload a new setup template having these fields empty.
10. Edit Service Settings:
Figure 39: Service Settings of the Cloud Service Click on each field of the Service Settings and edit the data. Service settings fields may vary for different cloud service roles. If there are no service settings available for a cloud service role, this section will not be displayed. An error is shown if the input for a required field is empty.
LOC-A Core Framework User Guide
Figure 40: Service Settings check
Page | 47
11. Click Save to save the modified Cloud Service. The cloud service list page will be automatically refreshed and reloaded.
Note:
· If one supervisor is modifying the metadata of a cloud service, others should not start the Instance Planning and Readiness check workflow simultaneously, otherwise it may result in out-of-date data being used to deploy instances.
· After you have modified Cloud Services/Network Services/IP Ranges/Sites, you may need to re-generate Registration Packages to update to the latest metadata for your server registration.
Credential policy
LOC-A provides the credential policy feature to manage the approaches for configuring BMC, UEFI, and OS credentials. The BMC and UEFI approaches include support for static passwords and dynamically generated passwords. For OS, the public key approach is also included along with static passwords and dynamically generated passwords.
Figure below shows an example page that lists credential policies:
Figure 41: Credential Policy list
Create a credential policy:
Follow these steps to create a credential policy 1. Click Setup Credential Policies, click the Add icon. 2. Input the Name of the credential policy.
Note: Name must start with a letter and can only contain letters, numbers, underscores, and hyphens. The length of the name should be between 2 and 50 characters.
3. Select the Kind of credential.
Note: Kind is a dropdown list that includes three types, which are BMC, UEFI and OS.
Page | 48
LOC-A Core Framework User Guide
4. Select the Approach of the credential.
Note:
a. Approach includes static, auto, and publicKey. Static indicates the need for manual password input, auto requires the input of a password template, and publicKey indicates the use of a public key.
b. Starting from LOC-A 3.1, you will not be allowed to create an auto credential policy if you don’t have an external read-write vault registered. Please refer to Vault secrets management for more details.
c. If you apply the same static credential policy to multiple devices, make sure you are aware of the potential security posture because all devices will have the same password. This is usually not recommended because it is not secure.
d. If a dynamic credential policy is applied to multiple devices, it means that different devices will have different random unique passwords generated by LOC-A that will be written to the external vault that is registered with LOC-A.
5. Click the Create button.
The following is an example of creating a credential policy with the approach of static:
Figure 42: Credential Policy creation with the approach of static The following is an example of creating a credential policy with the approach of auto:
LOC-A Core Framework User Guide
Page | 49
Figure 43: Credential Policy creation with the approach of auto
Modify a credential policy:
Follow these steps to modify a credential policy
1. Click SetupCredential Policies, select a credential policy, click on the Edit icon in the upper right corner. 2. Modify the Name of the credential policy. 3. Modify the Password Template of the credential.
Note: This one is editable only when credential approach is auto.
Password Template:
· Supported built-in template variables that can be used are: – {{random_characters(N)}}: where N is the length of the random string. For example{{random_characters(32)}} will be a random string of 32 characters. – {{last_characters(BMC_MAC_address,N)}}: where N is the length of the last characters of the BMC MAC address of the node. N needs to be between 1 and 12. The length of the password should be between 10 and 32 characters.
For OS type, both {{random_characters(N)}} and {{last_characters(BMC_MAC_address,N)}} template variables are supported. For the BMC and UEFI type, only {{random_characters(N)}} is supported. · The rendered password length should be between 10 and 32 characters for BMC, between 8 and 20 characters for UEFI and between 10-32 characters for OS, in case of the auto approach. 4. Click the Save button.
The following is an example of modifying a credential policy with an approach of auto.
Page | 50
LOC-A Core Framework User Guide
Figure 44: Credential Policy edit with the approach of auto The following is an example of modifying a credential policy with an approach of static.
Figure 45: Credential Policy edit with the approach of static
Note:
· When approach is auto, users are only allowed to modify the name and password template of the credential policy.
· When approach is static, users are only allowed to modify the name of a credential policy. · After modifying a credential policy, if this credential policy is used by a template, the template will
also be updated to use the modified credential policy.
Delete a credential policy:
Follow these steps to delete a credential policy
1. Click SetupCredential Policies, select a credential policy, click on the Delete icon in the upper right corner.
LOC-A Core Framework User Guide
Page | 51
2. Click the Delete button to confirm deletion. Note: If a credential policy is in use by one or more templates, the credential policy will not be allowed to be deleted.
Device profiles
LOC-A will create default device profiles for each flavor based on the best recipe. The default device profiles are allowed to be modified and deleted. It should be noted that the configuration items belonging to the best recipe in the default device profiles cannot be changed. In addition, users are also allowed to create new device profiles on their own. A device profile defines the server BMC and UEFI configurations for the cloud flavor. Device profile is required when creating templates and the BMC/UEFI configurations defined in the device profile will be applied when deploying the cloud/OS instances.
Figure 46: Device Profiles list
View a device profile’s details:
You can view a device profile’s details by clicking on one device profile.
Page | 52
LOC-A Core Framework User Guide
Figure 47: Device Profile Detail
Create a device profile:
Follow these steps to create a device profile 1. Click Setup Device Profiles, then click on the Add icon in the upper right corner. 2. After flavor and models supported by the flavor are selected, the configuration items that belong to the best recipe of the current model are forcibly added and not allowed to be modified. 3. Enter the name of the newly created device profile. 4. You can click the Add Field button to add more configurable BMC and UEFI items. 5. Click the Save button in the bottom right corner to save the creation.
Note: When adding a configuration item, if the configuration item has a dependent configuration item, the dependent configuration item is automatically added. Similarly, when you delete a dependency for a configuration item, that configuration item is deleted along with it.
LOC-A Core Framework User Guide
Page | 53
Figure 48: Create Device Profile
Modify a device profile:
Follow these steps to modify a device profile
1. Click Setup Device Profiles, select a device profile, then click on the Edit icon in the upper right corner. 2. Add, delete, or modify the current BMC, UEFI configuration. Same as creating, the configuration items
that belong to the best recipe of the current model are not allowed to be modified. 3. Click the Save button in the bottom right corner to save the change.
Note:
· When adding a configuration item, if the configuration item has a dependent configuration item, the dependent configuration item is automatically added. Similarly, when you delete a dependency for a configuration item, that configuration item is deleted along with it.
· The device profiles being used by instances are not allowed to be modified.
Page | 54
LOC-A Core Framework User Guide
· For device profiles that are being used by templates but not by instances, if this device profile is modified, the configuration of the device profile in the template will also change accordingly.
Figure 49: Modify Device Profile
Note:
· Currently, there is no configuration option for the vSAN flavor. Delete device profiles:
Follow these steps to delete a device profile 1. Click Setup Device Profiles, select one or more device profiles, click on the Delete icon in the upper right corner. 2. Click Delete button to confirm deletion.
Note: Any device profile currently being used by a template or instance cannot be deleted.
LOC-A Core Framework User Guide
Page | 55
Generate LOC-A registration packages
LOC-A provides various methods to add devices into the inventory. For edge-site server nodes, we recommend you use the nZTP (near zero-touch-provisioning) approach to register the devices using a LOC-A registration package via a USB key or the Lenovo Open Cloud Automation Utility. For other approaches to device registration, see Register devices on page 59.
The LOC-A registration package contains site metadata information and other necessary artifacts for nZTP device registration. After importing the edge sites resources metadata, you can generate and then download the LOC-A registration package to facilitate edge-site server node registration. To create a new registration package, click SetupDevice RegistrationCreate. LOC-A supports generating an image for a USB key or for Lenovo Open Cloud Automation Utility.
Generate USB type package
The USB type registration package is a bootable mini-OS image that can be loaded to a USB key for on-site device registration.
Figure 50: Create USB type registration package
1. Select USB and enter the number of days until the image expires. 2. Choose a passphrase type. The registration package for the USB key is passphrase protected.
· Select Auto-generate passphrase to let LOC-A generate the passphrase automatically. · Select Use static passphrase to enter your passphrase.
The passphrase will be needed later when you perform server registration. See the section Register devices for more information.
Page | 56
LOC-A Core Framework User Guide
3. Click Create to start generating the package. It usually takes several minutes for the task to complete. You can refresh the page or view progress of the task in the Tasks page. Upon completion, an image is shown in the Image List and is ready for download. The passphrase (automatically generated or user defined) is listed in the Passphrase column.
Figure 51: Registration package list 4. Select the image and click the Download icon to download the package. The .IMG file is typically around
96 MB. After downloading the file, you can use tools like ImageWriter or Rufus to flash the bootable image file on a USB key. Ensure that the enable bootable image option is used. Next, you can refer to the section Register devices to register devices via USB key.
Note: If your site resources in Setup are changed (e.g., added new sites, modified IP ranges), you need to regenerate the registration package to include the latest metadata.
Generate near-Zero Touch Provisioning type package
near-Zero Touch Provisioning type registration package is a .tar file for the Lenovo Open Cloud Automation Utility to use. It includes all the metadata required for registration and is encrypted. After populating the edge sites resources metadata and creating the BMC credential policy, you can generate a LOC-A registration package to facilitate edge-site server node registration.
LOC-A Core Framework User Guide
Page | 57
Figure 52: Create near-Zero Touch Provisioning type registration package
1. Select near-Zero Touch Provisioning and enter the number of days until the image expires. 2. Choose a passphrase type. The near-Zero Touch Provisioning registration package is passphrase
protected. · Select Auto-generate passphrase to let LOC-A generate the passphrase automatically. · Select Use static passphrase to enter your passphrase.
The passphrase will be needed later when you perform server registration through the Lenovo Open Cloud Automation Utility. See section Register devices for more information.
3. Select the expected BMC new password policy. Input BMC new password if the credential policy is of static approach type. During the on-site server registration, LOC-A will follow the password policy to configure the BMC’s new password.
4. You can optionally select UEFI new password policy as well for setting the UEFI admin password.
Page | 58
LOC-A Core Framework User Guide
5. You can optionally enable Preload OS image to XCC to sideload OS images on the XCC. Please refer to OS Image Sideloading section below for more details.
Click Create to start generating the package. It usually takes several minutes for the task to complete. After downloading the package file, you will need to download the Lenovo Open Cloud Automation utility on your Windows desktop and refer to section Register devices to register devices via the Lenovo Open Cloud Automation Utility.
Download Lenovo Open Cloud Automation Utility
Lenovo Open Cloud Automation Utility is a Windows desktop application designed to assist in provisioning and registering edge servers. Each utility software package is specific to a particular LOC-A portal instance. Therefore, you must download the software package corresponding to your LOC-A portal instance.
Click Download Lenovo Open Cloud Automation – Utility to download the utility.
Figure 53: Download Lenovo Open Cloud Automation Utility
Register devices
There are several methods to register servers into LOC-A inventory. For typical edge scenarios, it is recommended that the user register devices using the LOC-A registration package via USB key or through the LOC-A Automation Utility. These two approaches include a connectivity check of related network services and cloud services for the site; the cabling for edge nodes and the network facilities are verified before remote cluster deployment. For datacenter scenarios, you can also register new devices through automatic discovery in the layer 2 or layer 3 network or by manually entering them using Add device or by uploading a cloud setup template Excel file.
Register devices via Lenovo Open Cloud Automation Utility
Follow the section Device Registration to generate and download a registration package and download the registration utility.
After downloading the software package Registration-tool-<LOC-A_version>.zip:
1. Extract it to your Windows laptop.
2. Go to the directory and you should be able to find LOC-A_Registration_Utility.exe file. This is the executable file for the software.
Cabling
1. Make sure you have unboxed the server and followed the network requirements of your cloud deployment plan to cable the server Ethernet Adapter ports properly.
2. For servers that are straight out of the box and unconfigured, connect your laptop Ethernet port to the XCC RJ45 Ethernet management port directly. If your laptop does not have an RJ45 Ethernet port, you can use a USBEthernet adapter for the connection. If the XCC(BMC) already has an IP address set, then use the planned network to remotely connect the laptop to the XCC(BMC).
LOC-A Core Framework User Guide
Page | 59
Using the utility
1. Double click LOC-A_Registration_Utility.exe to launch the desktop application. You will need administrator permission to run the application. Click the Next button to proceed to the Prepare Setup page. Note: Only one application instance can run on the same desktop machine at a time.
Figure 54: LOC-A Registration Utility – Prepare Setup
2. Click the Load button and load the near-Zero Touch Provisioning type registration package that you
downloaded from the LOC-A portal and then enter the same passphrase used when the package was created.
Page | 60
LOC-A Core Framework User Guide
Figure 55: Load registration package
3. Select BMC(XCC) Connection Type
a. Use pre-configured BMC IP mode: In this mode, your server XCC(BMC) is already configured with an IP and is connected properly in the planned XCC(BMC) network. LOC-A attempts to connect and provision the server XCC(BMC) through Ethernet IPv4 address. You will need to input the existing IP address of XCC(BMC). Please make sure the network is reachable between the device that the registration utility is running upon and the XCC(BMC) Ethernet IP address.
b. RJ45 Direct Connect mode: In this mode, your server is factory default without pre-configuration. LOC-A attempts to connect and provision the server XCC(BMC) management port through direct RJ45 connection. Please ensure you have completed the cabling. You will also need to select the local network card on the laptop you are connecting to the server.
LOC-A Core Framework User Guide
Page | 61
Figure 56: Use pre-configured BMC IP
Page | 62
LOC-A Core Framework User Guide
Figure 57: RJ45 Direct Connect
4. Configure BMC Credentials Settings
If the server is factory default, you can choose the Use BMC factory default credentials checkbox, then the current username will be USERID and current password should be PASSW0RD (note that the `O’ is a zero).
If the server’s credentials were previously changed, you need to unselect the Use BMC factory default credentials checkbox and input the current password manually so the LOC-A Utility can connect to the server properly. Current username needs to be USERID.
BMC new password is set according to the BMC credential policy you selected when you generated the registration package, so you will not set it in the utility.
Click Next to continue to the next page.
LOC-A Core Framework User Guide
Page | 63
Figure 58: Input current password manually
5. Select Site
Select the proper site that you want to register your server into. After you have confirmed all the inputs are correct, click Register, this will trigger the automatic server registration process.
Page | 64
LOC-A Core Framework User Guide
Figure 59: Select Site
6. Server Registration
A workflow will launch automatically which includes the following content:
· Change BMC password: change XCC(BMC) password. · Set up BMC configuration: configure XCC(BMC) network settings and configure port forwarding. · Mount image and change boot order: mount the LOC-A mini-OS image. · System startup and start registration agent: boot system into the mini-OS image where the LOC-A
registration client will run. · Configure BMC IP: set the BMC IP according to the planned site metadata. LOC-A will automatically find an
available BMC IP for this site. · Server connectivity check: perform connectivity check according to the planned site metadata. Network
and cloud services for this site will be checked to make sure the server is properly cabled. · Sideload image: optionally sideload the OS image to the server · Register server: LOC-A registration client will collect server inventory and register the server to the LOC-A
portal.
You can click the Retry button if any steps of the workflow fail. When the server completes the registration, it will be shown in the Registered Devices list on the LOC-A portal.
LOC-A Core Framework User Guide
Page | 65
Figure 60: Register server through LOC-A Registration Utility
Error Recovery
In the LOC-A automatic registration process, passwords for the BMCs will be changed. However, when certain steps in the process fail, resulting in incomplete registration, users may attempt to reopen the utility and execute the automation process again. In this situation, the LOC-A Utility records the server registration failing point and provides recovery. The next time the utility starts, if there are servers that failed to register before, the utility will prompt the user whether to continue registering the server. If you want to continue registering, you need to select the corresponding Serial Number and click OK. If you are attempting to register another server, click CANCEL and all processes will proceed normally.
Page | 66
LOC-A Core Framework User Guide
Figure 61: Error recovery
Log
The logs for the LOC-A Utility are located at: C:Users%USERPROFILE%DocumentsLOCA_Utility_logsxxx.log. In case you need Lenovo Support, please send the log fille to the Lenovo support team. Max size of the log file is 1M, when the max size is reached, it will be backed up to xxx.old.log. Only 1 backup log file is preserved.
Register devices via USB key
You can use the USB key to register edge site server nodes to the LOC-A Core Framework appliance. Prerequisite Make sure you have Ethernet Over USB enabled with BMC IP address set to 169.254.95.118 (default). This can usually be configured through the BMC interface to the server. Figure 62: Ethernet Over USB shows an example configuration through the XCC user interface.
LOC-A Core Framework User Guide
Page | 67
Figure 62: Ethernet Over USB
Complete the following steps to register devices using a USB key: 1. Boot from USB key. a. Attach a Keyboard/Video/Mouse (KVM) to the server or open a Remote Media Console from server XCC user interface. b. Insert the bootable USB key that you created in one of the USB ports of the system. c. Boot the server into the bootable image by pressing F12 during the boot process and selecting the USB device.
Note: If you are using the XCC Remote Media console, you can also mount the .IMG file through the XCC Remote Media Console and choose to reboot the server from the image.
2. Register the server. a. After the server is booted, enter the encryption password you received or defined during registration package creation.
Figure 63: Input encrypt password
b. Change XCC password. To change the XCC password in this step. You will need to enter the original XCC password and then the new credential.
Page | 68
LOC-A Core Framework User Guide
Figure 64: Change XCC password
c. Configure the server. Select the expected site to which your device will be registered and enter the correct IP address. The XCC IP needs to align with the one specified during the Ethernet over USB configuration (the default is 169.254.95.118).
Figure 65: Config the server
Note: The output appears only when choosing Option 1. d. Register the server.
After the server is configured, an action menu is displayed. Choose action 3 to register the server directly. If the connectivity check was not performed earlier, LOC-A will attempt the connectivity
LOC-A Core Framework User Guide
Page | 69
check first. If the check is successful, this server is registered. If the check fails, check the cabling and use action 2 (connectivity check) to re-check the connectivity until the check is successful.
Figure 66: Register the server e. Configure the XCC IP address (optional).
Use action 5 to assign an IP from the XCC IP address range for the site to the XCC automatically.
Figure 67: Config the server
f. Reconfigure the server (optional). If the server registration failed because of an incorrect configuration, such as selecting the wrong site or entering the wrong credentials, use action 1 (config the server) to reconfigure the server.
g. Update customer site (optional) If the site information inside the image is not up to date, use action 4 (update customer site) to update the site information from the LOC-A Core Framework appliance.
Page | 70
LOC-A Core Framework User Guide
After you have completed server registration, unplug the USB key from your server. Repeat the same steps to register other server nodes in the edge sites. In the LOC-A portal GUI, you can find all registered devices listed on the Registered Devices page.
Add devices by Discovery
You can use LOC-A to discover server nodes within the same layer 2 network or accessible layer 3 network, and add them into LOC-A inventory. LOC-A offers two discovery methods: Layer 2 and Layer 3. The Layer 2 method discovers devices within the same broadcast domain as the LOC-A appliance, while the Layer 3 method discovers the BMC IP range assigned to each site, requiring the IP allocation strategy field of the IP range to be user-allocated. Complete the following steps to register devices through automatic discovery within the same layer 2 network:
1. Click Registered DevicesAdd DeviceAdd Device by Discovery.
Figure 68: Add devices by discovery 2. Check L2 Discovery and click the Discover button on the right. Wait for a few minutes, and the discovered
devices will be displayed below. Check the device you want to register and click next.
LOC-A Core Framework User Guide
Figure 69: L2 Discovery
Page | 71
3. Make sure the site from which you want to register devices has a BMC network pre-planned in the Setup so that LOC-A can ensure that the BMC IP is within the planned BMC IP range. Otherwise, there will be no data in the Site Available Nodes. For sites with LOC-A allocated IP allocation strategy for the IP range corresponding to the site, the Site Available Nodes will display all the devices you selected in the first step. For sites with an IP allocation strategy of User allocated IP range, Site Available Nodes will only display devices with IP addresses within the corresponding BMC IP range, because User allocated strategy means that the BMC IP of the site has been pre-configured by the user and cannot be modified.
Figure 70: The IP allocation strategy for the IP range corresponding to the site is LOC-A allocated
Page | 72
LOC-A Core Framework User Guide
Figure 71: The IP allocation strategy for the IP range corresponding to the site is User allocated
Users can check the devices in the site available nodes and click the plus sign in the upper right corner to move them to the selected nodes below. Similarly, users can also select a device from the selected nodes and click on the trash can icon in the upper right corner to move the device to the available nodes.
Figure 72: Selected Nodes After assigning all the devices, click Next in the bottom right corner.
LOC-A Core Framework User Guide
Page | 73
4. On the BMC/UEFI configuration page, specify BMC and UEFI new password policy and reconfigure BMC IP addresses. As each site has a BMC IP range defined, the new BMC IP address for each node can be selected from the dropdown list of available IP addresses in the BMC IP range. Specify existing BMC and UEFI passwords as well in the case that the server is not using a factory default configuration. Note: When the IP allocation strategy of the BMC IP range corresponding to the site is User allocated, its BMC IP cannot be changed.
Figure 73: BMC/UEFI config
5. After completing the form, click Done to start the registration process. You can view the progress of the registration process from the Tasks page.
After the task has been completed, you can see the server in the list of registered devices.
Complete the following steps to register devices through automatic discovery via a layer 3 accessible network: 1. User needs to configure, in advance, the IP addresses of the XCC devices (by static allocation or through DHCP) 2. In the Cloud Setup Template document, the user would need to configure as User allocated the IP Allocation Strategy column for an IP range of BMC role as in the following example:
Page | 74
LOC-A Core Framework User Guide
Figure 74: Set User allocated strategy 3. Similar to the steps of L2 Discovery, you need to select L3 Discovery in the wizard. LOC-A exclusively
discovers IP ranges within a site where the IP allocation strategy is set to “User Allocated”.
Figure 75: L3 Discovery
LOC-A Core Framework User Guide
Page | 75
4. LOC-A will automatically match the discovered devices to the corresponding sites based on the IP range corresponding to each site.
Figure 76: Automatic allocation of devices
5. In the BMC/UEFI Config dialog, the BMC Assigned IP column is N/A, since the IP allocation strategy for the IP range corresponding to this site is User allocated, it means that all BMC IPs in this site are preconfigured by the user and cannot be changed.
6. Figure 77: BMC/UEFI Config
7. After completing the form, click Done to start the registration process. You can view the progress of the registration process from the Tasks page.
Page | 76
LOC-A Core Framework User Guide
After the task has been completed, you can see the server in the list of registered devices.
Note:
· The XCC IP of the target server must not conflict with the “XCC IP” setting configured on the LOC-A appliance
· Multiple sites should not use the same XCC IP address range · For L3 discovery, in order to ensure device discovery, it is necessary to ensure that the LOC-A appliance
has access to the IP range whose IP allocation strategy is User allocated on the network.
Add device by BMC IP
You can add a single device into LOC-A inventory by manually entering the BMC information. Complete the following steps to add a device using the BMC IP address:
1. Click Registered DevicesAdd DeviceAdd Device by BMC IP. 2. Select the site to which the BMC will be added and click Next. 3. In BMC configuration page, enter the BMC IP address, the BMC user ID and the existing BMC passwords. 4. Select BMC New Password Policy or keep it as No changes which means do not change the BMC
password. 5. Select UEFI New Password Policy or keep it as No changes which means do not change the UEFI password. 6. After completing the form, click Done to begin the registration process. You can view the progress on the
Tasks page.
Note: The BMC IP address you enter must be a valid IP address in the BMC(XCC) IP address range that you defined for your selected site.
Figure 78: Add device by BMC IP select site LOC-A Core Framework User Guide
Page | 77
Figure 79: Add device by IP BMC/UEFI Config
Figure 80: Task of adding devices 7. Once the device is processed, you will be able to view it in the Registered Devices list.
Page | 78
LOC-A Core Framework User Guide
Figure 81: Registered device list
Upload device Excel file
LOC-A also supports importing your devices in batches through an Excel file. Complete the following steps to import devices through an Excel file.
1. From the LOC-A web interface click Registered Devices -> Download Device Definition file template to get the sample Excel file “Device_Definition_Standard_Template.xlsx”, and follow the embedded instructions to fill in the file with the planning data for your devices.
2. Click Upload icon. 3. Click Browse to find the file that you created. 4. Select BMC New Password Policy or keep it as No changes which means do not change the BMC
password. 5. Select UEFI New Password Policy or keep it as No changes which means do not change the UEFI password.
In addition to these two options, you can also select Clear Password which means clear the UEFI password. 6. Click Upload to upload the file.
LOC-A Core Framework User Guide
Page | 79
Figure 82: Upload device Excel file 7. After the devices have been processed, you can view them in the Registered Devices list.
Adding devices into external hardware management tools
LOC-A provides integration with external device management tools like Lenovo xClarity Administrator (LXCA) and Lenovo xClarity Orchestrator (LXCO). If you have an external LXCA or LXCO instance defined for your sites, when new devices are registered into LOC-A, they can also be added automatically to LXCA for continued lifecycle management.
To enable this function, you need to define a cloud service with type Hardware management in your metadata Excel file. For example:
Name *
Platform Type*
Type*
Site List*
IP/FQDN*
Admin user
Admin password
Used for connectivity check*
lxca
Lenovo LXCA
Hardware management
any
lxca.global.cus
tom.local
xxx
xxxxx
Yes
Connectivity check protocol
Num of retries in connectivity check
HTTPS, Port 443
3
Figure 83: LXCA cloud service of Hardware management type
The LXCA or LXCO instance can either be an IP address or an FQDN that is resolvable by the DNS configured for the LOC-A Core Framework appliance. If you specify a site list, all nodes from those sites will be added to this LXCA instance.
A server node can only be managed by one LXCA instance. Therefore, the sites are associated with LXCA services in the order of affinity. For example, assume that you have two LXCA instances defined:
· LXCA1 is dedicated for siteA · LXCA2 has a site list of any.
In this scenario, new servers from siteA will be added to the LXCA1 instance.
Page | 80
LOC-A Core Framework User Guide
Note: Make sure that you provide the correct administrative credentials for the LXCA instance so that the nodes may be added to LXCA automatically when new servers are added to LOC-A.
Figure 84: Devices added into LXCA instance
Continuous devices discovery
Users can configure continuous discovery tasks for the deployment(s) to carry out scheduled automatic device discovery. Successfully discovered and registered devices will be shown in the registered devices list, whereas devices that fail registration will be placed in the discovered devices list, awaiting manual intervention. One continuous discovery task can be associated with one or multiple deployments. Please refer to section Automatic instance creation for Deployment and how to create a Deployment plan.
Once a deployment is bound to one continuous discovery task, it cannot be bound to other continuous discovery tasks. Furthermore, deployment with a continuous discovery task cannot be modified or removed. If you want to update or delete the deployment, you need to delete the associated continuous discovery task first. As an exception, the default deployment can be updated while a continuous discovery task is associated. User created sites and the templates, if not specified, will be automatically associated with the default deployment. If you associate the default deployment with a continuous discovery task, LOC-A will ensure continuous discovery is done with latest default deployment plan. For example, the devices of the newly added sites can be discovered and registered properly.
To discover the devices of a site properly, you will also need to make sure the template for the site’s flavor is created associated to the site’s deployment. Continuous discovery will only discover and register the devices that meet the requirements of the device models defined in the template. One exception is flavor type “LOC-A Basic”. For a site with flavor “LOC-A Basic”, LOC-A will discover and register devices regardless of the device model.
LOC-A offers two discovery methods: Layer 2 and Layer 3. The continuous discovery tasks only support Layer 3, which discovers the BMC IP range assigned to each site, requiring the IP allocation strategy field of the IP range to be user-allocated.
Each BMC IP range should only be bound to one site, and each BMC IP range must not overlap with others. The continuous discovery task will discover devices whose IPs are within the BMC IP ranges and assign each discovered device to the corresponding site according to the mapping between the machine BMC IP and the site defined BMC IP range.
Note: The name of the continuous discovery task must be unique within LOC-A.
Go to Registered devices page then click Continuous Discovery Tasks tab. You can view list of continuous discovery tasks. The below figure shows an example page that lists the continuous discovery tasks:
LOC-A Core Framework User Guide
Page | 81
Figure 85 : Continuous discovery task list
Create a continuous discovery task:
You can click the Create button to create a continuous discovery task, and a page will pop up to guide the user through the creation process.
Page | 82
LOC-A Core Framework User Guide
Figure 86: Create a continuous discovery task
Fill in the fields for the continuous discovery task creation. These typically include:
Name*: Enter the name of the continuous discovery task. The name of the continuous discovery should be unique.
Deployments*: Select the associated deployments. Interval*: Enter the interval. The unit of the interval is seconds. The next execution time of the task is the last
execution time of the task plus the interval. If the interval is too short, the next task execution will be postponed until the previous task is completed. BMC Username*: Enter the BMC username. The BMC username should be “USERID”. BMC Current Password*: Enter the current BMC password. BMC New Password Policy*: Select BMC New Password Policy or keep it as “No changes” which means do not change the BMC password.
LOC-A Core Framework User Guide
Page | 83
UEFI administrator Current Password: Set the UEFI administrator current password. UEFI New Password Policy*: Select UEFI New Password Policy or keep it as “No changes” which means do not
change the UEFI password.
The fields marked with an asterisk (*) are mandatory. Fill in any optional fields according to your requirements. Once the Create button is clicked, the system will handle the request and create a new continuous discovery task. If there are any validation errors, the continuous discovery task will not be created, and you will need to correct the errors before proceeding.
View continuous discovery task details:
You can view continuous discovery task details by clicking on one continuous discovery task.
Figure 87 : Continuous discovery task detail The ignored sites field lists all sites that cannot be used to discover and register devices.
Page | 84
LOC-A Core Framework User Guide
Figure 88 : The ignored Sites list The results show the result of the last three runs. You can click the View Detail icon to view the details of each run.
LOC-A Core Framework User Guide
Page | 85
Figure 89: the continuous discovery task detail
Delete the continuous discovery task:
To delete one or more continuous discovery tasks, select the continuous discovery task(s) and click the Delete button. The deletion may take several seconds. After the deletion is complete, the page will be automatically refreshed to show the updated results. Note: If you need to delete a continuous discovery task, please ensure that the status of the continuous discovery task is “pending”, “canceled”, or “failed”.
Run the continuous discovery task:
Page | 86
LOC-A Core Framework User Guide
To run one or more continuous discovery tasks, select the continuous discovery task(s) and click the Run button. The status of the continuous discovery task will be set as “running” and the continuous discovery task will periodically invoke a “Discover and Register” workflow with the parameters defined in the continuous discovery task, e.g., the BMC current password. The next execution time of the workflow is the previous execution time plus the interval. If the interval is too short, the next execution will be postponed until the previous workflow is completed. If the workflow fails three times in a row (e.g., network connectivity problems), LOC-A will automatically mark the status of the continuous discovery task as “failed” and will not schedule the next execution of the workflow.
Note: If you need to run a continuous discovery task, please ensure that the status of the continuous discovery task is “pending”, “canceled”, or “failed”.
Cancel the continuous discovery task:
To cancel one or more continuous discovery tasks, select the continuous discovery task(s) and click the Cancel button. The status of the continuous discovery task is set as “canceled”. If the workflow invoked by the continuous discovery task is ongoing, the workflow will be canceled as well.
Note: If you need to cancel a continuous discovery task, please ensure that the status of the continuous discovery task is “running”.
Discovered Devices
Devices that are discovered through continuous discovery tasks will be added to the Discovered Device list.
LOC-A will manage these discovered devices without any human intervention. When one of the below conditions is met, the discovered devices will be removed from the Discovered Devices page automatically:
· These devices have been registered to LOC-A. · These devices cannot be discovered in subsequent scans anymore. · The continuous discovery tasks that discovered these devices have been deleted.
Go to Registered devices page then click Discovered Devices tab. You can view the list of discovered devices. The below figure shows an example page that lists the discovered devices:
Figure 90: Discovered devices list
A Device may be automatically discovered through the continuous discovery tasks but may not be able to be registered due to issues such as incorrect BMC credentials, incorrect UEFI credentials, network connectivity problems, or other configuration errors. In this case, users can manually select devices from this list to complete the registration process. Complete the following steps to register the discovered devices:
1. Select the device(s) you want to register and click the + button.
LOC-A Core Framework User Guide
Page | 87
Figure 91 : select devices you want to register
2. On the BMC/UEFI configuration page, specify BMC and UEFI new password policy. Specify existing BMC and UEFI passwords, as well, in the case that the server is not using a factory default configuration.
Figure 92: BMC/UEFI Config
3. After completing the form, click Done to start the registration process. You can view the progress of the registration process from the Tasks page.
Notes:
· During the registration process, the servers cannot be selected for registration, and the status of these servers will be set as “Registering”.
· If the registration process is completed successfully, the servers will be deleted from the Discovered Devices page automatically, and you can view these servers on the Registered Devices page.
· If the registration process encounters a failure, you can try the above registration process later.
Repository management
LOC-A provides an internal repository where you can upload your ISO files for bare metal or cloud deployments, upload firmware packages for your operations, or the OVA files for LXCI service deployment.
From the LOC-A web interface, click SetupRepository to view the list of files in the repository.
Page | 88
LOC-A Core Framework User Guide
Figure 93: LOC-A repository page
View image details:
You can view image details by clicking on one file from the Repository page. For ISO files, the MD5 checksum value is displayed. Figure 94 shows an example of the ISO image details.
LOC-A Core Framework User Guide
Page | 89
Figure 94: ISO image detail
For firmware package files, the firmware type (XCC or UEFI), release date, version/build information, and all supported device types for this firmware package are listed in the image details.
Page | 90
LOC-A Core Framework User Guide
Figure 95: Firmware package detail
Upload a file to the LOC-A repository:
Complete the following steps to upload a file to the LOC-A repository: 1. Click (Upload) from the Repository page. 2. Choose the file type of the file to be uploaded and click Browse to find the file.
Figure 96: LOC-A Repository Upload File to Server LOC-A Core Framework User Guide
Page | 91
3. Click Upload. · For an ISO file, the verification is done during upload. If the image is not supported, the upload operation to the repository will fail. · For a firmware file, for firmware of servers that are not ThinkEdge/ThinkSystem v3 or v4, make sure that the file you upload is a zip file that contains one or more Lenovo firmware bundles. Each firmware bundle needs to contain a .uxz firmware payload file, and an .xml file for manifests with the same filename prefix. The zip file supports only one directory level, please do not put .uxz or .xml files into a subdirectory in the zip archive, otherwise the firmware can’t be detected properly. For ThinkEdge/ThinkSystem v3 or v4, the firmware payload file you get from the Lenovo support site is a .zip file without an .xml file, please use this .zip file for upload directly and do not package this payload file again with other firmware bundles. You can visit https://datacentersupport.lenovo.com/ to get the expected firmware files for your servers. · For an Open Virtualization Appliance (OVA) file, you can upload a supported OVA file bundle. LOC-A only supports to use the OVA file for LXCI cloud service deployment.
Note: Repository files are important artifacts for your cloud and bare metal OS deployments. Make sure that you have the necessary files uploaded into the repository before you attempt to create a cloud or OS template and perform a deployment.
For large file uploads, unstable or poor network conditions (such as high latency, packet loss, or intermittent connectivity) may cause the upload to fail or be interrupted. You may see gateway timeout error once this occurs, please make sure your web browser client has better network connectivity to LOC-A portal.
Vault secrets management
HashiCorp Vault Instance can be used as a user owned backup solution for LOC-A user’s secrets, or as a user owned secrets source for LOC-A’s user secrets, including BMC credentials, OS credentials, service credentials, etc. This feature integrates LOC-A with the HashiCorp Vault application. Users can opt to centralize all secrets in a HashiCorp Vault server. Information about HashiCorp Vault can be found under these tutorials: https://developer.HashiCorp.com/vault/tutorials.
There are two types of Vault Instances: read-only vault and read-write vault. If a read-write Vault Instance is registered into LOC-A, LOC-A will automatically save all user’s secrets (including the auto generated secrets) into it. Read-only Vault Instances store secrets that are pre-populated by the user, and LOC-A will read the secrets whenever needed. LOC-A will not update any secret in a read-only Vault Instance. Users can register multiple Vault Instances in LOC-A.
If no read-write Vault Instance is registered, LOC-A will store user secrets internally. Starting from LOC-A 3.1, the LOC-A appliance stores user credentials in an internal HashiCorp Vault as well, instead of storing encrypted data in MongoDB. The user’s secrets, stored into the LOC-A internal vault server, will be used only to fulfill the LOC-A specific tasks/jobs and will not be accessible outside the LOC-A appliance through GUI or RestAPI calls.
Note:
· Once stored in LOC-A, plaintext credentials will not be displayed on GUI or accessible via LOC-A RestAPIs for the user’s safety. They will be displayed as “********”. If the credential is stored in an external vault, secret path with the format @@@vaultname@@full_secret_path will be displayed, and user can retrieve the content from their external vault system accordingly. The vault_name stands for the name of the registered external Vault Instance, while the full_secret_path contains the full secret path for that credential in the external Vault Instance, including the root secret path used during external Vault Instance registration.
· A credential policy with Auto approach cannot be created if there is no external read-write vault registered. Also, if the user wants to unregister the last read-write Vault Instance from LOC-A, and there are auto credentials policies defined in LOC-A, the unregister process will fail.
Page | 92
LOC-A Core Framework User Guide
· LOC-A talks to HashiCorp Vault Instances by using the vault tokens. A user can configure the vault token expiration time in HashiCorp Vault Server manager (32 days by default). Until LOC-A 3.1, if the token used expires, the user is expected to unregister the Vault Instance, and register it back with the new token. Starting from LOC-A 3.1, a Vault Instance can be updated with a new token value, without the need of removing the instance and adding it back.
User needs to setup an external vault server before starting to use the vault management feature in LOC-A. More users with different rights over different secret paths can be created in the vault server. One or more key/values secrets engine may be enabled. After that, the user can register the Vault Instance in LOC-A.
1. Registration of a read-write/ready-only Vault Instance in LOC-A Navigate to Setup Vaults and click the Add icon:
Figure 97: Vaults list After clicking the + icon, you will get the prompt dialog for you to input the Vault Instance information:
LOC-A Core Framework User Guide
Page | 93
Figure 98: Register a vault
– Vault Name: The HashiCorp Vault Instance name as an identifier. This should be unique in the LOC-A system.
– IP/FQDN/URI: The FQDN/IP of the Vault service – Port: The TCP port to access the Vault server. – Token: The authentication token to the Vault server. Please make sure the user associated to the
token has read-write rights over the root secret path inside the secret engine. – Secrets Path: The root path of the secrets (for example, LOCA/). – Mount Path: The mount point for the secret-path from HashiCorp Vault service (for example, kv-
v1/). The full root path will be in fact a concatenation between secret engine mount path and secrets path: kv-v1/LOCA/ in our example. – Read Only: This parameter will make the distinction between a read-only Vault Instance, used only as a secret source for LOC-A, and the read-write instance used for saving LOC-A secrets. – If “Read Only” is checked, user can optionally define the rules for the secrets path computation in the Vault server. Once templates are defined, it will be enough to specify the Vault Instance Name only
Page | 94
LOC-A Core Framework User Guide
when pushing a secret stored externally, while the secret path will be computed based on these templates/rules. – Service Template: Secret path template for Cloud Services credentials. Supported built-in template variables are:
{{service_name}}: the name of the Cloud Service {{platform_key}}: Cloud Service Platform Type {{role}}: Cloud Service Role taken from onboarding xls {{ip_fqdn}}: Cloud Service IP/(FQDN)/URI taken from onboarding xls Example: Service/{{service_name}} – Device Template: Secret path template for BMC new credentials. Supported built-in template variables are: {{site_name}}: string, the site name where the device will be registered {{mgmt_ip}}: string of the BMC IP {{serial_number}}: string, the device serial number {{uuid}}: string, the UUID of the device Example: Dev/{{serial_number}}/BMC – UEFI Template: Secret path template for UEFI new credentials. Supported built-in template variables are: {{site_name}}: string, the site name where the device will be registered to {{mgmt_ip}}: string of the BMC IP {{serial_number}}: string, the device serial number {{uuid}}: string, the UUID of the device Example: Device/{{serial_number}}/UEFI – Deploy Template: – Secret path template for OS root password/ssh key. Supported built-in template variables are: {{site_name}}: string, the site name where the instance will be deployed {{flavor_name}}: string, deployment flavor name {{geo}}: geo string of the site {{country}}: country string of the site {{province}}: province string of the site {{city}}: city sting of the site {{hostname}}: string, resulting Host FQDN of the device from the OS and Cloud deploy template {{ip_fqdn}}: string, IP associated with above hostname {{serial_number}}: serial number of the device Example: Dev/{{serial_number}}/OS – Secret Template: Secret format template. A vault secret is a dictionary containing different keys and values. LOC-A is interested in the format of only two keys: the username and password keys. Examples: “user@@@U, Pwd@@@P” – username key will be “user” and password key will be “Pwd” “password@@@P” the vault secret will contain only the password, the username may be part of the secret path. If not specified, the expected default keywords in vault server secret will be UserName and Password. Same as the default for secrets written by LOC-A in read-write Vault Instance.
2. Use Vault Instance in LOC-A: Whenever you are asked to input credentials, you can use @@@VaultName@@SecretPath syntax to refer to the secret stored in a read-only Vault Instance (e.g. @@@VaultRO@@Service/vCenter001). With pre-registered templates, only the vault name is required (e.g. @@@VaultRO2). 2.1 Use vault in Excel file during setup files upload.
LOC-A Core Framework User Guide
Page | 95
Figure 99: Vault in Excel file
Figure 100: Vault in Excel file with pre-registered secret path templates 2.2 Use vault in the LOC-A GUI. E.g., device upload, device profile set or cloud template creation, etc.
Figure 101: Configure to use Vault with secret path template
Page | 96
LOC-A Core Framework User Guide
Figure 102: Configure to use Vault without secret path template 3. How to delete(unregister) a Vault Instance from the GUI:
Figure 103: Delete Vault Instance
Select the Vault Instance that you want to delete and click on the delete icon. If the selected Vault Instance is a read-write instance, the user will be asked if they want to also delete all the secrets in the vault associated with that Vault Instance. If the instance is read-only the secrets will remain unchanged in the Vault system.
A Vault Instance can be registered at any time during LOC-A usage, so if the user has chosen by mistake to delete the secrets pushed by LOC-A in a read-write vault, the user can re-register the vault and the secrets will be used again by LOC-A.
LOC-A Core Framework User Guide
Page | 97
Create a cluster template
A cluster deployment template is a way to pre-define how one or more cluster instances should be configured. You can define the expected cloud flavor, hardware definition, parameters, naming conventions, and password policies in the cluster deployment template. Complete the following steps to create a cluster template:
1. Go to the Templates page and click Add to add a cloud template.
Figure 104: Templates page 2. Select a cluster flavor for the template.
Page | 98
Figure 105: Flavor selection
LOC-A Core Framework User Guide
3. Specify a unique template name. Template name length needs to be 5 to20 characters.
Figure 106: Cloud template wizard
4. Click Next to enter the Instance Info. 5. On the Instance Info page, select the target cluster type from the dropdown list. Then, define additional
cloud-specific parameters for your cluster.
For example, when you select cluster type “VMware ThinkAgile VX cluster(vSAN)”, you must configure Instance Name, Flavor Version, OS version and Datacenter Name. LOC-A supports vSAN version 8.0. The version of ESXi supported by LOC-A is ESXi 8.0U3 Build 24414501 please make sure you have downloaded the ISO file from https://vmware.lenovo.com and uploaded it into the LOC-A repository.
LOC-A Core Framework User Guide
Page | 99
Figure 107: Cloud template Instance Info
If your cloud template is for a RedHat OCP cluster deployment, you will need to provide the cluster name, cluster network, service network, RedHat OCP version, and the OpenShift Pull Secret for your deployment.
Below is an example of OpenShift Pull Secret:
{ “auths”: { “cloud.openshift.com”: { “auth”: “xxxxxxxxxxxxxxx”, “email”: “example@abc.com” }, “quay.io”: { “auth”: “xxxxxxxxxxxxxxx”, “email”: ” example@abc.com” }, “registry.connect.redhat.com”: { “auth”: “xxxxxxxxxxxxxxx”, “email”: “example@abc.com” }, “registry.redhat.io”: { “auth”: “xxxxxxxxxxxxxxx”, “email”: “example@abc.com” } }
}
Page | 100
LOC-A Core Framework User Guide
Note: LOC-A supports the use of built-in template variables to enable naming flexibility so that the cloud deployment template can apply to multiple sites. As an example, for cluster name, supported built-in template variables that can be used are:
· {{site_code}} : site code string of the site · {{flavor_name}}: flavor name string of the site. · {{site_name}}: site name string of the site · {{geo}}: Geo string of the site. · {{country}}: Country string of the site. · {{province}}: Province string of the site. · {{city}}: City string of the site
For example, if the templated cluster name is {{site_name}}_{{flavor_name}}_cluster1, the cluster name for site ABC will be created as ABC_vmware-thinkagile-vx-clustervsan_cluster1. You can refer to the hint of each input field to get the supported built-in template variables list.
6. Click Next to display networking details. In this page you can define the DNS namespace for your site cluster, and the node hostname FQDNs.
Ensure that the DNS namespace and hostname FQDNs you specify here align with the existing DNS entries you configured in the DNS servers associated with the site (defined as network services). See Cloud setup, on page 21 for more information.
For example, if the templated Node hostname FQDN is esxi{{#}}.{{site_code}}.{{province}}.{{country}}.customer.com
The node FQDN for a 3-node vSAN cluster site in site1 in Shanghai will be ‘esxi001.site1.shanghai.customer.com’, etc. If the vSAN-vManagement IP range of site1 is 10.0.0.21/24 10.0.0.30/24, you will need to configure DNS entries as follows:
address=/esxi001.site1.shanghai.china.customer.com/10.0.0.21
ptr-record=21.0.0.10.in-addr.arpa.,esxi001.site1.shanghai.china.customer.com
address=/esxi002.site1.shanghai.china.customer.com/10.0.0.22
ptr-record=22.0.0.10.in-addr.arpa.,esxi002.site1.shanghai.china.customer.com
address=/esxi003.site1.shanghai.china.customer.com/10.0.0.23
ptr-record=23.0.0.10.in-addr.arpa.,esxi003.site1.shanghai.china.customer.com
LOC-A will perform an environment pre-check for DNS entries in the cloud deployment task, if you don’t have proper entries configured, the cloud deployment task will fail.
Note: For vSAN cluster deployment, two DNS servers are mandatory, so you will need to configure proper
entries for both DNS servers.
LOC-A Core Framework User Guide
Page | 101
Figure 108: Cloud template – networking details
7. Click Next to view the Hardware Filters page where you can specify the expected device type and number of nodes for your cloud cluster deployment.
The minimum number of devices varies based on the cloud cluster type you selected. For VMware vSAN and RedHat OpenShift Container Platform, the minimum number of nodes is 3.
Check the option Select a firmware package, and you can choose a specific firmware package. The dropdown lists all supported firmware packages in your repository based on the device model you select.
In the Device Profile section, you can choose the available device profile that corresponds to the current flavor. This item is optional.
In the OS Credential Policy section, you can select the credential policy for root credentials of your cluster nodes. LOC-A supports three authentication types based on the cloud cluster type you selected.
Use a public key (approach of the credential policy is publicKey). Provide a public key as the authorized key, and you can SSH to your cluster nodes via the corresponding private key. All cluster nodes deployed with this cloud template will use the same authorized key.
Use a statically defined password (approach of the credential policy is static). Provide a static string as the root password. All cluster nodes deployed with this cloud template will use the same root password. This is usually not recommended because it is not secure.
Page | 102
LOC-A Core Framework User Guide
Figure 109: Cloud template – define hardware filter and static root password policy
Use a template to generate unique passwords (the approach of the credential policy is auto). You will use the template string defined in the credential policy to generate random passwords. Eg. template {{random_characters(12)}} makes a 12 character, random string for each of your nodes’ operating system.
Figure 110: Cloud template – define hardware filter and auto root password policy
LOC-A Core Framework User Guide
Page | 103
Please refer to the section Credential policy for more details.
Available authentication options vary based on the cloud cluster type you selected. Below is the matrix for the options supported by each cloud flavor.
Cloud or Bare metal OS offering
Authentication Type Support
RedHat OCP
· public key
VMware vSAN
· static password
· password template string
Bare metal OS
· static password
· password template string
Table 11: Nodes Authentication Types supported by LOC-A
After filling in all the information for the template, click Save to save the cloud template. Alternatively, click Proceed to deployment to save your cloud template and display the cloud deployment wizard page with this template selected.
Figure 111: Cloud template summary
8. It takes several seconds to save the cloud template. After that, you should be able to see your template listed on the page. You can view template details or delete a cloud template from this page.
Page | 104
LOC-A Core Framework User Guide
Figure 112: Cloud templates list
View cloud template details:
To view cloud template details, click on a template from the Templates page and then click the eye icon.
LOC-A Core Framework User Guide
Page | 105
Figure 113: Cloud template detail
Update a cloud template
Starting with LOC-A version 3.3, you can click the Edit button to update a cloud template. The modification wizard is the same as that for template creation. However, the Flavor cannot be modified. If a new Flavor is needed, it is necessary to create a new template.
Note:
· If the template is being used by an instance, modification will not be supported. Meanwhile, the associated device profile and credential policy will also not be available for modification.
Page | 106
LOC-A Core Framework User Guide
· All sensitive data will be shown as eight asterisks on the initial editing page. If no modification is required, just leave the eight asterisks as they are.
Cluster deployment
After you have created your cluster template and uploaded the metadata for your sites, you have completed the planning phase for your deployment.
Complete the following steps to instantiate the cluster:
1. From the LOC-A portal, click Instances. Then click Add to start the process. 2. Select the target cloud template to apply in the dropdown. All sites ready for deployment will be
dynamically displayed in the list.
LOC-A Core Framework will calculate the site readiness through the following rules:
· Deployment Readiness Status needs to be Ready, indicating mandatory IP ranges, network
services and cloud services with valid information are imported for the site. This is also dependent upon the cloud flavor of your selected cloud template. For example, for the VMware vSAN cloud flavor, if you plan to use LOC-A to install vCenter and LXCI services during vSAN cloud deployment, LOC-A will also check whether the specific VCSA and LXCI images are present in the repository and mark the Deployment Readiness Status as notReady if the requirement is not met. Please refer to Section Cloud setup if you don’t have your resources imported.
· Devices with the expected device type are registered to the sites, the number of devices and
available cluster IP resources meet the minimal requirement of “Number of devices” defined in your cloud template. Please refer to the Section Register devices if you don’t have proper servers registered into LOC-A.
Figure 114: Create new cloud instance via template LOC-A Core Framework User Guide
Page | 107
3. Select one or more sites to be deployed. By default, the selected device count for each site is the number of devices defined in your cloud template. You can add more devices in the dropdown list of the site. If
Documents / Resources
 |
Lenovo LOC-A Core Framework Software [pdf] User Guide LOC-A Core Framework Software, LOC-A Core Framework, Framework, Software |